Vliegmaatschappijen moeten systemen Airbus A350-vliegtuig elke 149 uur rebooten

Vliegmaatschappijen moeten van de EU-luchtvaarttoezichthouder in ieder geval een deel van hun A350-passagiersvliegtuigen uiterlijk elke 149 uur rebooten. Hier werd twee jaar geleden ook al voor gewaarschuwd. Het gaat om een paar systemen die anders problemen kunnen vertonen.

De European Union Aviation Safety Agency heeft een nieuwe, verplichte, zogeheten airworthiness directive uitgevaardigd, waarin het schrijft dat luchtvaartmaatschappijen uiterlijk elke 149 uur op de grond een reboot moeten uitvoeren. Dat hangt samen met een software-bug. Die is in 2017 al geïdentificeerd en Airbus heeft er een oplossing voor in de vorm van een aantal softwaremodificaties. Luchtvaartmaatschappijen moeten ofwel de software-updates doorvoeren ofwel de genoemde rebootcycli aanhouden.

Deze software-updates worden bij een aantal A350 type 941-vliegtuigen al doorgevoerd, maar alle andere A350-941's van alle serienummers waarbij dat nog niet het geval is, moeten de instructie ten aanzien van het herstarten van de systemen verplicht doorvoeren. De fix van Airbus betreft nieuwe software voor de core processing input / output module en de common remote data concentrator. Laatstgenoemde systeem verzamelt data van verschillende sensoren aan boord van de vliegtuigen.

De verplichte instructie van de EASA gaat vrijdag in en moet voorkomen dat een verlies aan communicatie tussen de sommige avionica-systemen en het avionica-netwerk optreedt. Uit eerdere analyses bleek dat dit kan voorkomen nadat deze systemen van de A350 doorlopend voor de duur van 149 uur zijn ingeschakeld. Er zijn verschillende gevolgen geconstateerd, zoals een 'verlies van redundancy tot een volledig verlies van een specifieke functie die wordt gehost op de common remote data concentrator en core processing input/output modules'.

Dit probleem is niet gerelateerd aan, maar lijkt wel enigszins op een issue van de Boeing 787 Dreamliner. In 2015 werd er bij dit eveneens relatief nieuwe toestel een memory overflow bug ontdekt, waardoor de generatoren van het vliegtuig zichzelf na 248 dagen van doorlopend gebruik konden uitschakelen. Dat werd veroorzaakt door een softwareteller in de firmware van de generator control units. In het ergste geval kon dit leiden tot een volledig verlies van de wisselstroom, waardoor de controle van het vliegtuig verloren kon gaan. Voor dit probleem heeft de Amerikaanse toezichthouder, de Federal Aviation Administration, destijds een airworthiness directive uitgevaardigd.

Reacties (267)

[__fred__]

Ik weet niet waarom dit nieuws is, maar het originele bulletin is 2 jaar oud, en toen was de instructie exact gelijk. Luchtvaartmaatschappijen doen dit al die tijd al. Het was toen binnen 30 dagen verplicht. Bekijk de originele revisie van het document maar eens. Ze zijn al een jaar bezig met het updaten van de A350's met nieuwe software. De AD is eindelijk aangepast, om de gemodificeerde toestellen uit te sluiten van de AD. Het zou me verbazen als er nog één rondvliegt met de oude software.

https://ad.easa.europa.eu/ad/2017-0129R1

[Reactie gewijzigd door __fred__ op 22 juli 2024 18:23]

[twiekert]

Dit is 'nieuws' vanwege het hele Boeing schandaal met de MAX 737. Ik ben bij dit soort berichten dan altijd benieuwd wat de bron is en wie het heeft ingestuurd.

De bron waarop dit bericht is gebaseerd stelt namelijk geen ene reet voor. het is een revisie van, zoals je al zei, een bulletin van 2017. En de wijziging aan de revisie is een verlaging van het type toestellen waarop dit bulletin van toepassing is.

[A3vdBerg]

Ben ik helemaal met je eens twiekert!

[Bert Gent]

Dogma in de nieuwswereld:

1) "Er kan nooit geen nieuws zijn"
2) "mocht er ooit toch geen nieuws zijn: onmogelijk want er is nooit geen nieuws!"

[kaasboer09]

Inderdaad, dat was me nog niet eens opgevallen. Ik ook wel benieuwd waarom dit nu opeens het nieuws zou halen. Revisies zijn wat mij betreft niet echt boeiend...

[Stoelpoot]

Dit is inderdaad een beetj een anticlimax t.o.v. het bericht, wat er meer op leek dat de EU-autoriteit nog eens moest herhalen dat ze wel echt deden (en dat sommige maatschappijen dat dus niet deden).

[kaasboer09]

Ik de praktijk is deze bug eigenlijk een non-issue. De vliegtuigmaatschappijen hebben ruim de gelegenheid om elke 149 uren een relatief simpele reboot uit te voeten. Daarom dat er ook geen Alert Service Bulletin is afgegeven, maar een reguliere SB.

Maar inderdaad, steeds vaker is ongepland onderhoud in de luchtvaart gerelateerd aan computer systemen, en in mindere mate mechanische componenten. En dat is eigenlijk ook niet zo gek. De mechanische componenten zijn tegenwoordig van betere kwaliteit (betere inzichten tijdens het ontwerp, etc.) terwijl de complexiteit van de computer systemen alsmaar toeneemt.

[pauldebra]

Dit soort bugs blijven in software komen zolang mensen het een "non-issue" blijven vinden. De meest voorkomende problemen met software die reboots noodzakelijk maken zijn memory leaks. Een goede programmeur (die ook voldoende rust en tijd krijgt) schrijft alleen maar software *zonder memory leaks* en *zonder buffer overflows* en dergelijke.
Het is onaccepptabel dat software systemen regelmatig moeten worden gereboot omdat ze het anders niet meer doen. Hiervan heb ik mijn hele leven lang mijn studenten van proberen te overtuigen. Goede software blijft het gewoon altijd doen. Ik wil niet mijn koelkast elke zoveel tijd resetten, of mijn koffieapparaat, of TV of auto, of noem maar op... en als ik met het vliegtuig meereis dan verwacht ik dat daar goede software inzit zodat het niet neerstort zoals een 737-MAX... De meeste dingen met software bij mij in huis doen het gelukkig goed, maar de TV ontvanger bijvoorbeeld niet (hapert soms en moet dan even uit het stopcontact), de netwerk-over-powerline adaptors hebben ook dat probleem, en dat zijn allemaal software problemen, veroorzaakt door sloppy programmeerwerk door mensen die vinden dat het een "non-issue" is.

[Verwijderd]

Hoewel het ook een memory-leak is, bestaat er zoiets als memory fragmentatie. Dat is best moeilijk voor een junior programmeur om te ontdekken en misschien wel net zo moeilijk om tegen te gaan.

Het probleem is dat in de libc laag van het besturingssysteem enkel zeg maar aaneengeschakelde blokken kunnen vrijgegeven worden. M.a.w. heb je in zo'n blok nog iets in gebruik, dan blijft het hele blok in gebruik, en zullen blokken die ervoor kwamen ook niet vrijgemaakt kunnen worden.

Veel programmeurs die strdup() en free() gebruiken voor strings gaan dat dan ook soms veroorzaken (in GLib heb je daar g_strdup dan voor, en zo verder). Maar dus de free() is er wel. En toch kan je memory-fragmentatie (= een memory leak) veroorzaken.

Uiteraard valt daar wat aan te doen. Zoals magazine allocators gebruiken (bv. g_slice_* in GLib) voor gelijkvormige structs en GStringChunk. In Qt is het meeste al voorzien in de standaard QString natuurlijk.

Ik weet uiteraard niet wat ze bij Airbus gebruiken, en vermoedelijk hebben vliegtuigen niet zo veel string achtige dingetjes nodig. Maar vaak zijn memory-leaks die pas na vele uren een probleem worden gerelateerd aan memory fragmentatie. Memory leaks die sneller zichtbaar (groter in omvang en ernstiger per frequentie) zijn zijn vaker traditionele memory-leaks (free of in C++ delete vergeten, cyclic reference van een smartpointer, en zo verder).

[Troepje]

Zodra je strdup in missie kritische systemen gebruikt, neem je jezelf niet serieus... Uberhaupt technieken genoeg om memory fragementatie tegen te gaan. Ook een fatsoenlijk opgeleide embedded software engineer weet dat al als junior.

Verder is memory fragmentatie totaal ongelijk aan een memory leak.

Fouten worden nu een keer gemaakt, het hoeft maar een tellertje te zijn die een overflow krijgt en je bent de lul, Een duurtest van 149 uur voor een vliegtuig continu aan klinkt mij al best lang in de oren, zo lang kan ie niet eens achter elkaar vliegen toch? Sowieso zal dat ook nog eens aan de veilige kant zijn.

Verder zijn er om echte leaks te vinden 48747698432 tools te vinden, dus denk echt niet dat het een memory leak is, het zal gewoon een over het hoofd geziene overflow zijn.

[Verwijderd]

Voor real time software ga je inderdaad normaal geen dingen doen die malloc veroorzaken (zoals strdup). Maar niet alle softwares in een vliegtuig hoeven noodzakelijk realtime te zijn.

De bug klinkt inderdaad wel eerder als een overflow van een 32bit nummer dan een memory leak.

[Martao]

Ik vind het echt belachelijk dat dit +2 oplevert.
Allereerst: programmeurs maken nou eenmaal fouten. Sommige zijn duidelijk en komen snel naar voren. Sommige treden alleen in uitzonderlijke situaties op, dus v zijn moeilijk te voorkomen. Je leeft in een utopische wereld als je denkt dat die te voorkomen zijn!
In een Boeing wordt natuurlijk wel veel meer gecertificeerd en getest dan in een tv ontvanger, maar het principe is hetzelfde

Daarnaast: hoe vaak draait jouw tv ontvanger 200 uur? Die van mij staat hooguit 4 uurtjes aan. Ik heb het idee dat je een beetje verkeerde eisen aan consumenten producten stelt. Het aan en uitschakelen van dergelijke apparatuur duurt orde grootte seconden. Dus ja: het is vaak ofwel een non-issue, ofwel een kostenpost die de consument niet wil betalen.

Ik vind het zelfs bij een vliegtuig en vreemd verhaal. De meeste toestellen zullen snachts aan de grond staan. Zouden er dan systemen zijn die desondanks 24/7 operationeel zijn? Oké, er zijn misschien (vracht)vliegtuigen die doorlopend op pad zijn, dat zijn uitzonderingen, maar die moeten ook blijven vliegen natuurlijk

[Reactie gewijzigd door Martao op 22 juli 2024 18:23]

[GeoBeo]

Ik vind het echt belachelijk dat dit +2 oplevert.
Allereerst: programmeurs maken nou eenmaal fouten. Sommige zijn duidelijk en komen snel naar voren. Sommige treden alleen in uitzonderlijke situaties op, dus v zijn moeilijk te voorkomen. Je leeft in een utopische wereld als je denkt dat die te voorkomen zijn!
In een Boeing wordt natuurlijk wel veel meer gecertificeerd en getest dan in een tv ontvanger, maar het principe is hetzelfde

Daarnaast: hoe vaak draait jouw tv ontvanger 200 uur? Die van mij staat hooguit 4 uurtjes aan. Ik heb het idee dat je een beetje verkeerde eisen aan consumenten producten stelt. Het aan en uitschakelen van dergelijke apparatuur duurt orde grootte seconden. Dus ja: het is vaak ofwel een non-issue, ofwel een kostenpost die de consument niet wil betalen.

Ik vind het zelfs bij een vliegtuig en vreemd verhaal. De meeste toestellen zullen snachts aan de grond staan. Zouden er dan systemen zijn die desondanks 24/7 operationeel zijn? Oké, er zijn misschien (vracht)vliegtuigen die doorlopend op pad zijn, dat zijn uitzonderingen, maar die moeten ook blijven vliegen natuurlijk

Ik vind het belachelijk dat mensen slechte software en producten zo enthousiast verdedigen.

Buggy software en hardware is vandaag de dag gewoon de norm. En vandaar dat jij dat misschien "normaal" vindt, maar ik als ontwikkelaar heb daar 0 respect of geduld voor. Ik kan niet 1 stuk software noemen waar geen ontzettend irritante bugs (of down time) in zitten. Dit gaat niet over bugs waar je bijna niets van merkt. We hebben het hier over bugs die een vliegtuig kunnen laten neerstorten. Of bugs die alle gebruikers mateloos irriteren. Hoe kun je het normaal vinden dat je "soms ff je vliegtuig moet resetten, omdat hij anders neerstort"?!

Als freelancer heb ik bij heel veel bedrijven een kijkje kunnen nemen (ook in de luchtvaart) en mijn conclusie is: slecht werkende troep op de markt brengen is gewoon de norm. Iedereen doet het, de klant accepteert het (of verdedigd het zelfs, zoals in het citaat) en er is daarom voor bedrijven geen enkele reden om producten op de markt te brengen die beter zijn dan "troep" en "net goed genoeg". Kost alleen maar meer ontwikkeld tijd en geld en mensen kopen je troep toch wel.

Dit is geen kwestie van "programmeurs maken nou eenmaal fouten" dit is een kwestie van "programmeurs maken een eerste grove afgeraffelde opzet die het per ongeluk goed genoeg doet (maar nog vol zit met bugs) en managers bepalen dat het product rijp is voor de verkoop". "Snel op naar het volgende project. Hoeven we die paar extra programmeurs ook niet in te huren. "

En laat de strikte normen van de luchtvaart geen illusie zijn: het is prima mogelijk brakke software te schrijven en tegelijk an alle veiligheidseisen en certificatie eisen te voldoen. Met hele dikke stapels documentatie. En dit gebeurt dan ook aan de lopende band. De neergestorte 737 MAX en deze A350 software zijn het topje van de ijsberg. Ik kan je garanderen dat er behalve die ernstige bugs ook een hele berg irritante bugs zijn die het leven van zowel de stewardessen als piloten als ook onderhoudspersoneel lastig/onmogelijk maken. Je zou de lijsten SIL's en SB's en verschillende mogelijke configuraties (hardware en software combinaties) eens moeten zien van een gemiddeld toestel inclusief alle apparatuur aan boord. Niemand die daar nog wijs uit kan worden.

Een zekering vervangen door een stuk metaal, zodat het irritante veiligheidssysteem niet steeds onterecht inschakelt? Yep, komt nog steeds gewoon voor.

[Reactie gewijzigd door GeoBeo op 22 juli 2024 18:23]

[Verwijderd]

Een zekering vervangen door een stuk metaal, zodat het irritante veiligheidssysteem niet steeds onterecht inschakelt? Yep, komt nog steeds gewoon voor.

LOL. Als daar brand van komt dan stort het vliegtuig neer of verstikken de passagiers. Of beide. Of de piloten vallen flauw van de CO en/of rook.

Wie zoiets doet in een vliegtuig hoort in de gevangenis te zitten.

[GeoBeo]

[...]
LOL. Als daar brand van komt dan stort het vliegtuig neer of verstikken de passagiers. Of beide. Of de piloten vallen flauw van de CO en/of rook.

Wie zoiets doet in een vliegtuig hoort in de gevangenis te zitten.

Nooit van die programma's als "air crash investigation" gekeken? Dat soort redenen zitten ertussen hoor... Ik herinner me er eentje van piloten die zelf in de cockpit een fuse hadden vervangen door wat aluminium folie. Dit was een "geheime truuk" die onder piloten circuleerde voor dat type vliegtuig, omdat ze anders helemaal horendol werden van een stem die constant een of andere waarschuwing (onterecht) omriep. Die piloten hebben het niet overleeft.

Genoeg bugs waar piloten helemaal gestoord van worden. Stel je voor dat je op je werkvloer elke keer 10 uur lang een of ander klote alarm (inclusief een stem die onterecht ergens voor waarschuwt) hoort afgaan en steeds opnieuw zichzelf onterecht inschakelt. Wat zou jij doen? Dat soort zaken zijn o.a. wat ik bedoel met irritant brakke software in mijn vorige post.

Tegenwoordig wordt er door de luchtvaart autoriteiten (als het goed is) strenger gecontroleerd op dat soort onterecht inschakelen van veiligheidssystemen en alarmen. Ze zijn er nu dus ook achter gekomen dat een alarm dat veel te vaak inschakelt en irritant is, op zichzelf ook een enorm gevaar kan vormen. En dat zo'n alarm dat veel te vaak afgaat niet "altijd veiliger is dan een alarm dat helemaal niet af gaat".

Als je hiermee gepakt wordt als vliegmaatschappij kun je rekenen op een flinke boete, maar de gevangenis gaat voor zover ik weet helemaal niemand in voor dat soort acties. Het probleem is dat er enorm veel mogelijkheden zijn om "kwaad te doen" zonder dat ooit iemand het door zal hebben. Als een onderhoudstechnicus in het veiligheidssysteem van de wijnkoeler een zekering door soldeert dan zal niet direct iemand daarachter komen. Of als piloten met onderlinge goedkeuring van elkaar een zekering even vervangen door een stukje folie... sja... Veiligheid wordt door de meeste mensen in de luchtvaart wel serieus genomen, maar zelfs dat is niet altijd genoeg...

[Reactie gewijzigd door GeoBeo op 22 juli 2024 18:23]

[skozaa]

Zelfs als 't probleem zou zijn opgelost. Zou ik uit voorzorg als nog ff een rebootje geven om zeker te zijn
Dat doe ik ook met mijn PC. Ff een reboot omdat die dan toch weer helemaal schoon is tijdens een boot. Alle processen die je niet nodig hebt die dan niet onnodig draaien Ook al is mn pc goed genoeg zonder even een reboot te doen en ik zou er toch niks van merken.

[Goof2000]

Je maakt een denkfout, je tv ontvanger staat 24/7/365 aan. (daarnaast vind ik het niet netjes om een beoordeling @pauldebra zo te bedoezelen)

Uitleg mbt tv ontvanger::
Alleen als je de stroom eraf haalt, dan gaat de tv ontvanger uit.
Bij mij duurt het zo'n 1 a 2 minuten voordat hij daarna weer opgestart is.
Het gebeurt nog wel eens dat ik de stroom van mijn tv ontvanger eraf moet halen om hem opnieuw op te starten. Dat ontdek ik bij het moment dat ik iets wil kijken, bij mij is dat irritant (en reden om over te stappen naar leverancier die wel een goede tv ontvanger heeft) maar bij een vliegtuig wat bezig is met het opstijgen of landen gevaarlijk. De systemen van vliegtuigen blijven altijd aan als ze ('s nachts) aan de grond staan en krijgen daardoor geen reboot, daar is het design van de hardware en software op gemaakt.

Programmeurs:
Een programmeur maakt fouten, dat klopt, maar daar heb je regels en kwaliteitscontroles voor om te zorgen dat deze worden gedetecteerd. De programmeur zal beseffen dat hij fouten kan maken, maar er alles aan doen om ze niet te maken. Als ik zie hoe sommige programmeurs code schrijven dan is het vragen om problemen, dat besef probeert @pauldebra aan te leren bij programmeurs. Het voorkomt fouten en dan vallen fouten ook beter te detecteren.

[Arokh]

Juist de a350 is een toestel wat bijna nooit stil staat. Hij vertrekt in de middag uit Amerika en komt dan in de ochtend hier aan. Dan vliegt hij door naar Bangkok bijvoorbeeld en komt daar de volgende ochtend aan. Terug naar NL en weer door naar Rio de Janeiro Etc. Etc. Elke minuut dat hij stilstaat kost hij veel geld.

[pepsiblik]

Hij staat minimaal een uur stil na elke landing om te tanken, schoongemaakt te worden en uitgeladen en ingeladen te worden. Dan kan je dus perfect die reboot laten doen.

[SideShow118]

Heb jij wel eens een reboot van een vliegtuig uitgevoerd?

Wie zegt dat er tijd is om dit binnen een uur te doen?

Soms moet het hele vliegtuig uitgezet worden voor een "simpele" reboot. Soms kan het wel "gewoon" zos je thuis kunt doen.

[michielonline]

het rebooten van het entertainment systeem van Delta duurde laatst al meer dan 15min in-flight, als zoiets "simpels" al een kwartier duurt, vraag ik me af hoe lang het duurt om de avionics opnieuw op te starten.

[680x0]

Dat systeem van Delta (Linux trouwens) moet al jaren constant gereset worden omdat het voor geen meter draait..

[Bert Gent]

Ja, ook meegemaakt op een vlucht naar Chicago. Die entertianment systemen zijn echt crap wat performantie betreft.
Avionics systemen zijn heel performant. Opstarttijd daar heeft vooral te maken met IRS alignment. Kwestie van minuten.

[dredger]

Om delays te voorkomen kan je het toch gewoon tijdens een nachtvlucht doen als iedereen slaapt? FF op de hand

[SideShow118]

Eens. Als je de motoren ff uitzet dan glide je gewoon verder, is het gelijk donker en staat die airco/verwarming ook niet zo op de strot te loeien.

Ik zie het probleem ook niet

[sprankel]

Euh, nee, een grondtijd van een uur is niets, dat is in vliegtuigtermen hetzelfde als 5 minuten stoppen aan een tankstation met je auto.
Je bent sowiezo 30 minuten kwijt aan boarding. Dat is 15 minuten om iedereen eruit te krijgen en 15 minuten om iedereen erin te krijgen. En dan ga ik ervan uit dat er geen gigantische hoeveelheden handbagage is.
Om te tanken heb je 15 minuten nodig. Echter tijdens het tanken is het vliegtuig EX zone wat wil zeggen dat er in die 15 minuten geen enkele andere activiteit mag plaats vinden.
In die resterende 15 minuten moet het toestel gereinigd worden, crew gewisseld (meestal komen de piloten later dan de rest van de crew) & catering aan boord worden gebracht. Bagage kan tijdens boarding gebeuren maar zeker niet tijdens tanken.

Dan heb je nog de "reboot", dit is niet een knopje uit en een knopje aan; er zijn noodprocedures voor een reboot en gewone procedures voor een reboot. Niet enkel zal de reboot op een correcte manier worden ingezet, verwacht je maar aan een heel lange checklist om na te gaan of de computer correct functioneert na zijn reboot. Een volledige reboot is meerdere systemen die in een correcte volgorde herstart moeten worden waarbij je in tussentijd vollop testen mag lopen doen.
Een vliegtuig aan de gate draait op een externe generator met als voornaamste reden dat de computers gewoon kunnen blijven draaien en zeker niet opnieuw opgestart moeten worden.

[Reactie gewijzigd door sprankel op 22 juli 2024 18:23]

[Icefellow]

ik weet niet waar jij je informatie vandaan haalt maar dit slaat echt de plank wel mis...

vliegtuigmaatschappijen werken heel hard om de tijd aan de grond te minimaliseren. Hoe minder een vliegtuig aan de grond staat hoe meer vluchten / dag / hoe meer winst er gemaakt kunnen worden op al (zeer kleine) marges.

15 minuten tanken waarbij geen andere activiteit mag plaatsvinden?:

Ik citeer maar even uit het handboek :

15.2 Handhaving veiligheidsmaatregelen tijdens tanken
Algemeen
Het toezicht van A.A.S. op de naleving van procedures tijdens het tanken van vliegtuigen is gebaseerd
op de relevante artikelen van de Schipholregels en de richtlijnen van IATA zoals deze zijn beschreven in
het Airport Handling Manual (AHM) – IATA Ground Operation Manual (IGOM) Supplement – Chapter 4
Aircraft Handling Procedures – paragraph 4.4 Safety during fueling/defueling.
A.A.S. stelt op basis van het periodiek opvragen van kwaliteitscertificaten zeker dat bedrijven die
betrokken zijn bij de opslag en het tanken van vliegtuigbrandstof, voldoen aan de eisen die gesteld
worden t.a.v. deze processen. Als norm hiervoor worden de standaarden van de Joint Inspection Group
(JIG) geaccepteerd, in het bijzonder JIG 1 – Aviation Fuel Quality Control and Operating Standards for
Into-Plane Fuelling Services.
Het dagelijkse toezicht op het tankproces op Schiphol wordt uitgeoefend door Authority Officers, die
door middel van routinetoezicht en specifieke inspecties toetsten op de opvolging van de
veiligheidsregels t.a.v. tanken. Als norm voor het routinetoezicht gelden de bepalingen in de
Schipholregels; voor de inspecties gelden de richtlijnen van IATA als norm.
Tanken met passagiers aan boord
Het tanken met passagiers aan boord is op Schiphol toegestaan wanneer aan de volgende voorwaarden
wordt voldaan:
a. er is toestemming gegeven door de gezagvoerder
b. het vliegtuig heeft een stoelcapaciteit van meer dan 19 passagiers;
c. er wordt niet over de vleugel van het vliegtuig heen getankt;
Bedrijfshandboek Amsterdam Airport Schiphol
Deel 1: Aerodrome Manual Deel E – Operationele procedures
Indeling 2014 – versie 6.0 – juni 2018 Pagina 64 van 81
Informatieclassificatie: openbaar
d. er wordt geen kerosine Jet B, AVGAS of MOGAS getankt;
e. tussen de cockpit en het grondpersoneel is een communicatieverbinding;
f. de gezagvoerder heeft nooduitgangen aangewezen waarbij een vliegtuigtrap is geplaatst of die van
een glijgoot zijn voorzien en bij deze nooduitgangen is gedurende het tanken gekwalificeerd
cabinepersoneel aanwezig;
g. de aangewezen nooduitgangen bevinden zich niet aan de zijde van het vliegtuig waar wordt
getankt;
h. de aangewezen nooduitgangen en vluchtroutes worden niet geblokkeerd door
afhandelingsmaterieel;
i. aan de passagiers is meegedeeld dat:
 zij op hun plaatsen moeten blijven zitten, tenzij zij in- of uitstappen;
 de veiligheidsriemen ontkoppeld moeten zijn;
 zij geen handelingen mogen verrichten, waarbij een vonk of open vuur ontstaat of zou kunnen
ontstaan;
j. tijdens het tanken in het vliegtuig is de minimum cabineverlichting ontstoken;
k. de voor het tanken verantwoordelijke persoon is op de hoogte is van het feit dat er passagiers aan
boord zijn of in- of uitstappen.
Wanneer aan alle bovenstaande voorwaarden is voldaan, is het niet noodzakelijk separate toestemming
aan de exploitant te vragen voor het tanken met passagiers aan boord.
Het tanken met passagiers aan boord is niet toegestaan bij helikopters.

[Reactie gewijzigd door Icefellow op 22 juli 2024 18:23]

[sprankel]

Ex medewerker die een jaar op de luchthaven gewerkt heeft tot hij genoeg had van de gigantische werkdruk, race to the bottem en de gigantische berg overuren.

De regels die je post bevestigen ook perfect wat ik zeg, tijdens het tanken mag er geen enkele andere activiteit plaats vinden. Ja er mogen passagiers opzitten maar ze mogen niet eens hun stoel uit en je moet ze een safety instructie geven voor je gaat tanken. Tevens moeten de piloten aanwezig zijn wat in 50% van de tijd niet zo is.
De enige case waarbij getankt word met passagiers aan boord is een tussenlanding waarbij passagiers sowieso op het vliegtuig blijven. Vraag maar eens na hoeveel mensen ooit al gehoord hebben dat ze gaan tanken, je bent immers verplicht dit te melden aan je passagiers. Enige andere case is wanneer de planning de soep is ingedraaid en men beslist heeft eerst te boarden en dan te tanken om vertraging tot een minimum te houden.

Let wel dat die regels luchthaven afhankelijk zijn maar er zijn altijd heel strenge regels rond vanwege het gevaar. 15 minuten is niet lang om te tanken en een uur is echt wel het minimum aan grondtijd voor een gewoon toestel. 1 maatschappij wilde het op 40 minuten klaar spelen, laat ons zeggen dat het er altijd feest was met delays en discussies. Als je naar de grotere vliegtuigen gaat heb je nog meer tijd nodig al was er ook 1 die probeerde dat in een uur te doen, je raad het al, continu delays, als die om 14:00 moest landen schreef ik 15:00 op mijn planning, helft van de tijd stond hij nog niet aan zijn gate.

[Niemand_Anders]

Ik heb zelfs een keer meegemaakt dat we naar het boarden vanaf de gate vertrokken naar een parking gate en dat daar het toestel werd getankt. Er waren die dag op Schiphol meerdere vertragingen en om de tijd aan de gate te minimaliseren ging het naar een andere plek op de luchthaven. Dit heeft er vooral mee te maken dat vertrektijd wordt gemeten vanaf het moment dat de push-back start..

Ik had echter op dat moment mijn koptelefoon op, dus had het bericht half gemist..

[CAPSLOCK2000]

Ik vind het echt belachelijk dat dit +2 oplevert.
Allereerst: programmeurs maken nou eenmaal fouten. Sommige zijn duidelijk en komen snel naar voren. Sommige treden alleen in uitzonderlijke situaties op, dus v zijn moeilijk te voorkomen. Je leeft in een utopische wereld als je denkt dat die te voorkomen zijn!

Overal maken mensen fouten, maar meestal weten we daar beter mee om te gaan dan bij software. Architecten en metselaars maken ook fouten. Met slimme technieken en ruime marges compenseren we daar voor. In de software wereld zijn we daar veel minder goed in.
Je zou kunnen zeggen dat rebooten na 149 uur zo'n maatregel is, maar dat is alsof je een deur van je gebouw niet mag gebruiken wegens instortingsgevaar.

In een Boeing wordt natuurlijk wel veel meer gecertificeerd en getest dan in een tv ontvanger, maar het principe is hetzelfde

Je kan het ook als probleem zien. We hebben geen structureel inzicht in de kwaliteit van onze software. Eindeloos testen is in praktijk de enige manier om iets over de kwaliteit te zeggen. Bij gebouwen rekenen we het hele gebouw door voor de eerste steen gelegd wordt en daarna wordt er wel getest, maar vooral om te zien of alles aan de verwachtingen voldoet.
In theorie kunnen we software ook doorrekenen, maar in praktijk is dat zo lastig dat vrijwel niemand het doet.

Het probleem met deze aanpak is dat je niks kan veranderen zonder opnieuw te gaan testen, en dat is al snel erg duur. In de vliegtuigindustrie zelfs extreem duur. Daarom wordt er zo min mogelijk veranderd als het eenmaal gelukt is om door de keuring te komen. Dan ontstaat vanzelf de neiging om bugs af te dekken met symptoombestrijding in plaats van iets te veranderen.

Bij vliegtuigen is dat extra sterk, maar tot op zeker niveau gaat het overal zo.

We hebben een fundamenteel andere manier van werken nodig om de kwaliteit van software te garanderen. (Hoe weet ik ook niet, anders was ik nu rijk geweest).

[Troepje]

Dus je hebt nog nooit gehoord van een gebouw dat toch niet bleef staan of instortte wegens foute in ontwerp op bouw? Ik nodig je uit een te googlen.

[CAPSLOCK2000]

Zo zwart-wit kijken heeft geen zin. Je kan beter naar de grote lijnen kijken dan naar de uitzonderingen.

99% van de hedendaagse gebouwen heeft nooit een probleem dat zo erg is dat de veiligheid van de gebruikers in gevaar wordt gebracht. 99% van de hedendaagse software heeft vroeg of laat wel zo'n beveiligingsprobleem.

Dat gebouwen tegenwoordig zo veilig zijn is een combinatie van wetenschap (we snappen genoeg van materialen, natuurkunde en bouwprocessen), regelgeving (we verplichten bepaalde standaarden en systemen zoals regels voor beton maar ook verplichte nooduitgangen), onafhankelijke controle, en ruime marges. Ergens zijn al die punten verbonden. Hoe meer je begrijpt hoe beter je het kan doorrekenen en reguleren.

Software is veel complexer, is veel minder beperkt door natuurwetten zoals zwaartekracht, wrijving of ruimtelijke beperkingen, wordt pas enkele decennia op grote schaal gebouwd, er is nauwelijks wetgeving of toezicht op de veiligheid en betrouwbaarheid van software, audits en controles zijn meer de uitzondering dan de regel, er zijn geen vastgelegde veiligheidsmarges.

[andreetje]

Mijn ervaring is dat jonge programmeurs soms niet precies weten waar ze mee bezig zijn. Zij gebruiken frameworks waarvan ze de werking niet kunnen doorgronden. Ze doen meerdere keren achter elkaar dezelfde dure aanroep, waardoor de performance beroerd is.

Dat is imho basiskennis.

Dus ja, daar is nog een wereld te winnen. Bugs waarbij systemen in vliegtuigen uitvallen zijn échte onacceptabel. In zulke systemen zou bijvoorbeeld een buffer overflow never nooit mogen voorkomen.

[dmantione]

Het is absoluut basiskennis, maar we moeten ons wel realiseren dat dit soort fouten een gevolg zijn van een mijn inziens dubieuze praktijk in de informatica die al decennia bezig is: We zijn voortdurend bezig geweest om te zorgen dat programmeurs steeds minder zicht hebben op implementatiedetails. Feitelijk zijn we de hele computer aan het zicht van de programmeur aan het onttrekken, zodat ze alleen maar het globale algoritme hoeven in te kloppen.

Vervolgens zitten we nu met de gevolgen dat veel programmeurs ook daadwerkelijk niet meer zien welke gevolgen hun handelen onder de motorkap heeft en er dus allerlei onverwachte gevolgen kunnen optreden.

Ik ben persoonlijk groot voorstander van het onderwijzen van machinetaal aan programmeurs: Niet omdat machinetaal de meest efficiënte vorm van programmeren is, maar omdat het de programmeurs de mogelijkheid geeft te begrijpen wat het gevolg is van één regeltje high-level code.

[84hannes]

dubieuze praktijk in de informatica die al decennia bezig is: We zijn voortdurend bezig geweest om te zorgen dat programmeurs steeds minder zicht hebben op implementatiedetails

Natuurlijk is het onderwijzen van machinetaal en van processorarchitectuur een goed idee. Maar je kunt je als applicatieontwikkelaar niet met individuele transistoren bezig houden. Een spel als Pong was in hardware te ‘schrijven’, een spel als Roller Coasters Tycoon in Assembly, maar een spel als Fortnite wil je in een veel abstractere taal schrijven. Een ontwikkelaar op de bovenste lagen van de software (gui, applicatie etc) kùnnen het zich simpelweg niet veroorloven zich tot in details met onderliggende lagen bezig te houden, juist daarom is abstractie uitgevonden. Als je een webapplicatie schrijft moet je de JavaScript engine kunnen vertrouwen, de JavaScript engine moet de browser/het OS vertrouwen, het OS moet er vanuit kunnen gaan dat de SSD-controller werkt etc. Als je webapplicatie zich met datablocks gaat bemoeien dan komt er echt niets meer van terecht. En gelukkig is de praktijk dan ook dat dit niet meer kan: in Windows 3.1 kon een applicatie nog bij al het geheugen en vermoedelijk iedere bit op een harde schijf uitlezen. Nu heeft zelfs een OS alleen via abstractie toegang tot de SSD (de SSD zorgt er zelf voor steeds andere cellen te belasten) en kan een browser alleen het geheugen lezen dat hem toebehoord, terwijl een website nog veel beperktere toegang tot data heeft.

Ik zou de stelling dan ook liever willen omdraaien: bugs komen doordat softwareontwikkelaars zich teveel met details bezig houden. Ik heb collega's die graag met C werken omdat ze zichzelf wijsmaken dan alle controle in handen te hebben. Maar daarmee hebben ze ook alle verantwoordelijkheid. Wie wil in een programma van meer dan 1000 000 regels verantwoordelijk zijn voor alle mogelijke nullpointer exceptions? Ik niet! Geef mij maar een goed afgebakend stuk software waar ik verwantwoordelijk voor ben: een laag, een module, een class, een functie, maakt niet uit, en de garantie^* dat alles waar ik van afhankelijk ben werkt, dan zorg ik dat mijn stuk zo goed als mogelijk vrij is van software. Hoe ik dat doe? Testen, testen en testen. Op units, op systemen en op complete oplossingen. En juist dat afbakenen en testen, is zoveel makkelijker met bijvoorbeeld C++ of C#/Java dan met C.

Om het in den extreme door te trekken: stap jij liever in

• een vliegtuig waarvan de software door geniale mensen is geschreven die verstand hebben van alles (earodynamica, materiaalkunde, halfgeleidertechnologie, computerarchitectuur, embedded software, applicatiesoftware, kennistechnologie, luchtvaartregels, hmi, artificial intelligence, filesystems, memory managment, EMC etc.) maar beperkt getest (er was geen tijd/budget meer), of
• een vliegtuig waarvan de software is geschreven door mensen met enige kunde op een klein vakgebied, maar onwijs goed getest is?

^*Natuurlijk is vrij zijn van bugs een illusie, waar mensen werken worden fouten gemaakt. Maar hoe kleiner je de code maakt, hoe eenvoudiger het wordt de afwezigheid van bugs aannemelijk te maken.

[Reactie gewijzigd door 84hannes op 22 juli 2024 18:23]

[dmantione]

Nog een reactie op je sterk uitgebreide betoog:

Beide extremen die je schetst zijn ongewenst, de eerste omdat het niet economisch haalbaar is, maar ook de tweede is volstrekt onaanvaardbaar, omdat testen geen enkele garantie geeft hoe de software zich in randgevalsituaties gedraagt. De eerste constatering die je als ingenieur hoort te maken is dat we hier te maken hebben met de zwaarste categorie van betrouwbaarheid die er bestaat: Van het goed functioneren van de software hangen mensenlevens af, niet eentje, niet een paar, maar honderden mensenlevens. Ongelukken zitten in kleine hoekjes: Je vijand hier zijn juist niet de situaties die je kunt testen, maar de randgevalsituaties.

Uiteindelijk moet alles tegen economisch haalbare kosten gebouwd kunnen worden, maar de afweging tussen tijd/budget en betrouwbaarheid weegt in dit geval zwaar naar betrouwbaarheid door. Je weet dat complexe software bugs bevat en om tegen economisch haalbare kosten te kunnen garanderen zul je dan ook moeten snijden in de complexiteit. Talen waarbij er vaak raamwerken van vele megabytes aan software op de achtergrond meegecompileerd worden, daar dien je dan ook zeer snel een rode streep door zetten: Je kunt gewoon niet instaan voor wat er allemaal in die megabytes aan code gebeurt. De kans dat die code in randgevallen ergens faalt is gewoon levensgroot.

Naast testen is het daarom noodzakelijk dat de correctheid beredeneerd kan worden, dat randgevallen waarin hij niet correct functioneert niet bestaan. De correctheid beredeneren is niet mogelijk voor enorm complexe raamwerken, niemand kan de objectgeoriënteerde raamwerken van de talen waar je het over hebt goed doorzien. Je zult je code daarom moeten reduceren tot een overzichtelijk geheel om te kunnen beredeneren dat hij correct is.

Bibliotheekaanroepen, expliciet, of onzichtbaar op de achtergrond (zoals garbage collection) zijn in de regel zo gespecificeerd dat ze correct voltooiien bij voldoende geheugen en voldoende rekentijd. Bij batchverwerking is dit acceptabel. Bij besturing in een vliegtuig hebben we echter vaker dan niet met realtime te maken. Gecombineerd met het niveau van betrouwbaarheid dat hier gewenst is, zijn dan ook vaak garanties nodig hoeveel geheugen en hoeveel rekentijd een aanroep mag verbruiken. Dat is bij expliciete aanroepen al uitdagend genoeg, maar op het moment dat een programmeertaal ook nog eens onzichtbaar op de achtergrond allerlei aanroepen gaat doen, dan wordt het al helemaal onoverzichtelijk en dus: Rode streep.

[84hannes]

omdat testen geen enkele garantie geeft hoe de software zich in randgevalsituaties gedraagt

Waarom zou ik de randgevallen niet testen?

Naast testen is het daarom noodzakelijk dat de correctheid beredeneerd kan worden

Uiteraard. En daarna moeten de correctheid getest worden. Ik neem aan dat jij ook niet akkoord zou gaan met een "Nee meneer, deze pacemaker hoeft niet getest te worden, de correctheid is heel goed beredeneerd". Redeneren ontslaat je niet van de verantwoordelijkheid de software grondig te testen, maar het draagt er zeker aan bij.
Voor een Realtime systeem zou de keus uiteraard niet naar Java/C# gaan, maar ik zou nog steeds liever voor Rust of C++ gaan dan C.

Talen waarbij er vaak raamwerken van vele megabytes aan software op de achtergrond meegecompileerd worden, daar dien je dan ook zeer snel een rode streep door zetten: Je kunt gewoon niet instaan voor wat er allemaal in die megabytes aan code gebeurt.

Je hebt gelijk dat het gebruik van bibliotheken een risico is, maar je kunt jezelf niet wijsmaken dat het zelf schrijven van alle code daarom veiliger is. Voor safety critical oplossingen zou ik ook niet in zee gaan met frameworks als Linux en Qt, die zijn immers niet ontwikkeld met zulke sterke eisen in het achterhoofd en zoals jij ook suggereert een groot gevaar. Aan de andere kant zou ik niet mijn eigen vectoren (slecht voorbeeld bij een realtime system, weet ik) gaan implementeren, dat heeft iemand anders al voor me gedaan en die varianten zijn veel beter getest dan ik van die van mij ooit zal kunnen hopen te doen.

edit:
Je hebt me aan het denken gezet.

Juist het gebruik van een stad::Vec kan desastreuze gevolgen hebben als de programmeur zich de overhead van een volledige kopie niet realiseert, en deze zal dit randgeval dan ook niet testen. Maar de oplossing ligt naar mijn mening in het doorlezen van de documentatie van de bibliotheek, niet in het vermijden ervan. Daarbij mag je na het opstijgen volgens mij toch geen variabelen meer toevoegen aangezien dit allocatie impliceert.

[Reactie gewijzigd door 84hannes op 22 juli 2024 18:23]

[dmantione]

Randgevallen testen faalt om twee redenen:

• Bij software van een beetje complexiteit is het aantal mogelijke invoeren zo groot, dat je nooit alle mogelijke situaties kunt gaan testen.
• Om een randgeval te kunnen testen, moet je het eerst identificeren, waardoor je toch je correctheidsberedenering nodig hebt

Voor wat het tweede betreft laten we een voorbeeld nemen, buiten de luchtvaart: Stel je wilt een rij getallen sorteren. Een naïeve programmeur zal blind een quicksort in een bibliotheek aanroepen, wat dat is het beste sorteeralgoritme. Een beter onderlegd programmeur weet evenwel dat quicksort last heeft van een worst-case, waarin de tijdscomplexiteit O(n²) bedraagt. In een situatie van een webserver of zo, kan een kwaadwillende persoon zo een website overbelasten.

Er is dus een randgeval. waarin het algoritme niet correct werkt. Op het moment dat je deze analyse gemaakt hebt (dus de beredening van correctheid gemaakt hebt), kun je inderdaad specifiek op dat randgeval gaan testen, maar dat is na de beredenering. Op dat moment weet je eigenlijk al dat je algoritme verkeerd is en je een ander algoritme zonder worst-case nodig hebt, zoals shellsort.

Je hebt gelijk dat het gebruik van bibliotheken een risico is, maar je kunt jezelf niet wijsmaken dat het zelf schrijven van alle code daarom veiliger is.

Dat ben ik helemaal met je eens. Zelf alles schrijven is zeker niet beter dan bibliotheken gebruiken. Beter gezegd, die bilbiotheken zijn in veel meer situaties getest dan enkel voor jouw code. Wat je wel wilt doen, is kunnen overzien wat er in die bibliotheken gebeurt. Een sin(x) aanroepen uit een bibiliotheek is nagenoeg risicoloos: Je kunt er vanuit gaan dat de schrijver ervan reeds alles gedaan heeft dat deze in alle gevallen het juiste antwoord heeft en het aantal bewerkingen dat in de aanroep gedaan wordt is constant, geen dynamische geheugenallocatie, en zo voorts. Echter, op het moment dat je minder makkelijk dit soort conclusies kunt trekken, zul je met bibliotheken voorzichtiger moeten worden. Dat betekent niet dat de biblbiotheek noodzakelijk te vermijden is, maar dit is wel het punt waar je je moet realiseren of een eigen routine in het onderhavig geval niet beter te overzien is.

Ik deel ook je bedenkingen over std::vec, daar gebeuren dingen op de achtergrond waar je geen zicht op hebt en in het algemeen is C++ wat dat betreft een taal die je met beleid moet gebruiken: Het is erg krachtig, maar je kunt code er ook redelijk ondoorzichtig mee maken.

[RuddyMysterious]

Een naïeve programmeur zal blind een quicksort in een bibliotheek aanroepen, wat dat is het beste sorteeralgoritme. Een beter onderlegd programmeur weet evenwel dat quicksort last heeft van een worst-case, waarin de tijdscomplexiteit O(n²) bedraagt.

Een beetje programmeur weet dat hij mits een kleine moeite de pivot zodanig kan kiezen dat O(n²) nooit voorkomt, daarvoor is shellsort heus niet nodig.

[dmantione]

Een beetje programmeur weet dat hij mits een kleine moeite de pivot zodanig kan kiezen dat O(n²) nooit voorkomt, daarvoor is shellsort heus niet nodig.

Je verkleint de kans dat hij optreedt, maar de worst-case is er nog wel. Bij het type software waar we het hier overhebben, zou ik er de voorkeur aan geven worst-cases in het programma helemaal te vermijden, zodat je dingen kunt garanderen. Hoe dan ook, of je nu handig de spil gaat kiezen of een ander algoritme kiest, in beide gevallen heb je als programmeur het risico onderkend en het hele plaatje in kaart gebracht i.p.v. blind vertrouwd op de vermeende perfectie van een bibliotheek. Dat is waar het om gaat.

[RuddyMysterious]

Je verkleint de kans dat hij optreedt, maar de worst-case is er nog wel.

Wel nee, als je de pivot kiest volgens de strategie Median of Medians, dan is de worst case máár O(n log n) en niet O(n²).

Voor de rest lijk je niet te geloven in unit-tests.

Er is echter een aanpak die je zou moeten erkennen als goed en volledig: test driven development.

In TDD ga je op voorhand de specs bepalen, per use-case of randgeval eerst op voorhand de test(en) schrijven en adhv van die testen de implementatie incrementeel bekomen, waarbij de testen moeten garanderen dat de code voldoet aan de specificaties, mits die correct en volledig worden gedekt door de unit-tests.

[84hannes]

In de documentatie van std::vector staat wel duidelijk beschreven wat het risico is, dat zou bij code van een collega wel eens minder goed kunnen zijn.

[Znorkus]

Dat lijkt mij ook ja. Software dien je volledig te doorgronden zodat bugs niet plaatsvinden, zgn 'testen' om de bugs eruit te halen lijkt mij de verkeerde kant op werken.

Het grotere probleem lijkt mij er een van ethiek. Het doel is zo veel mogelijk verdienen, niet zo goed mogelijk vliegen. Dan krijg je dit.

[andreetje]

Een programmeertaal moet niet nodeloos ingewikkeld zijn. Ik ben zeker met je eens dat het handig is als een programmeertaal bepaalde zorgen bij je weghaalt (zoals garbage collection).

Er schuilt echter ook een gevaar in. Ik zie programmeurs vijf keer achter elkaar in de code exact dezelfde dure aanroep doen. Ze beseffen niet dat het opslaan en hergebruik van een resultaat zeer veel performance scheelt.

Dus is het prima als je bepaalde zorg en complexiteit wegneemt, maar kennis van het onderliggende systeem blijft hard nodig.

[84hannes]

Ze beseffen niet dat het opslaan en hergebruik van een resultaat zeer veel performance scheelt. Dus is het prima als je bepaalde zorg en complexiteit wegneemt, maar kennis van het onderliggende systeem blijft hard nodig.

Als je performanceproblemen hebt moet je de oorzaak zoeken. Dat doe je door te meten (sterk gerelateerd aan testen). Als de programeeromgeving die jij gebruikt performance profiling niet toestaat, dan moet je op voorhand alles gaan optimaliseren voor performance. De meest veilige code krijg je niet door te gaan optimaliseren voor performance, maar door te optimaliseren voor juist die twee zaken. Naar mijn mening moet je optimaliseren voor leesbaarheid en testbaarheid.

[andreetje]

"Naar mijn mening moet je optimaliseren voor leesbaarheid en testbaarheid."

Ik zal een voorbeeld noemen. Een systeem doet een complexe zoekopdracht op de database.

Wanneer je het resultaat vijf keer nodig hebt, zou je omwille van de leesbaarheid vijf keer de query kunnen uitvoeren.

Voor de performance is dit desastreus.

Slecht leesbare software is problematisch, maar een systeem wat onvoldoende performt kan onbruikbaar zijn.

[84hannes]

Wanneer je het resultaat vijf keer nodig hebt, zou je omwille van de leesbaarheid vijf keer de query kunnen uitvoeren.

Voor de performance is dit desastreus.

Wanneer je hetzelfde resultaat vijf keer nodig hebt dan moet je de query één keer uitvoeren, de data kan immers ondertussen veranderen. Dat is optimaliseren voor correct gedrag.

Als de complexe zoekopdracht inderdaad een bottleneck voor je performance is dan wil je wellicht het resultaat cachen, maar dan moet je ook zeker weten dat je database dat niet al zelf doet. Anders ben je onnodig code aan het toevoegen, en de enige code die gegarandeerd zonder fouten is is de code die je niet schrijft. Dus daarin heb je zeker gelijk dat het nuttig is om de omgeving van je eigen code te kennen, maar een premature optimalisatie is nog steeds een risico voor onderhoudbare code.

[Reactie gewijzigd door 84hannes op 22 juli 2024 18:23]

[Martao]

"Naar mijn mening moet je optimaliseren voor leesbaarheid en testbaarheid."

Ik zal een voorbeeld noemen. Een systeem doet een complexe zoekopdracht op de database.

Wanneer je het resultaat vijf keer nodig hebt, zou je omwille van de leesbaarheid vijf keer de query kunnen uitvoeren.

Voor de performance is dit desastreus.

Slecht leesbare software is problematisch, maar een systeem wat onvoldoende performt kan onbruikbaar zijn.

Dat kan net zo goed andersom gelden. Slecht performende software kan irritatie opleveren, of bakken met geld kosten. Maar slecht leesbare code is niet onderhoudbaar, of kan juist fouten in de hand werken.
Met andere woorden: Zo'n fout kan net zo goed en vliegtuig uit de lucht halen, als een performance probleem.

[Verwijderd]

Een programmeertaal moet niet nodeloos ingewikkeld zijn. Ik ben zeker met je eens dat het handig is als een programmeertaal bepaalde zorgen bij je weghaalt (zoals garbage collection).

Garbage collection is voor veel softwares in een vliegtuig absoluut not done: veel van die systemen zijn real time. Garbage collection is typisch daar totaal ongeschikt voor. Je mag zelfs eigenlijk geen geheugen allocatie tijdens real time processen veroorzaken. Bv. wel initieel. Maar daarna niet meer. Laat staan dat de GC erdoor mag ploegen om die allocaties te gaan opruimen.

[dmantione]

Als je een webapplicatie schrijft moet je de JavaScript engine kunnen vertrouwen, de JavaScript engine moet de browser/het OS vertrouwen

Dit is de kern van de materie: In bepaalde situatie is het onmogelijk om op de onderliggende laag te kunnen vertrouwen. Afhankelijk van de garanties die je moet kunnen leveren. Je moet als informaticus behalve werkende algortimen kunnen bedenken ook in staat zijn om te analyseren of de onderliggende laag voor jouw toepassing aanvaardbaar is. Software voor een vliegtuig schrijf je niet in Javascript, nu niet, en zeer waarschijnlijk nooit niet.

Ik kan me ook goed voorstellen dat ik in een bepaald geval de onvoorspelbaarheid van de onderliggende SSD-algoritmes een risico zou vinden en bijvoorbeeld zou terugvallen op EEPROM voor maximale betrouwbaarheid (NAND-flash = duizenden cycli, EEPROM is honderdduizenden cycli).

[Reactie gewijzigd door dmantione op 22 juli 2024 18:23]

[dev10]

Mijn ervaring is dat jonge programmeurs soms niet precies weten waar ze mee bezig zijn.

Wat heeft leeftijd te maken met de kunde van de programmeur? Er zijn meer dan genoeg oudere programmeurs die ook niet weten waar ze mee bezig zijn en er zijn ook genoeg jonge programmeurs die heel goed weten waar ze mee bezig zijn.

[Crew One]

De kwaliteit van het onderwijs, om mee te beginnen.

"In mijn tijd" (jezus, ik word een oude zak) werd er nog machinecode, processor- en compilerontwerp en wiskundig bewezen software ontwikkeling onderwezen op de universiteiten.

We zijn al jaren bezig in ons bedrijf met het werven van goede mensen, maar eerlijk... de meeste programmeurs die we vers van de HBO's of universiteiten krijgen hebben geen flauw benul van hoe een computer, processor, programmeertaal en uiteindelijk hun eigen software werkt. Laat staan dat je ze kan lastigvallen met wat complexere programmeerproblemen.

Ik realiseer me dat ik hier wellicht bevooroordeeld ben, maar de optiek binnen ons bedrijf is wel dat de kwaliteit van de mensen die de HBO's en universiteiten afleveren de afgelopen 15 jaar niet is toegenomen. (... als het gaat om informatici.)

Dus alhoewel slimme mensen van alle tijden zijn, is het type softwareontwikkeling dat word onderwezen denk ik wel van invloed op de kwaliteit van de software die door die generatie - in grote lijnen - word afgeleverd.

[Reactie gewijzigd door Crew One op 22 juli 2024 18:23]

[andreetje]

Dat is misschien geen wet van Meden en Perzen, maar in het algemeen kun je stellen dat jonge mensen minder kennis en ervaring hebben.

[dev10]

Dat ben ik ten dele met je eens: kennis en kunde heeft zoals ik eerder zei weinig met leeftijd te maken. Dat iemand die ouder is meer ervaring heeft is logisch, maar zeker geen vast gegeven omdat de ervaring niet relevant hoeft te zijn.

Even een heel simpel voorbeeld: ik ben nu 30 jaar en begon ongeveer 12 jaar geleden met werken. Ik heb dus 12 jaar ervaring als developer. Dagelijks werk ik nu met PHP met Laravel, MySQL, Redis, TypeScript en React. Toen ik begon met werken, bestonden alleen PHP en MySQL. Dus dat ik 12 jaar ervaring heb met PHP en MySQL is leuk, maar het is maar ten dele relevante ervaring omdat de rest van de technieken en software allemaal later zijn gekomen. Daar komt bij dat PHP en MySQL er 12 jaar geleden heel anders uitzagen dan nu en eigenlijk geldt dat voor bijna alles in de development hoek. Dus ik heb heel leuk 12 jaar werkervaring, maar ik heb geen 12 jaar relevante ervaring met het werk dat ik nu doe.

En ik weet zeker dat er nu mensen afstuderen die betere programmeurs zijn dan ik, ondanks m'n 12 jaar ervaring.

[andreetje]

Beter opgeleide mensen zullen betere programmeurs zijn.

Maar bij gelijke opleiding zal de ervaring toch écht winnen.

[84hannes]

Wat ik veel merk is dat software ontwikkelaars die langer in het vakgebied hebben meer domeinkennis hebben, maar niet of veel minder op de hoogte zijn van ontwikkelingen op softwaregebied. Unit testen, continue integratie, versiebeheer, maar ook meer expressieve code schrijven en refactoring zijn daardoor vaak ondergewaardeerd bij deze ervaren krachten.

[RuddyMysterious]

Toevallig een clean code aanhanger? ;-)

[84hannes]

Uiteraard!

[BoozeWooz]

https://i.imgur.com/rNKfs38.png

763 dagen zonder reboot. Productie omgeving, dus elke seconde reboot is downtime.

Onze dev machine:

https://i.imgur.com/xVa6dFM.png

Zelfs voor update van de kernel zijn reboots tegenwoordig niet eens meer nodig, door dit soort grappen; https://linux-audit.com/l...pdates-without-rebooting/ Dus er is geen excuus waarom dat niet zonder zou hoeven kunnen.

[Reactie gewijzigd door BoozeWooz op 22 juli 2024 18:23]

[dev10]

Productie omgeving, dus elke seconde reboot is downtime.

Dus elke seconde storing ook? Als die machine zo belangrijk is dat hij 763 dagen niet gereboot is, zou ik toch eens gaan kijken of je die niet kunt dupliceren.

[Bergen]

Leuk die uptimes, maar dat betekent ook dat je kernel al zo lang niet is voorzien van bugfixes.

[BoozeWooz]

https://ubuntu.com/livepatch

[Seal64]

Eh, Linux v4.x en hoger kan de kernel updaten zonder reboot.

[Martao]

Wat is je punt precies?
Ik had het alleen maar over onrealistische eisen voor (veelal onbeduidende) consumenten producten, omdat iemand daar over begon.
Dan heb ik het dus duidelijk niet over een "productie omgeving", whatever that may be.

[Corrigan]

@pauldebra heeft het anders goed begrepen. Jij blijkbaar niet wanneer je een workaround als een reboot goed probeert te praten als een eind oplossing. We hebben het niet over een vaatwasser maar over vliegtuig!

Repareren die code en anders die programmeurs eruit gooien!

[mbbs1024]

In het artikel staat ook dat er een reparatiecode voorhanden is, maar dat tot die code geïnstalleerd wordt, de periodieke reboots moeten uitgevoerd worden.

[Martao]

Ik praat helemaal niks goed voor dat vliegtuig. Ik reageer alleen op onrealistische claims van de schrijver, o.a. over dat goede programmeurs met voldoende tijd geen fouten maken.

Dat is gewoon utopisch. Je kunt veel beter de risico's inschatten en uitgaan van fouten en vervolgens zorgen dat je daar mee om kan gaan. Zoek bijvoorbeeld eens naar het chaos monkey principe dat Netflix hanteert.

[wjn]

Sorry hoor, maar onze netwerk apparatuur draait ook soms 2160 uur en meer zonder problemen. Enige reden om te rebooten is meestal een software update (en die komen regelmatig) om CVE's te fixen.

Dus ja, er zitten fouten in de firmware (getuige de CVE's).
Dus nee, er is geen reden om te rebooten omdat anders ergens de communicatie (deels) uitvalt.

Dan hebben we het over apparaatjes van een paar 100 euro.

Apparaten meer voor consumenten wordt inderdaad veel bespaart, wat gewoon irritant is.

On topic: Bij een vliegtuig van 250+ miljoen moet dat beter kunnen. En er zijn dus al fixes die het probleem oplossen.

[Dabbel]

De TV bij de mcDonalds moet 24/7 draaien. De TV bij de tankstation moet 24/7 draaien. De TV in het hotel moet 24/7 kunnen draaien. Ga zo maar door.

Het gaat daarnaast niet om dat een vliegtuig ALTIJD 24/7 operationeel is. Als er calamiteiten zijn, bijvoorbeeld als je op Schiphol niet kan tanken. Dan moet een vliegtuig misschien een aantal vluchten overnemen en zodoende geen tijd hebben voor herstart procedure.

Verplaats het eens in een ander situatie. Niet alles draait om de TV bij jou thuis.

[fsfikke]

De TV bij de mcDonalds moet 24/7 draaien.

Wat zijn de consequenties als deze TV uitvalt? Zijn die te vergelijken met de uitval van een essentieel onderdeel van een vliegtuig?

[Dabbel]

Als je de hele discussie hebt gevolgd, ipv ergens in het midden aanhaken, dan weet je dat het niet daarom draaide. Ik reageer op iemand die het over tv’s heeft.

Daarnaast geeft ik in mijn een post een argument over waarom vliegtuigen non stop moeten kunnen werken. Maar schijnbaar heb jij daar geen tegenargument voor.

[Reactie gewijzigd door Dabbel op 22 juli 2024 18:23]

[84hannes]

Als ik ook een deel van de discussie uit zijn context mag trekken, je geeft zelf al aan dat een vliegtuig ook moet tanken

[Dabbel]

Als vliegtuig A per direct retour moet om een vlucht van vliegtuig B over te nemen, omdat B geen kerosine heeft. Hoe heeft A tijd om een reset te doen?

[84hannes]

Ik denk dat een vliegtuig niet 149 uur op één tank kan vliegen. Het lijkt me ook niet dat je het op een paar uur aan laat komen. Anderzijds zou het me niets verbazen dat de software tijdens het tanken blijft draaien.

[Dabbel]

En bij hoeveel uur ga jij die resets doen dan? Na elke vlucht? Na 50u? Na 100u? Er zijn strikte onderhoudsschema‘s waar engineers en piloten aan moeten houden. Een herstartprocedure van een kritisch onderdeel wordt geagendeerd, structureel uitgevoerd en niet ff zomaar flexibel uitgevoerd. Als vandaag reset is gepland, dan kan het vliegtuig niet per abuis vertrekken om in te vallen. Ben je koppig of gewoon aan het vervelen?

[Houtenklaas]

Het feit dat je het acceptabel vind dat een consumentenproduct fouten mag bevatten vind ik behoorlijk discutabel. Natuurlijk, als ik mag kiezen tussen een bug in mijn TV of een vliegtuig, dan is de keuze snel gemaakt. Maar beiden horen zonder fouten afgeleverd te worden, zo simpel is het. Qua complexiteit zijn consumentenproducten - vergeleken met vliegtuigen - geen rocket science. Goedkope programmeurs die nodig zijn om de "race to the bottom" vol te houden zorgen ervoor dat fouten voorkomen, consumenten die die goedkoper rommel kopen vinden het vervolgens acceptabel dat je af en toe een stekker eruit moet trekken. Absoluut laakbaar gedrag van zowel consumenten als bedrijven.

Wat @Goof2000 al meldt, ook hier staat de TV 24/7 aan, om dezelfde reden dat het minuten duurt om dat ding vanaf 0 te booten. Programmeurs opleiden in het juiste gedrag is glashard nodig, het is een vak wat helaas te vaak door broddelaars wordt uitgevoerd. Alleen die insteek van @pauldebra naar zijn studenten is al +3 waard. Vakkennis, liefde voor het vak, de juiste mentaliteit ... Mijn elektronica leraar op de ETS (wat is dat lang geleden) in Amsterdam heeft ooit die liefde mij bijgebracht en bepaalde kwaliteitsnormen in het vak... Ik ben die man daar nog steeds dankbaar voor. Te lage kwaliteit is gewoon onacceptabel, voor TV's en zeker voor vliegtuigen.

[84hannes]

Softwareontwikkelaars maken fouten. Softwareontwikkelaars lossen fouten op. Dat heeft niets met liefde voor het vak te maken, daar wordt je gewoon voor betaald. Als productmanagement het nodig vind een product met fouten te verkopen dan gebeurt dat. Als productmanagement wil wachten tot absoluut alle fouten er uit zijn komt er nooit een product uit en gaat het bedrijf failliet. Als een product met teveel fouten wordt uitgebracht gaat het bedrijf uiteindelijk ook failliet. Het is een balans die bepaald wordt door allerlei factoren, maar gebrek aan liefde voor het vak is niet de reden dat er bugs bestaan.

[Houtenklaas]

Grappig dat iedereen leest wat hij of zij wil lezen en de rest van wat er staat volledig lijkt over te slaan. En dat je er dingen bijhaalt die er niet staan. Maar goed, er staat ook nergens dat gebrek aan liefde alleen de oorzaak is. Het helpt echter wel, net het verschil tussen "gewoon" je werk doen en pareltjes afleveren. Presteren als een zesje of een 8. En blijkbaar gaan we tegenwoordig voor de zesjes. Jij bent developer zie ik, ga jij akkoord als iemand op driekwart van jouw development cycle zegt dat het goed genoeg is? Daar heb jij dan geen moeite mee dat iets wat niet goed getest is productie in gaat? Ik kan me dat slecht voorstellen, maar het lijkt uit je woorden dat je daar vrede mee hebt omdat "product management" dat nu éénmaal wenst ... Het hoeft echt geen 10 te zijn, maar een 6, daar ga ik niet voor.

[Martao]

Ik snap bij god niet waarom je denkt dat ik lage standaarden of lage kwaliteit goedpraat.
Alleen, wat je normen ook zijn: fouten zullen gemaakt worden. Dan is het alleen zaak hoe je er mee om gaat. Bij bedrijven gaat het dan om een stukje service, bij software kan het erom gaan dat afhankelijke systemen er mee om kunnen gaan dat er iets fout gaat.

Daarnaast is er nog zoiets als redelijke eisen, en dat is iets waar ik op doelde. Lekker boeiend als ik eens in de 2 weken mijn tv-ontvanger aan/uit moet zetten. Daar zitten simpelweg heel andere eisen aan dan aan een controle systeem in een kerncentrale of vliegtuig.

[Houtenklaas]

Dan zijn we het daarover eens. Maar je bevestigt precies waar de angel zit: Je vindt het prima om een slecht geprogrammeerd product met regelmaat te rebooten. En daarmee praat je wel degelijk een lage kwaliteit goed. En daarmee sluiten we af!

[Suspiria]

Waar het om gaat is dat vliegen al ingewikkeld genoeg is.
Wat je niet wil is dat er met dit soort dingetjes überhaubt rekening mee gehouden moet gaan worden.
Je kunt deze bugs alleen wegwuiven als er daadwerkelijk geen enkel denkbaar scenario is waarin het een probleem is.

Tijden veranderen. Ineens heeft iemand een goed idee om het vliegen anders te gaan doen.
En vergeet men dat deze bugs aanwezig zijn, omdat men ze heeft afgedaan als non-issue.

Dus er moeten dan mensen gaan zijn die dit dan "in het achterhoofd" moeten gaan houden.
Dat is nogal wat.
Het lijken misschien kleine dingetjes, maar zeker als er een opeenstapeling van dit soort dingetjes is hoef ik zo'n schip niet meer te vliegen hoor. Ik wil niet nèt tussen de limietjes door moeten werken, omdat het - in theorie - gewoon goed *zou* moeten gaan zo.

Daarnaast is het mijn ervaring dat waar zo'n bug aanwezig is vaak een indicatie is van een verminderde concentratieboog en onverzorgd stuk programmeerwerk. Het is "goed", maar net niet helemaal afgewerkt. En soms leidt zo'n klein bugje dan ook tot een "Oooh, trouwens", en blijkt er nog meer in die richting niet te kloppen en heeft dat stukje algo nog wat tlc nodig.

Verder is er een psychologisch effect van ons "reticular activating system", dat als we er een gewoonte van gaan maken om dit soort bugjes af te doen als non-issues, dat dan de scherpte voor het ondekken van bugs in het algemeen af zal nemen. Immers, het voelt toch iedere keer zinloos. "Non-issue" dreunt door.

"Tsjah, laat ook maar dan." zou het antwoord kunnen zijn.
Dat wil je echt niet met dit soort dingen. Dus laten we vooral voorzichtig zijn met dit soort dingen als "non-issue" te bestempelen. Want mensen blijven emotionele wezens en ook jouw woorden hebben invloed.

[Fijinees]

In industrie draaien systemen weken en maanden zonder reboot. Het is echt wat anders dan die pc op je werk, die rustig 8 uur per dag uit mag.

Je werkt denkelijk in een kantooromgeving

[Martao]

In industrie??? We hadden het over tv ontvangers en koffiezet apparaten hè? Get your context straight. Dit is precies mijn punt: verschillende systemen hebben andere eisen.

[Tijgert]

Ik vind het zelfs bij een vliegtuig en vreemd verhaal. De meeste toestellen zullen snachts aan de grond staan. Zouden er dan systemen zijn die desondanks 24/7 operationeel zijn? Oké, er zijn misschien (vracht)vliegtuigen die doorlopend op pad zijn, dat zijn uitzonderingen, maar die moeten ook blijven vliegen natuurlijk

Vliegtuigen die ‘s nachts stilstaan zijn juist de grote uitzondering. Waarom denk je dat Schiphol ‘s nachts bijna leeg is?
Vliegtuigen moeten zoveel mogelijk uren maken om de kosten terug te kunnen verdienen.
Als je de vloot goed managed en aan het werk zet dan moet je zelfs gaatjes forceren voor onderhoud.

[Fly-guy]

Bugs blijven bestaan omdat het nu eenmaal mensenwerk is en mensen maken foute, ook in vliegtuigen, ook door goede programmeurs.

En feit blijft dat vliegtuigen steeds meer een computer worden, waardoor het aantal regels code exponentieel toeneemt en daarmee ook de kans op bugs.

[andreetje]

Dan zou er beter geprogrammeerd en getest moeten worden in de plaats van dat we accepteren dat vliegtuigen uit de lucht vallen omdat de software te complex wordt.

Je kunt je zelfs afvragen of verdere en complexere automatisering wel de juiste weg is.

[SideShow118]

Testen en bugs zijn een afweging van risico tegen tijd.

Wie weet zit er wel een bug in de software die zich voordoet als het spulletje 15 jaar niet is gereboot. Hoe ga jij dit testen?

Je moet accepteren dat er een foutmarge is. Die foutmarge wordt in kritieke systemen natuurlijk zo laag mogelijk gehouden maar 100% garanderen kun je het niet.

"Beter geprogrammeerd en getest worden" is zo'n inhoudsloze politieke term dat ik niet weet waar ik moet beginnen.

Automatisering staat ook niet gelijk aan groeiende complexiteit. Vliegtuigen worden complexer omdat we steeds meer leren en de toestellen beter worden. Daar zitten nu eenmaal kinderziektes in die je nooit helemaal kunt voorkomen. Het is aan jou om te bepalen of het risico om het vliegtuig te pakken voor jou acceptabel is. Het is aan de autoriteiten om te bepalen of de risicoafweging van vliegtuigbouwers acceptabel is.

[andreetje]

Velen van ons kennen de realiteit van projecten die uitlopen en deadlines die gehaald moeten worden.

We weten dat onervaren programmeurs veel begeleiding nodig hebben en een risico vormen.

Ook weet iedereen dat onder grote tijdsdruk de kans op fouten groter is.

Testen gebeurt achteraan in het traject, en als het moment van opleveren gekomen is, komt test in tijdsdruk, kan er niet volledig meer getest worden laat staan dat bugs nog opgelost worden.

De opmerking "Dan zou er beter geprogrammeerd en getest moeten worden" dekt de lading dus volledig.

[SideShow118]

Velen van ons kennen de realiteit van projecten die uitlopen, correct. Hoeveel mensen kennen die realiteit op projecten van levensbelang?

Dat er beter geprogrammeerd en getest moet worden dekt in de context van dit nieuwsartikel helemaal niet de lading. Wat is beter?

Beter programmeren zodat je niet meer hoeft te testen? Beter testen zodat je alle bugs vindt? Alles 100% uitsluiten?

Hoe vaak worden de testen prima uitgevoerd en besluit men om niet te wachten op de fixes? Of "kunnen we ondanks de bevindingen toch gewoon live?"

Al zet je foutloze programmeurs in en voer je 100% testen uit, dan nog kun je niet alles uitsluiten.

[Reactie gewijzigd door SideShow118 op 22 juli 2024 18:23]

[andreetje]

Daar ben ik het mee eens. Je sluit het nooit 100% uit.

[Fly-guy]

Er zijn nu inderdaad gevallen bekend waarbij er niet voldoende getest of zelfs nagedacht is, maar heb niet de illusie dat ooit alle bugs uit een code gehaald kunnen worden voordat het op de markt komt.

Deze bug uit het artikel is iets wat meer testen niet altijd opvalt maar ook niet heel kritisch is.
Door de genoemde opdracht is het effect van de bug inmiddels nul en zal deze na een tijdje met een update verholpen worden.

[kaasboer09]

Ik ben geen programmeur dus helaas kan ik niet inhoudelijk reageren op de kwaliteit van de software. Maar ik ben het met je eens dat je mag verwachten dat een vliegtuig software gebruikt van de beste kwaliteit.

Wat betreft de "non-issue" status denk ik dat ik het wellicht verkeerd omschreef. Onderhoud van een vliegtuig is dagelijkse kost. Voor elk type vliegtuig komen elke dag meerdere "service bulletins" binnen. Geregeld zijn deze bulletins gemarkeerd als kritisch, wat vaak inhoudt dat een vliegtuig niet eens mag opstijgen voordat het probleem is verholpen. In die context is de impact van deze specifieke software bug dus erg laag.

[Martijn.C.V]

Het is onmogelijk om bug vrij te programmeren. Ik ben programmeur en ik ken geen (con-)collega die het niet eens is met dat statement. Het is onmogelijk bugvrij te programmeren, punt.

Het ding is namelijk dat het aan zoveel factoren kan liggen...
- Als eerst heb je de code. Een programmeur denkt niet aan alles en/of kan een probleem oplossen wat (achteraf) niet handig blijkt.
- Dan moet jouw code samenwerken met iemand anders code. Kan zijn dat de spec's besproken zijn, en net een haar anders geinterpreteerd.
- Dan zijn er code reviews waar mensen elkaar code na te lezen/dubbelchecken
- Dan zijn er menselijke tests die alles doorlopen
- Dan komen er automatische tests (die geschreven worden door mensen) die alles blijven nalopen elke test

Stel, elke stap gaat 95% goed (best netjes right?), en het wordt 1000x uitgevoerd. Vijf checks, elke stap vangt een stuk fouten van de vorige ronde op, resultaat: 99.99% zeker werkende code, nice toch? Maar nu is t opeens 1.000.000x afgezet, dan heb je 1.000 fouten! En zelfs als je nog een check weet te maken van 95%, zijn er nog steeds 50!

De catch is, die 50 zijn zeer goed verstopt, anders hadden ze het nooit zo ver gered om nog te bestaan. En waarschijnlijk komen daar 49 nooit van aan het licht omdat de vereisten niet voldoen om de bug te laten ontstaan.

Hoe goed je ook controleert en checkt, zijn er altijd nog situaties als op de 6e maandag van de maand, terwijl er volle maand is, je klikt met links omdat je rechterhand net tussen de deur kwam, terwijl net je kat over het toetsenbord loopt en de buurman hard meezingt met een nummer.

[Reactie gewijzigd door Martijn.C.V op 22 juli 2024 18:23]

[Verwijderd]

Het is onmogelijk om bug vrij te programmeren. Ik ben programmeur en ik ken geen (con-)collega die het niet eens is met dat statement. Het is onmogelijk bugvrij te programmeren, punt.

Nuja. Het is erg moeilijk. Maar niet onmogelijk. Zoals je weet zou ik hier een 100% bugfree hello world kunnen maken. En er zijn ontwikkeltechnieken (die bijna niemand gebruikt) die wiskundig bewijzen dat je geen bugs hebt.

Je haalt aan dat je afhankelijkheden hebt waarin ook bugs zullen zitten. Dat is één van de belangrijkste reden waarom volledig bugfree software ontwikkelen zo moeilijk is.

Een andere reden is dat de industrie zo enorm snel wil gaan, dan men vaak de tijd niet maakt om rustig en serieus dingen te ontwikkelen die erg goed zijn (en vooral, die ook echt getest werden - i.p.v. dat men zichzelf wijsmaakte dat het echt getest werd). Met als meest waanzinnige groep de Internet Of Things ontwikkelaars. Die maken er echt een potje van. Met deursloten die vanop afstand open te doen zijn, babyfoons die je vanaf het Internet kan bekijken, routers met gelekte private keys op de SSH, je kan het zo gek niet bedenken of de IOT mensen hebben het al herhaaldelijk veroorzaakt.

[Martijn.C.V]

Ben jij 100% zeker dat jouw 'hello word' werkt op 100% van de machines waar je het op draait? En wat nou als teveel mensen het opvraagt? En wat als er misschien een bug zit in de hostsoftware die alleen in vage situaties voorkomt? Mag wel mooi zijn dat jouw code goed werkt, maar in alle gevallen ben jij ook de eindverantwoordelijke, had je t maar moeten testen op alle host software.

Onmogelijk dus. Enkel goed reduceerbaar. (en lees nu mijn antwoord nog eens, maar dan met duizenden regels code).

[Reactie gewijzigd door Martijn.C.V op 22 juli 2024 18:23]

[Verwijderd]

Ben jij 100% zeker dat jouw 'hello word' werkt op 100% van de machines waar je het op draait?

Voor Hello world kan ik daar 100% zeker van zijn wanneer jij mij de specificaties van die 100% van de machines geeft. En dat laatste zal je moeten doen, want "alle machines" is geen specificatie. Dan moet ik het ook op een schop en een schoen laten draaien (die nog geen computer aan boord hebben voor één of andere dwaze IOT reden).

[Zeerob]

Nuja. Het is erg moeilijk. Maar niet onmogelijk. Zoals je weet zou ik hier een 100% bugfree hello world kunnen maken. En er zijn ontwikkeltechnieken (die bijna niemand gebruikt) die wiskundig bewijzen dat je geen bugs hebt.

Toen destijds de Maeslantkering gebouwd werd, las ik eens dat voor de software ontwikkeling zo'n techniek gebruikt zou worden. Ik had er toen al mijn bedenkingen bij.
Later las ik dat er toch allerlei fouten in de software zaten, en dat die helemaal niet zo betrouwbaar was geworden als eerder beloofd.
https://www.computable.nl...weg-dubbel-beveiligd.html
https://www.win.tue.nl/~jfg/articles/AGapril2006.pdf

[dmantione]

Klopt, net zoals dat je op papier een redenering kunt opschrijven dat iets correct is, kun je dat formaliseren en op die manier je bewijsvoering onderdeel van de routine maken en softwarematig ondersteunen. Zoiets garandeert echter geenzins dat in de praktijk geen situaties voorkomen waar in je in je ontwerp rekening mee hebt gehouden en het vereist ook zeer discilplinematig werk om te zorgen dat je het juiste bewijst.

Zulke methoden zijn daarom louter een hulpmiddel en garanderen op zichzelf geen foute software. Omdat het vrij bewerkelijk is een veel praktijkdingen (zoals geheugenallocatie) lastig in de modellen te vatten zijn waarvan je de correctheid gaat aantonen wordt het niet heel veel gebruikt. Maar in de basis is het wel waar dat er methoden bestaan waarmee de afwezigheid van bugs in een stukje code aangetoond kan worden.

[casberrypi]

Een van de bugs in een traditionele hello world applicatie is de representatie van de binaire data in de sourcefile (dus de string 'hello world') tot een voor mensen leesbare tekst. Dit gaat dus grandioos de mist in als je terminal een andere character encoding heeft dan die waarin de programmeur werkte.

[FlyingDutchMen]

Helaas is dit steeds meer een issue aan het worden. Efficientie is tegenwoordig een minder belangrijk ding dan het vroeger was. Door de shift van deze focus komen er naar mijn idee steeds meer "undocumented features" tevoorschijn. Ook het ach de carbagecolletor ruimt het wel op idee wordt helaas te veel gebruikt, dit is natuurlijk in behoorlijk wat gevallen correct, maar dan moet je hier wel zeker over zijn en het correct implementeren.

Slightly offtopic
Daarnaast heb ik ook echt iddues met de hoeveelheid producten die niet werken zonder een verbinding te hebben met een bepaalde server. Ik kan hier echt slecht tegen. Oke bepaalde functionaliteit kan het niet doen omdat deze de server nodig heeft, helemaal prima. Maar meestal is het niet nodig om direct het gehele product onbruikbaar te maken. Fabrikanten zijn daarnaast ook nog niet echt gewend dat ze deze servers/software up and running moeten houden tot dat er nagenoeg geen gebruikers van dit product meer zijn.

[dmantione]

Juist garbagecollectors zijn in dit soort situaties iets waar je met een grote boog omheen moet lopen, omdat je als programmeur geen zicht hebt op wat de garbagecollector op de achtergrond doet. Je kunt niet voorspellen of de garbagecollector eventjes de processor een tijd blokkeert om op te ruimten, of dat je wellicht een worst-case kunt realiseren, waarin hij zeer inefficiënt wordt en geheugentekort kan optreden.

Er bestaan geautomatiseerde hulpmiddelen die niet gedealloceerde geheugenblokken kunnen terugleiden naar de programmaregel waar ze gealloceerd zijn. Daarmee moet je geheugenallocatiebugs opsporen.

[dingo35]

Sterker nog, het is in het ontwerpen en bouwen van realtime software (en daar hebben we het over in het geval van communicatie-modules) is het absoluut not done om te werken met dynamische allocatie van geheugen. En als je alleen maar met statische declaraties werkt heb je helemaal geen garbage collector nodig.

[holoduke51]

Zeker geen programmeur. Want memory leaks kunnen aanwezig zijn zonder dat deze direct naar boven komt tijdens de bouw van de software. Het kan veroorzaakt worden alleen in bepaalde edge scenarios. Een combinatie van dingen. Het is absoluut niet zo simpel als jij het zegt.
Daarnaast staat nergens dat het een memory leak is. Misschien is het wel een floating point issue. Of een log die vol loopt. Het kan echt van alles zijn.
Software is nooit foutloos. En met de juiste procedures. Zoals in dit voorbeeld het geval is, zal de concequentie tot een minimum beperkt blijven.
Ik zie deze bug bij Airbus dan ook niet als iets ergs. De media vindt het vooral leuk om op te blazen.
Je moest eens weten hoeveel bugs er niet naar buiten sijpelen.

[Ralph58]

Een simpele timerfout is best wel erg.

[michaelmou]

Dit soort bugs bestaan omdat er mensen aan de code werken. Boeing heeft destijds een team met vrij onervaren programmeurs aan het werk gezet; waarschijnlijk om geld te besparen.

[Reactie gewijzigd door michaelmou op 22 juli 2024 18:23]

[Verwijderd]

Correct. Uitbesteden naar landen zoals India. Niet om het e.a, maar zulke software audit je fatsoenlijk. Er zijn een hoop mensen overleden na een vlucht. We spelen niet met een spelletje hier. Mensenlevens staan op het spel. Dan maar de vliegtax omhoog met 10% per ticket.

[g4wx3]

Outsourcen is kan heel goed werken, maar zorgt wel altijd voor stress binnen een bedrijf. De interne programmeurs die werkt aan de cruciale software, voelde de hete adem van de manager die succesvol zijn project extern liet ontwikkelen.

[bussie66]

Ik ben geen programmeur en vraag me af kunnen dit soort bugs niet ondervangen worden in de software waarmee ontwikkeld wordt?

[MrBreaker]

Dit is een stap richting Idiocrazy.

Perfect voorbeeld wat je aanhaalt van de 737-Max.

Tegenwoordig zijn het de mensen ongehinderd door enige kennis die de cepter zwaaien.

Hoe vaak hoor ik een CEO een verhaal afsteken, wat nog kant nog wal raakt .

[Ralph58]

Dat is dan ook de taak van een CEO en hij verwacht van programmeurs dat die precies het tegenovergestelde doen.

[correcto]

In de tekst is ook te lezen dat er allang een fix voor dit probleem is. Het probleem wordt zeker niet door iedereen als een non-issue gezien. Dus in plaats van elke x uur het vliegtuig rebooten zouden ze ook de fix kunnen installeren?

[TD-er]

149 uur = 536400 seconden.
2^31 (max van 32-bit signed integer) / 149 uur is vrijwel 4000.
Oftewel er is kennelijk een interne klok ergens die 4000x per seconde tikt. (of 8000x bij 32-bit unsigned integer)
In embedded systemen is het heel gebruikelijk om de tijd te monitoren door de interne klok op te slaan in een variabele, je ding te doen en dan te vergelijken met de dan geldende "tijd".

Bijv: (gebruik hier als voorbeeld milllis() aangezien dat in Arduino veel voorkomt)

[code]
unsigned int start = millis();
doYourStuff();
unsigned int end = millis();
unsigned int duration = end - start;
[/]
Echter wat gebeurt er nou als je end < start?
Met de klok in dit systeem kan dat elke 149 uur gebeuren.
Dan is de tijdsduur van je taak ineens niet meer zo kort als je verwacht (bijv. paar-100 msec) maar ineens nagenoeg 149 uur.

Bij het berekenen van hoelang iets geduurd heeft is het misschien nog niet zo'n ramp, maar bij het bepalen hoe lang je moet wachten voor je iets nieuws mag doen kan het wel heel vervelend zijn.
Als de interne scheduler bijv. stelt dat je iets moet uitvoeren op millis() + 1000.

Dit soort fouten zijn heel snel te maken en persoonlijk ben ik er dan ook groot voorstander van om alle tijd-gerelateerde berekeningen door een eigen functie te laten doen ipv. start en eind simpelweg van elkaar af te trekken.
Dit soort dingen lijkt vaak triviaal, maar is het zeker niet omdat je een foutje heel snel kunt maken en dat kan heeeeeeeel lang onopgemerkt blijven en is ook vrij lastig te testen omdat het eigenlijk voor moet komen precies rond het tijdstip waarop de teller een overflow krijgt.

Eigenlijk is dit een mini millenniumbug.

[JackBe]

"Echter wat gebeurt er nou als je end < start?"
Velen denken dat dit fout gaat, maar het verschil is nog steeds correct.
Gewoonlijk zijn die variabelen een uint32_t.
Het wordt een probleem als je een verschil in tijd wilt bepalen, die zo lang is dat er mee dan 1 roll-over plaatsvond.

[Reactie gewijzigd door JackBe op 22 juli 2024 18:23]

[TD-er]

Velen denken dat dit fout gaat, maar het verschil is nog steeds correct.
Gewoonlijk zijn die variabelen een uint32_t.

Klopt, maar het verraderlijke is dat je vaak over 't hoofd ziet wat er fout kan gaan.
En dat is ook wat ik al beschrijf.
Je kunt concluderen dat de tijd verstreken inmiddels ruimschoots overschreden is. Dat is meestal niet zo'n probleem (bijv. kijken of een waarde bijgewerkt is is niet erg als je dat iets vaker doet dan strict noodzakelijk)

Maar als je het verschil gebruikt om te bepalen hoe lang je nog moet wachten is dat wel een probleem.
Dan is het van een paar 100 msec (typische wachttijden in embedded systemen) ineens bijna 150 uur in dit systeem.
Oftewel de manier hoe je een dergelijk verschil inzet is heel erg bepalend of de bug optreed. en de ernst ervan.
En het echt frustrerende is dat je dit soort bugs keer op keer terug ziet komen, terwijl je er heel simpel omheen kunt werken door dit soort ogenschijnlijk triviale zaken in een functie te vatten en die ook echt overal gebruiken.

[THA_ErAsEr]

Wat een onzin. Ooit in de IT gewerkt? Achter elk project zit een heel team. Analist, developer, tester, integratie tester. Een GOED team zou dit nooit mogen voorhebben. Elke mens maakt nu eenmaal fouten en bekijkt zaken anders. Daarom bestaan er ook testers. Anders had je enkel enkele senior developers nodig. En van alle bugs die je kan bedenken zijn memory issues wel bij de dieren die het makkelijkst door de glazen van het net glippen.

Niemand verdedigt dat dit mag gebeuren, zeker niet een vliegtuig waar vele mensen levens op het spel staan. Als deze personen geen "goede programmeurs" zouden zijn, zouden ook niet bij airbus binnen raken.

[scholtnp]

"Een goede programmeur (die ook voldoende rust en tijd krijgt)..."

De programmeertaal Rust bedoel je?
https://www.rust-lang.org
Helemaal mee eens! Al die memory- en overflowproblemen de wereld uit! Zie ook het stukje over reliability op die site.

[HuisRocker]

Je noemt de 737-MAX, maar dat is een heel andere zaak! Namelijk leuk al die focus op software, sensoren, developers, piloten, trainingen, enzovoort, in dat geval maar de 737-MAX zou voor die taak helemaal geen sensor en/of software (of alles daarna) nodig moeten hebben om te kunnen blijven vliegen...

Boeing heeft dit gedaan om een fout in het ontwerp te verdoezelen, het vliegtuig is in de lucht namelijk niet "van nature stabiel" (wat een passagiersvliegtuig wel altijd zou moeten zijn) vanwege andere motoren in een andere positie t.o.v. de vorige 737's.

[Ralph58]

Dat is geen enkel probleem. Straaljagers vallen zonder computer als een baksteen naar beneden.

[HuisRocker]

Daarom zeg ik ook specifiek; passagiersvliegtuig, als je straaljagers in het verhaal gaat betrekken is dat "appels met peren vergelijken"...

[Reactie gewijzigd door HuisRocker op 22 juli 2024 18:23]

[kwakzalver]

Moet ik toch altijd denken aan de AS/400.
Niet stuk te krijgen....en krijg je na 20 jaar een sms van een unit dat ie een storing voorspelt en ook nog welk stuk hardware.

Is het sloppy programmeerwerk? Niet altijd. Door de complexiteit en de toenemende hoeveelheid talen en programmeertools is men zich totaal niet bewust van 'sloppy programmeerwerk'. Het geleverde werk kan er prima uitzien, terwijl de achterliggende code een zooitjes is.

Ook is het goed mogelijk dat dit HW memory leak probleem (ook programmeerwerk en ontwerp) in de gebruikte processoren zit.

Sloppy is pas als je bij lezen van een code de opmerking leest: "Afblijven van de volgende regels met je tengels. Het werkt maar we weten niet hoe..."

Lijkt me hoe dan ook dat we 'ermee moeten leren leven' dat dit aspect er is en hoe we het oplossen of een work-around vinden.

[slowdive]

We zullen - zeker voor dit soort kritische systemen - naar andere vormen van programmeren moeten gaan.
Voor het (sub-)systeem moet een wiskundig, verifieerbaar model opgesteld worden, dat aantoonbaar niet in ongewenste toestanden kan komen.
Daar wordt aan gewerkt, maar dit soort nood-restarts zouden niet mogen bestaan.

[mbbs1024]

Wordt er voor kritische systemen niet de programmeertaal ADA gebruikt ?
Ik heb onlangs een podcast over ADA gehoord, zou lijken op C++, maar veel strikter op het vlak van variabele en memory declaraties.
Er zouden ook allerlei analysetools voor beschikbaar zijn om code op runtime niveau te testen op dingen die kunnen misgaan als er een verkeerde input in de sw binnenkomt.

[onox]

Voor embedded en real-time systems wordt idd vaak Ada gebruikt. De taal is ontworpen voor real-time en safety critical systemen en biedt memory safety d.m.v. strong typing, dependent typing, bounds checking van arrays en accessibility checks zodat pointers niet naar ongeldig geheugen kan wijzen. De taal maakt het eenvoudig om je code op te delen in aparte modules, het verbergen van informatie, het specificeren van low-level reprentatie van types, high-level concurrency en het opleggen van bepaalde taal-restricties om het review en het certificeren van code makkelijker te maken.

Maar ook met Ada kun je jezelf nog steeds in je voet schieten en daarom is er een subset genaamd SPARK die alleen features bevat die formeel verifieerbaar zijn (in de laatste versie heb je nu ook pointer ownership). SPARK biedt tools om te bewijzen dat je code correct is volgens de specificaties en dat er geen exceptions optreden. Op https://learn.adacore.com..._Overview.html#what-is-it kun je in je browser kleine code examples door de tools laten checken.

[miitjohn]

Een simpele reboot, tot die vergeten wordt. De kans dat er hierdoor een vliegtuig neerstort is waarschijnlijk zeer klein, maar de meeste ongevallen zijn een aaneenschakeling van gebeurtenissen.

[kaasboer09]

Het is niet dat de piloten een post-it sticker op hun cockpit hebben hangen. Zulke procedures zijn vrij rigoureus. Als men het vergeet en dat waarschijnlijk zou resulteren in een crash, dan waren alle vliegtuigen "grounded" totdat een update was geïnstalleerd.

[miitjohn]

Niet noodzakelijk. Maintenance zijn ook maar mensen en elke aparte procedure is een extra risico. Vermoedelijk heef men hier ingeschat dat het risico klein is. Alles is een risico, het gaat erover hoe groot is dat en wat is de kans dat het een probleem wordt. Maar elke anomalie die langer aanhoud dan nodig kan een onderdeel gaan spelen in een groter geheel en als dan net alles bij elkaar komt heb je een probleem.

Wat daar de kans toe is, is opnieuw onderdeel van de risico analyse. Feit is, zo'n risico analyse is weer een risico op zich. Zie 737 max. Alles technisch dik inorde en volgens de regels. Naja, blijkbaar toch niet helemaal inorde zo blijkt.

Het valt mij altijd op dat bij de meeste crashes het soms zeer banale zaken zijn die aan de oorzaak van de crash liggen, maar het zijn er meestal ook meerdere.

[kaasboer09]

Bij de uitgifte van een onderhoudsbericht wordt rekening gehouden met de mogelijkheid van het niet/onvoldoende opvolgen.

Daarom is het onwaarschijnlijk dat bij éénmaal vergeten te rebooten meteen het toestel uit de lucht dondert.

[bouwfraude]

Een relatief simpele reboot kan vergeten worden, beetje jammer als het systeem vastloopt in de lucht.
Om de 6 dagen is best vlot, windows 95 hield het nog 49 dagen uit.

[Reactie gewijzigd door bouwfraude op 22 juli 2024 18:23]

[St00mwals]

Ben ik de enige die dacht dat als een vliegtuig ergens 'een nachtje zou blijven slapen' dat die dan gewoon uit gezet zou worden, maar blijkbaar dus niet.

Vandaar een misschien hele suffe vraag :
Hoe lang duurt een volledige restart van een vliegtuig?

Edit:
@JUST_me :
Dan weet jij (als piloot zijnde) mogelijk ook wel het antwoord op mijn vraag...

[Reactie gewijzigd door St00mwals op 22 juli 2024 18:23]

[JUST_me]

Een volledige restart van de meeste systemen duurt maar een paar minuten. Dat stelt niets voor.

Het meeste tijd neemt een volledige line up van het traagheidsnavigatie systeem in beslag, max 11 minuten. Maar dan is de rest al volledig operationeel en zijn wij druk aan het werk met de route programmeren/system set up.

Vanuit een volledig dode kist kan een ervaren crew binnen een kwartier up and running and ready for take off zijn.

[familyman]

Nu fascineert het dat die machines schijnbaar telkens zo lang aan blijven staan.

[Sand0rf]

Vliegtuigen verdienen alleen geld als ze vliegen dus die staan zo min mogelijk uit

[JUST_me]

Nou ja, mij bevreemd het ook wel een beetje....

Ik vlieg zelf de Boeing 737 NG voor een Nederlandse maatschappij. Wij hebben de instructie dat als we in de nacht aan komen op Schiphol en de technische dienst is niet direct bij het vliegtuig, we de kist dood moet maken (de spanning van alle elektrische systemen behalve de cabine bus, zodat catering/schoonmaak zijn werk kan doen).

Dit heeft te maken met het falen van een externe spanningsbron bij een van onze vliegtuigen een tijdje geleden (die krengen zijn nogal onbetrouwbaar, relatief gezien. Soms vallen ze uit omdat de diesel op is). Dat toestel is voor de stroomvoorziening overgeschakeld op de interne accu’s die daarbij zo diep ontladen zijn, dat ze vervangen moesten worden. Dat was een schade post van een paar ton.

Een behoorlijk deel van onze vloot wordt iedere nacht daarom gereboot..... ik zie niet snel een toestel 7 dagen achtereen aan staan.

Wereldwijd worden soortgelijke externe spanningsbronnen gebruikt voor het voeden van het vliegtuig. Kan me niet voorstellen dat A350 operators hier ook niet mee te maken hebben.

[Reactie gewijzigd door JUST_me op 22 juli 2024 18:23]

[Fly-guy]

Een A350 of 787 is niet simpel meer uit te zetten door de grondspanning weg te halen en de batterijen uit te zetten, daar is een maintenance actie voor nodig.

Uiteraard wordt de cockpit donker, maar dat wil niet zeggen dat intern alles ook dood is.

[JUST_me]

Oh, dat geloof ik graag. Als wij een kist 'dood'maken dan blijven er ook bepaalde bussen onder spanning staan. Anders zou bijvoorbeeld iets eenvoudigs als de klokken in de cockpit iedere keer opnieuw ingesteld moeten worden...... (de klokken worden gesynchroniseerd met GPS, als het systeem volledig operationeel is. Daarvoor werken ze in handmatige mode)

[Ryen]

Wat @pauldebra hierboven zegt:

Het is onaccepptabel dat software systemen regelmatig moeten worden gereboot omdat ze het anders niet meer doen

is natuurlijk waar. Maar helaas niet de realiteit.

@JUST_me :

Een behoorlijk deel van onze vloot wordt iedere nacht daarom gereboot..... ik zie niet snel een toestel 7 dagen achtereen aan staan.
Wereldwijd worden soortgelijke externe spanningsbronnen gebruikt voor het voeden van het vliegtuig. Kan me niet voorstellen dat A350 operators hier ook niet mee te maken hebben.

Hier schuilt een potentieel gevaar: Als de procedures/gewoontes zorgen dat de boordcomputers regelmatig uitgeschakeld worden om andere redenen dan softwarestabiliteit bestaat natuurlijk ook de mogelijkheid dat dat niet altijd gebeurt. En als je pech hebt en dat 149 dagen niet is gebeurd heb je alsnog een levensgroot probleem.

Software moet expliciet getest worden op langdurige stabiliteit. Dit is niet makkelijk maar ook niet onmogelijk. Memory-gebruik (en dus leaks) zijn bijvoorbeeld prima te monitoren tijdens tests.

O ja: "Grotere" integers gebruiken is geen oplossing, maar een lapmiddel.

[Reactie gewijzigd door Ryen op 22 juli 2024 18:23]

[Adm.Spock]

Als de timer dan langer kan doorlopen zonder rollover dan de levensduur van het toestel, dan heb je effectief het probleem opgelost.

[Ryen]

OK, als deze veel langer kan doorlopen wel. Maar dat moet dan een paar honderd jaar zijn. Er vliegen nu ook al vliegtuigen rond die 50+ jaar oud zijn.

[mae-t.net]

Maar die zijn in de tussentijd vast al eens gereboot. Het is in dit geval belangrijk dat de teller langer kan doorlopen dan een veilig veelvoud van het langste onderhoudsinterval.

[JUST_me]

Daar heb je gelijk in. Ik wilde dan ook geenszins suggereren dat een procedure die niets met een probleem (software) als dit te maken heeft, als vervanging van een noodzakelijke procedure moet gelden.

Ik vroeg me alleen of hoeveel toestellen van de A350 serie daadwerkelijk 7 dagen of langer in werking zijn.

[robvanwijk]

Software moet expliciet getest worden op langdurige stabiliteit. Dit is niet makkelijk maar ook niet onmogelijk. Memory-gebruik (en dus leaks) zijn bijvoorbeeld prima te monitoren tijdens tests.

En het geeft ook geen garantie op succes. Er bestaat geen getal X waarvoor geldt "als er na X uur testen geen fout optreedt, dan is de software bug-vrij", net zomin als er een getal Y bestaat waarvoor geldt "als er na Y test cases geen fout optreedt, dan is de software bug-vrij" uitzondering: combinatorial logic (dus zonder geheugen-effecten), maar zelfs in dat geval is Y zo ontzettend groot dat alle combinaties testen alsnog geen realistische aanpak is.

"Grotere" integers gebruiken is geen oplossing, maar een lapmiddel.

Als een Amerikaan een klok maakt, dan zou ie een vier-bit integer kunnen gebruiken voor het aantal uren (en een flag voor AM / PM). Werkt prima. Zodra ie Europese gebruikers krijgt (die 24-uurs notatie verwachten) is het geen oplossing om een vijf-bit integer te gebruiken...? Wat stel jij dan als correcte oplossing voor?

Of "bredere integers" een oplossing of een lapmiddel is hangt er vanaf. Mijn eerste vraag is, waarom heb je ervoor gekozen om het op die manier aan te pakken?

• "We snappen niet wat er precies fout gaat, maar met een grotere integer verdwijnt het probleem" -> lapmiddel.
• "We hebben de oorzaak van het probleem gevonden en uitgewerkt hoe groot de integer moet zijn om nooit meer problemen te veroorzaken" -> oplossing.

[Sand0rf]

Ik denk ook niet dat dit direct iets is wat regelmatig voorkomt (Langer dan 150 uur niet cold & dark) maar dat dit als extra aanwijzing wordt verspreidt.

[2TheMaks]

Dat toestel is voor de stroomvoorziening overgeschakeld op de interne accu’s die daarbij zo diep ontladen zijn, dat ze vervangen moesten worden. Dat was een schade post van een paar ton.

Stel, dit komt een immer behulpzame software-developer ter ore, dus die implementeert een routine die de capaciteit van de batterijen in de gaten houdt, en de stroomvoorziening automatisch uitschakelt wanneer de resterende capaciteit van de batterijen te laag word. "Dat scheelt duizenden dollars in onnodige kosten wanneer er weer eens een GPU (ground power unit) de geest geeft", zo denkt de behulpzame software-developer.

En zo hebben we een scenario te pakken waar er een feature in de software terecht komt die niet direct voortvloeit uit de requirements. Sterker nog: deze feature staat mogelijk zelfs in de weg van een andere requirement, namelijk dat de batterijen minimaal 20 minuten lang power moeten kunnen leveren aan alle systemen die nodig zijn om het vliegtuig onder controle te houden wanneer alle motoren en de APU (auxiliary power unit) ermee opgehouden zijn, en de (eventueel aanwezige) RAT (ram air turbine) niet naar behoren werkt.

Vliegers die de ongelofelijke pech hebben in deze situatie terecht te komen worden dan ook nog eens geconfronteerd met het feit dat de cockpit reeds na 10 minuten op zwart gaat omdat het 'battery-discharge-protection-system' van de immer behulpzame software-developer de stroomvoorziening uitgeschakeld heeft vanwege te lage resterende capaciteit van de batterijen. Die vliegers en hun passagiers (strikt genomen zijn de vliegers in deze situatie ook passagiers geworden) hebben nu geen enkele kans meer om levend terug op de grond te komen.

Het ongedocumenteerd introduceren van features door developers (of development-teams) komt regelmatig voor. Omdat de features niet gedocumenteerd zijn worden deze ook niet onafhankelijk getest, hooguit door de developer of het development-team zelf.

Wanneer onafhankelijke testers of de architect hier naar gekeken hadden, dan hadden ze kunnen zeggen: goed idee, dat 'battery-discharge-protection-system', echter, het is onvolledig geïmplementeerd.

Het moet niet zijn:
<code>if (battery-capacity < min-limit) then (shutdown-power)</code>

maar:
<code> if (weight-on-wheels AND battery-capacity < min-limit) then (shutdown-power)</code>

Ofwel: het 'battery-discharge-protection-system' schakelt de stroomvoorziening alleen uit wanneer het vliegtuig op de grond staat (weight-on-wheels indicator) EN de resterende capaciteit van de batterijen te laag word.

[JUST_me]

Klopt. Maar ook het air ground sensing systeem kan een fout hebben. Sterker, dat gebeurt nog wel eens.

De minimale capaciteit van de accu bij een total power loss is 60 minuten in 'mijn' toestel. En zelfs als alles uit zou vallen, dan valt het toestel met spierkracht te besturen en ook het landingsgestel kan met zwaartekracht uitgeklapt worden. Dus zelfs in dit bizarre geval is er iets mogelijk. In een groter toestel of een Airbus is het klaar zonder spanning.

Ik prefereer het handmatig uitzetten van de kist bij aankomst zonder TD. Het debacle met de 737 Max laat wel zien wat (teveel) software kan veroorzaken. Al is dat vloeken in de kerk hier op Tweakers.... Mijn excuses.

[Reactie gewijzigd door JUST_me op 22 juli 2024 18:23]

[2TheMaks]

Klopt. Maar ook het air ground sensing systeem kan een fout hebben. Sterker, dat gebeurt nog wel eens.

Ook iets wat je alleen door training en/of ervaring weet.
I.p.v. flight/ground dus de stand van de parking-break switch gebruiken in het if-statement.

Dat is dus mijn punt:
bij het ontwikkelen van software nemen ontwikkelaars regelmatig beslissingen zonder exact te weten waar de klepel hangt. Ze ontberen immers de training en ervaring van de operator, in dit geval de vlieger.

[kaasboer09]

Het debacle met de 737 Max laat wel zien wat (teveel) software kan veroorzaken. Al is dat vloeken in de kerk hier op Tweakers.... Mijn excuses.

Toestellen van zowel Boeing als Airbus vallen helaas wel eens uit de lucht. Typische redenen kan je classificeren onder:
- Menselijke fout (bv piloot schakelt verkeerde motor uit)
- Component error (bv elevator breekt af)
- Hardware error (bv brand in de boordcomputers)
- Software error (bv weergeven van een verkeerde kruissnelheid)

Maar vrijwel in alle gevallen van noodlottige crashes is het een combinatie van deze vier factoren. Automatisering kan de menselijke fouten reduceren, maar tegelijkertijd introduceer je de mogelijkheid tot kritieke software bugs. Daarom dat human-machine interaction (HMI) momenteel een heet hangijzer is in de wetenschap naar crash preventie.

Maar dit gaat weer terug naar de klassieke discussie over de ontwerp filosofie van Boeing versus Airbus. Voor zover ik weet zijn er geen statistieken die uitwijzen dat er significante verschillen zijn tussen Airbus en Boeing wat dat betreft. Maar wat wel duidelijk is, is dat de afname in fatale ongevallen evenredig afneemt met de introductie van digitale system en automatisering.

In een groter toestel of een Airbus is het klaar zonder spanning.

In het geval van een complete power failure heeft Airbus heeft nog een RAT generator. Één hydraulisch systeem en één bus wordt daardoor weer operationeel voor de basale navigatie, communicatie, maneuvres en hydraulisch remmen.

[robvanwijk]

Dit heeft te maken met het falen van een externe spanningsbron bij een van onze vliegtuigen een tijdje geleden (die krengen zijn nogal onbetrouwbaar, relatief gezien. Soms vallen ze uit omdat de diesel op is).

Misschien een stomme vraag hoor, maar wat verwacht je dan dat een aggregaat doet als de diesel op is, doorgaan met stroom leveren...?

[JUST_me]

Nope. Maar ik verwacht wel van een afhandelaar dat hij zijn ground power units van voldoende brandstof blijft voorzien zodat deze blijven werken en niet een enorme schade post veroorzaken.....

[Z80]

Even de pdf gelezen. Het gaat er om dat de systemen powerup zijn. Blijkbaar laten de vliegtuigmaatschappijen de kist onder spanning als deze niet gebruik wordt. Wordt de kist wel "black" weggezet voor de nacht dan is er niets aan de hand.

[Ryen]

Hier ben ik het dus niet mee eens. Er is alleen niets aan de hand als men een bepaalde gewoonte aanhoudt (het stroomloos wegzetten). Als ergens ter wereld iemand van deze gewoonte afwijkt valt er mogelijk alsnog een vliegtuig uit de lucht.

[BonnyDuctTape]

Het triggered mij ook. Na een korte Google search vond ik de volgende uitgebreide uitleg op onderstaande site;

https://aviation.stackexc...on-ground-for-an-aircraft

Er wordt onderscheidt gemaakt tussen;

Time on Ground,
Boeing 747: 80 minutes
Boeing 777: 70 minutes
Boeing 767: 60 minutes (-300 model)
Boeing 737: 35 minutes (-300 model)
Airbus A320: 40 minutes

Aircraft Lifetime in Cycles,
Boeing 747: 20,000 cycles
Boeing 777: 40,000 cycles
Boeing 767: 50,000 cycles
Airbus A320: 48,000 cycles (60,000 hours)
Airbus A300: 40,000 cycles

en Aircraft Usages.

[Reactie gewijzigd door BonnyDuctTape op 22 juli 2024 18:23]

[sygys]

Ik vraag me af als dan alles uitvalt in de lucht. Is dit systeem nog te rebooten voordat het vliegtuig uit de lucht komt vallen? En is deze überhaupt in de lucht te rebooten?

[Verwijderd]

Ik zou zeggen van wel. Airbus vliegt op basis van fly-by-wire (FBW) waar bij Boeing de piloot volledige controle heeft (de piloot kan de Auto-pilot overullen).

Een mooi voorbeeld is de https://en.wikipedia.org/wiki/China_Airlines_Flight_006 waarbij de piloot nog de vlucht heeft kunnen redden van een vrije val vanaf 30.000 voet. Als de 747 FBW was geweest waren die mensen morsdood geweest. Omdat de piloot de vliegtuig uit een stall kon trekken, gaat mij voorkeur uit naar on-pilot systemen. Maar FBW maakt het vliegen ongeloofelijk makkelijk en vergt alleen kennis van de FBW systeem (in relatie tot het tpe vliegtuig). Men zegt dat vliegen in een Airbus makkelijker is, en vliegen Boeing schijnt leuker te zijn. Allebij zijn natuurlijk subjectief.

[nallath]

Fly by wire is domweg dat je niet door middel van spierkracht de flappen aanstuurt maar dat je controls electrische signalen naar je actuatoren sturen.

Een vliegtuig van die grote is altijd fly by wire. Dat geld voor zowel Airbus als voor Boeing. Die stuurvlakken zijn zo groot (en hebben zulke krachten er op werken) dat jij dat met spierkracht echt niet meer geregeld krijgt hoor.

[Verwijderd]

De laatste 2 vliegtuigen (de 787, en de 747-8) van Boeing zijn bijna volledig op fly-by-wire gebasseerd.

Bij Boeing stuur je namelijk met kabels bepaalde servo's aan die vroeger volledig met actuatoren bestuurd moesten worden.

Hierdoor kan een boeing 777 (die fly-by-wire gebruikt) die een uitval heeft van zijn Fly-By-Wire systeem nog door vliegen.

"The flight controls on Airbus fly-by-wire aircraft are all electronically controlled and hydraulically activated"

Boeing heeft 3 vliegmodusen (Normal Mode, Secondary Mode en Direct Mode)

"A mechanical Backup In the event of a complete electrical system shutdown, cables from the flight deck controls to the stabiliser and selected roll spoilers allow the pilots to maintain straight and level flight until the electrical system can be restored."

En ze worden vandaag de dag nog steeds gebruikt. Gebeurt niet vaak dat alle FBW systemen uitvallen.

Ik heb vliegtuig onderhoud gedaan aan de ROC Hoofddorp waar ik succesvol mijn part diploma gehaald heb. Hierna ben ik de IT in gegaan.

In een Airbus is FBW leidend en in een Boeing de piloot. Vandaar dat de piloot altijd de auto-pilot/FBW kan overrullen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:23]

[Powermage]

Boeing is ook steeds meer FBW en geautomatiseerd, dat bewijzen de 737 MAX toestellen zelfs.

[JUST_me]

De 737 is niet fly by wire. Slechts bepaalde systemen zijn dat (spoilers, stabiliser). Aansturen van de primaire stuurvlakken gaat nog steeds met ouderwetse stalen kabels met hydraulische bekrachtiging.....

In een totale system failure is een 737 met spierkracht te besturen. Veelvuldig gedaan tijdens testvluchten. Vliegt prima, goed te controleren alleen stuk zwaarder en logger te sturen. Alleen het rudder heeft nog een hydraulische back up, want met spierkracht is deze niet te poweren.

[Fly-guy]

Ook in een airbus kun je met gemak de autopilot overrulen en dat heeft nul komma niets met fly by wire te maken.
Tegenwoordig is elk (groter)modern vliegtuig fly by wire, ook boeings en heeft wederom nul komma niets met makkelijker te vliegen te maken.

[Verwijderd]

Alleen de laatste 2 (787 en 747-8) Boeing vliegtuigen bevatten FBW zonder mechanische backup. Daarvoor krijg je de 777 die allebij heeft, en daarvoor was alles mechanisch. Zelfs de 737 max komt nog met mechanische back-up (als ik het goed heb), alleen dat is geen nieuwe airframe.

[kaasboer09]

Let op: FBW is niet hetzelfde als de Autopilot. FBW is zelden (of nooit?) de directe aanleiding geweest van een crash. Wat wel voorkomt is dat de autopilot een onterechte handeling uitvoert. Bij de recente crash van Ethiopian Airlines voerde de autopilot incorrecte mechanische handelingen uit.

[dmantione]

Als ik het relaas op dit Wikipedia-pagina lees, is dat niet mijn conclusie: Het artikel meldt meerdere momenten waarop de piloot niet optimaal handelde. Het is plausibel dat de beveiligingssystemen die in een fly-by-wire systeem van een Airbus zitten hadden kunnen voorkomen dat het vliegtuig in een dergelijke situatie terecht was gekomen, immers het corrigeren van de piloot is precies bedoeld om dat soort menselijke fouten te voorkomen.

Verder lijkt het erop dat je een verkeerd begrip hebt van het corrigeren van de piloot: Die is ook op een Airbus nog altijd de baas. Als de piloot het er niet mee eens is dat hij gecorrigeerd wordt dan kan hij met een eenvoudige handeling de zgn. flight-control-mode van het vliegtuig aanpassen. In de "direct law"-mode is de piloot de baas en zal de piloot nooit gecorrigeerd worden. In een situatie waar de computer de piloot hindert om het vliegtuig in veilige stand te krijgen, zou dit al lang gebeurt zijn.

Verder was bij dit voorval nog sprake van een vliegtuig met een boordwerktuigkundige. De boordwerktuigkundige is een functie op een vliegtuig die al heel lang door computers is overgenomen (fly-by-wire of niet) en als gevolg is de werking van dat vliegtuig dusdanig anders dan een modern vliegtuig dat vergelijkingen er moeilijk worden.

Tot slot, zoals Nallath schrijft is fly-by-wire iets anders dan het corrigeren van de piloot. Fly-by-wire betekent dat je het vliegtuig niet langer mechanisch met spierkracht kunt besturen. Het corrigeren van de piloot zoals op Airbussen gebeurt staat daar los van.

[Reactie gewijzigd door dmantione op 22 juli 2024 18:23]

[Verwijderd]

Ik heb het ook niet van Wikipedia, maar een pagina die de wetten beschrijft waar een FBW aan word onderworpen. Dat geeft meer inzicht en informatie dan Wikipedia.

De concorde was ook fly-by-wire, maar bezat ook gewoon een mechanische besturing als back-up.

Overigens als ik de eerste alinea's van wikipedia lees, bevestigt het mijn comment:
"Fly-by-wire (FBW) is a system that replaces the conventional manual flight controls of an aircraft with an electronic interface. The movements of flight controls are converted to electronic signals transmitted by wires (hence the fly-by-wire term), and flight control computers determine how to move the actuators at each control surface to provide the ordered response. It can use mechanical flight control backup systems (Boeing 777) or use fully fly-by-wire controls.[1] "

Lees anders deze pagina als voorbeeld met best duidelijke diagrammen:
https://www.heritageconcorde.com/fly-by-wire

[dmantione]

Inderdaad, moderne Airbussen hebben geen volledige mechanische backup. Er zijn nog wel mechanische backups om in geval van stroomuitval nog wat te kunnen sturen, maar om het toestel aan de grond te zetten is elektriciteit nodig en de mechanische backups bestaan dan ook alleen om de piloten de kans te geven de elektriciteitsvoorziening weer op te starten (door middel van de motoren, auxiliaire stroomgenerator of uitklapbare windturbine kan elektriciteit opgewekt worden). De gedachtengang is dat als al deze drie methoden falen, het vliegtuig sowieso al verloren is en de nadelen van volledig mechanische besturing zwaarder wegen dan de voordelen.

[Z80]

Niet alles valt uit. Slechts een paar onderdelen. En wat ik zo snel zie ook enkel de helft van een systeem.
Het toestel blijft gewoon veilig vliegen. Enkel een back-up systeem kan falen. Dus enkel in een noodsituatie waarbij dit betreffende systeem uitvalt blijkt het back-upsysteem ook niet te werken.
Maar de kist is ook zonder deze toeters en bellen te vliegen. Zodra je deze in deze stand zet ben je als piloot volledig baas over wat er gebeurt. Met alle voor en nadelen.

[DennusB]

Gaat lekker met die vliegtuig software de laatste tijd. Blijft toch bijzonder hoe zulke problemen er in kunnen sluipen in zulke kritische systemen. Je zou verwachten dat het test proces beter op orde is...

[Lapa]

Van de ene kant vind ik dit altijd zo makkelijk gezegd. Reken er maar op dat dit soort software heel wat uitgebreider getest is dan een willekeurige iPhone app. Maar ook dat dit veel ingewikkelder is, in een complex samenspel van hardware en software.

Van de andere kant... er zijn wel sterke aanwijzingen dat in ieder geval Boeing heel veel technische expertise wegbezuinigd heeft omdat "de systemen inmiddels volwassen zijn". Geen idee hoe dat bij Airbus zit.

[Reactie gewijzigd door Lapa op 22 juli 2024 18:23]

[DennusB]

Ben het met je eens, alle scenarios afdichten met testen is ontzettend lastig. Maar je zou er toch vanuit gaan dat ze zo'n systeem 149+ uur laten draaien in een test omgeving om te zien wat het doet? Dat lijkt me dan 1 van de simpelere tests!

[Seal64]

Hoe wil je dat testen dan? Nu blijkt dat dat systeem na 149 uur in de fout kan gaan. Misschien gaat het volgende systeem wel na 376 uur uit z'n stekker, en nog een ander systeem na 15.945,3 uur. Hoe lang moet je testen voordat je zeker weet dat je alles hebt?

[DataGhost]

149 uur klinkt zo specifiek, dat moet haast wel om een timer gaan die ergens overflowt. Dat zou bijvoorbeeld een signed 32-bit overflow van een 4000Hz timer (of unsigned op 8000Hz) kunnen zijn. Na 536.870 seconden ofwel 149,13 uur zal die negatieve tijden (unsigned: rollover naar 0) aan gaan geven. Ik geef het een zeer grote kans dat het zoiets is, en op het moment dat je wat voor timer dan ook gebruikt weet iemand dat, die moet dat melden en dan moet je gaan kijken wat er gebeurt bij overflow-condities, zeker als je kijkt wat er met Y2K allemaal mis had kunnen gaan. Dat is namelijk eenzelfde soort bug.

Oftewel: alle timers inventariseren en gevolgen testen. Nooit direct gebruiken zonder geteste library die tijdsverschillen correct kan berekenen ook al heeft er rollover plaatsgevonden.

Edit: net de airworthiness directive gelezen en daar staat inderdaad het volgende in:

To address this potential unsafe condition, Airbus issued the AOT to provide instructions to reset the internal timer.

[Reactie gewijzigd door DataGhost op 22 juli 2024 18:23]

[zonoskar]

Als het zoiets is, dan zou het elke keer optreden na 149 uur. Ik denk dat het meer iets is met memory leaks. En daar is normaal vrij makkelijk op te testen.

[DataGhost]

Nee, dat hoeft niet. Stel je hebt een signed 8-bits timer. Je stuurt een ping om 127 en krijgt een reply om 128, wat een overflow is. Je krijgt dan -128, en je systeem ziet dat de reply eerder is dan de ping zelf en
a) negeert 'm helemaal, waardoor het betreffende systeem op failure gezet wordt
b) PANIEK! CRASH!
c) berekent daarmee de RTT in een breder datatype: -128 - 127 = -255 (a en b kunnen nu alsnog gebeuren)
d) berekent daarmee de RTT op de juiste manier: -128 - 127 = 1
Maar er is ook een heel grote kans, met snelle verbindingen (lage RTT) en "hoge" klokfrequentie (4kHz) dat er helemaal geen berichten gestuurd worden die precies over de overflow-grens heen gaan. Als ze allebei 1 tik later waren gekomen had je resp. -127 en -128, wat causaal klopt en wiskundig nog steeds gewoon 1 oplevert, zelfs met de verkeerde datatypes.

In mijn edit en ook in de PDF van de EASA staat trouwens expliciet dat het om een timer gaat, niet om een memory leak.

[burne]

Vliegtuigen gebruiken 127 volt 400Hz als boordspanning.

[Umbrah]

Dat is voeding. Dit zou best een sensor, inverter, of time/series module kunnen zijn. Die draaien vaak vele malen hoger dan de voeding. De 400Hz base hoop ik niet dat ze gebruiken voor dit soort timings, maar gewoon losse clocks.

[burne]

RDC's zijn modules die sensors uitlezen en de waardes op een netwerk-bus zetten. Het idee is dat je in plaats van tientallen of honderden kabels door het hele vliegtuig een beperkt aantal netwerk-bussen hebt.

Een veelvoud van een veel voorkomende storingsfreqentie gebruiken is een goede mogelijkheid om 'ruis' te onderdrukken. En 4000Hz of fracties daarvan is een mooi getal voor timer-intervallen. Je vind dat soort getallen dus overal terug. Een gyro sampled op 8kHz. De barometer in de hoogtemeter zit op 2kHz.

Dus een aan de boordspanning gerelateerde klok is een stuk minder raar dan je lijkt te denken.

[runeazn]

Niet lullig bedoeld maar hoe is dit relevant? Want een timer werkt gewoon op basis van een crystal oscillator (vaak) en die werkt weer op gelijkstroom.

[ToolkiT]

Precies zoiets is het idd.. ik ben de details vergeten, maar heb er iets over gelezen en wat jij beschrijft is idd de kern van het probleem..

Volgens mij had Matt Parker het in math mistakes het erover..
https://youtu.be/6JwEYamjXpA?t=3379
Raket verhaal, maar vergelijkbaar probleem.. skip naar 1:02 voor details on the probleem..

[Reactie gewijzigd door ToolkiT op 22 juli 2024 18:23]

[mashell]

Dus als een vliegtuigprobleem na 149,13 uur optreed krijgen de vliegmaatschappijen instructie om bij 149 uur de boel te resetten? Dat zou toch een goede aanwijzing om voorlopig maar niet meer te vliegen.... Ik denk eigenlijk dat het probleem ergens vanaf pakweg 200+ uur is vastgesteld, maar niet reproduceerbaar en er dan met een flinke marge een instructie van 149 uur uit komt.

[DataGhost]

Waarom zouden ze dan zo'n rare hoeveelheid tijd pakken als 149 uur? Dan zeg je toch gewoon 168 uur, wat 1 week is, in plaats van 6,02 dagen of 6 dagen en 5 uur. Stel dat het echt 200+ uur is, heb je een wijsneus die ziet dat er niks gebeurt na 149 uur en concludeert dat zij het probleem niet hebben.
Bovendien zeggen ze volgens mij niet dat ze hem "bij 149 uur" moeten resetten, maar "voor 149 uur" en dat betekent dat ze gewoon zwaar de zak zijn als er uit logbestanden blijkt dat het systeem langer dan 149 uur heeft gedraaid (ook al is het minder dan 149,13 uur). Als je heel precies kan berekenen (4000 * 3600 * 149 is ongeveer 2³¹) wanneer het probleem voor kan komen is het niet nodig om extra marges te nemen, het is niet alsof het afhangt van hoeveel tegenwind er staat ofzo. De marges dien je als maatschappij zelf te nemen, zodat je niet na 141 uur opstijgt voor een 10-urige vlucht.

[Reactie gewijzigd door DataGhost op 22 juli 2024 18:23]

[mashell]

je heel precies kan berekenen (4000 * 3600 * 149 is ongeveer 231) wanneer het probleem voor kan komen is het niet nodig om extra marges te nemen

en

heb je een wijsneus die ziet dat er niks gebeurt na 149 uur en concludeert dat zij het probleem niet hebben

is precies de reden om extra marge te nemen. Dit is luchtvaart. Die wereld bestaat uit extra marge nemen. Er zitten zelfs twee piloten in de cockpit terwijl het vliegtuig eigenlijk bijna zelfstandig kan vliegen.
Een reden voor een raar getal als 149 kan zijn het preciezer lijkt dan een mooi afgerond getal als 150. Jij zoekt vanalles achter 149, dat doet de wijsneus ook. En de wijsneus zou bij 150 kunnen denken, dat is een natte vinger getal, 155 uur kan ook wel.

[Reactie gewijzigd door mashell op 22 juli 2024 18:23]

[hiostu]

Het kan dus zijn dat er in een heel specifiek geval, situatie, hardware combinatie, etc na 149 uur+ een issue optreedt in de software. Mogelijk weten ze nog niet in welke gevallen dat optreedt, dus daarom laten ze uit voorzorg alle vliegtuigen nu resetten na 149 uur om te voorkomen dat het lijdt tot een incident.

[thechronic]

Volgens het artikel is er al een patch beschikbaar:

Dat hangt samen met een software-bug. Die is in 2017 al geïdentificeerd en Airbus heeft er een oplossing voor in de vorm van een aantal softwaremodificaties.

Je zou denken "waarom niet updaten" maar het verbaast mij eigenlijk niet dat de maatschappijen de software van hun vliegtuigen niet updaten. Als het werkt dan werkt het. Vliegtuig 1x per week rebooten is waarschijnlijk makkelijker.

[DiedX]

Het zou mij niets verbazen als je dan het hele vliegtuig moet laten checken. Kost geld, dus doen we niet.

[FreshMaker]

Het zal niet zomaar een usbstick inpluggen en gaan zijn.
Die dingen zijn procedureel vastgelegd, misschien kan het ook alleen maar op 'specifieke' luchthavens, of als onderdeel X gedemonteerd is.

Zou het een OTA update zijn, had het inderdaad al wel gebeurd geweest

[T-men]

Dat lijkt me dan 1 van de simpelere tests!

Zo simpel is het niet. Het is niet een kwestie van 149+ uur laten draaien en kijken of er dan, bij wijze van spreken, rook uit komt.

Het kán na die tijd mis gaan != het gáát ook mis in de test.

Dus ook na vele praktijktesten zul je het waarschijnlijk niet eens merken.

[Kenhas]

inderdaad, je kan op voorhand natuurlijk niet weten hoe lang je iets moet testen. Als je zou weten hoe lang het duurt eer iets crashed, dan kan je het probleem evengoed verhelpen.

Wat ben je met 149 uur laten draaien als iets maar voorvalt na 248 dagen, zoals het ander voorbeeld in het artikel

[Jimmy J.]

Ik kan me voorstellen dat deze bug niet áltijd na 149 uur voorkomt, maar soms in specifieke gevallen.

[Iblies]

Ben het met je eens, alle scenarios afdichten met testen is ontzettend lastig. Maar je zou er toch vanuit gaan dat ze zo'n systeem 149+ uur laten draaien in een test omgeving om te zien wat het doet? Dat lijkt me dan 1 van de simpelere tests!

Sorry om het te zeggen,
maar wat je daar zegt is zwaar onzin, en die fout wordt in de praktijk ook vaak gemaakt.

Dit soort software is afhankelijk van input van een scala aan sensoren, en die sensoren zijn een zwakke schakel in het geheel die je niet zomaar kunt simuleren anders dan letterlijk heel veel vlieguren maken.

In de praktijk kun je links en rechts heel veel input krijgen waarmee je ogenschijnlijk prima kunt vliegen, corrigeert zichzelf wel, alleen kan de bron een een probleem hebben, of het opstapelen van de foutmeldingen kan bij andere elementen tzt storingen leiden.

Iets soortgelijks zie je overigens ook bij auto’s, als er geen klachten zijn, bij een check komt er ook niks uit, dan wordt bij onderhoud de foutmeldingen verwijderd.

[MrAndy9797]

Ben het met je eens, alle scenarios afdichten met testen is ontzettend lastig. Maar je zou er toch vanuit gaan dat ze zo'n systeem 149+ uur laten draaien in een test omgeving om te zien wat het doet? Dat lijkt me dan 1 van de simpelere tests!

Meer zelfs, het is onmogelijk. Testen dienen ertoe om aan te tonen dat er fouten in de software zitten. Alles coveren is niet mogelijk, maar je kan de risico's wel beperken. Zeker in deze branche zijn er ook coverage afspraken die veel strenger zijn dan bij een gemiddeld bedrijf (je werkt met mensenlevens in dit geval). Er zou inderdaad een testomgeving moeten zijn die de testen 24/24 laten draaien. Kan geautomatiseerd worden, maar is daarom niet simpeler. Je moet namelijk allerlei dingen testen waardoor dit een zeer grote testcase wordt.

Bovendien speelt hardware ook mee die eens betrouwbaarder / onbetrouwbaarder kan zijn. Ik bedoel dan de vergelijking van de testomgeving met de werkelijke toestellen.

Er komt zoveel bij kijken, en om heel eerlijk te zijn: die sector is niets voor mij als testengineer. Dan houd ik het liever bescheiden in het gemiddelde bedrijf. Misschien later als ik meer ervaring heb, maar dan nog

[Ryen]

[...]
Zeker in deze branche zijn er ook coverage afspraken die veel strenger zijn dan bij een gemiddeld bedrijf (je werkt met mensenlevens in dit geval).

Alleen de financiële sector is nog strenger. Daar gaat het tenslotte om geld.

[j_bos]

[...]
(je werkt met mensenlevens in dit geval)

Volgens mij kan hier de discussie meteen mee stoppen. Dit soort bugs en een reboot als fix is belachelijk als het om een vliegtuig gaat. Komop zeg.

[rik86]

Tja, als 't werkt, waarom ook niet? Ik kan me niet echt situaties voorstellen waar een vliegtuig in een blok van 149 uur niet gereboot kan worden

[T-men]

Ja vroegah... toen alles nog met touwtjes en hendeltjes bediend werd toen hadden we dit soort problemen niet... of het toen veiliger was, dat betwijfel ik.

Jammer dat je zo negatief reageert. Dit soort instructies zijn juist het gevólg van het veiligheidsbeleid in de lucht. Ga eens na hoeveel software er in een gemiddelde airliner draait. Het is een gegeven dat 1 op de zoveel (ik meen ongeveer 100) regels code een bug bevat. Dat zal misschien in de luchtvaart wat minder zijn, maar dan nóg zitten er vele regels code en dús ook bugs in het systeem.

Fijn dat die gevonden worden voordat er grote ongelukken gebeuren én fijn dat er zo'n simpele workaround is én fijn dat die wordt afgedwongen.

[T_elic]

Vliegen was vroeger zeker niet veiliger, daarvoor kan je gewoon de cijfers van aantal incidenten per jaar erbij pakken.

Er is sinds begin jaren 80 een langzame daling te zien in aantal incidenten, daar waar het vliegverkeer juist is toegenomen.

[MicGlou]

Ik denk dat het veel meer een ding is dat dergelijke zaken meer de media bereiken dan dat dit in het verleden minder gebeurde... het is sinds Boeing een paar keer met de billen bloot moest een hot item geworden en nu zie je dus dat ook bij Airbus dat soort dingen aan de orde van de dag zijn.

En ook zoals al genoemd, de systemen in vliegtuigen zijn uitermate ingewikkeld en zullen absoluut tot in den treuren worden getest maar helemaal 100% probleemvrij krijg je het dus blijkbaar niet.

[Tricolores]

"Beste passagiers, door de opgelopen vertraging dienen wij zo meteen een tussenlanding maken op de luchthaven van Berlijn om een reboot van ons toestel uit te voeren. Onze excuses voor het ongemak."

[Lapa]

Verkeersleiding: "Heeft u het vliegtuig al uit- en opnieuw aangezet?"

[Zyphlan]

Offtopic:

is 1 keer bij een vlucht van mij voorgekomen. GPS deed het niet... ik maak grapje tegen de persoon die naast me zit :

Vliegtuig opnieuw opstarten -> lukt het nog niet -> paar tikken ertegenaan-> nogmaals opnieuw opstarten -> opgeven.

2min later : Vliegtuig wordt opnieuw opgestart

Ontopic:
Als de bug verder niet voorkomt lijkt het me dat ze dit gewoon in het onderhoud zetten en het meegecalculeerd wordt met de vluchten.

Logisch dat ze het vliegtuig niet aan en uit zetten bij elk landing ( zolang staan die dingen nou ook weer niet aan de grond) maar iemand enig idee hoelang het duurt om zon ding volledig opnieuw op te starten?

[Lempke]

maar iemand enig idee hoelang het duurt om zon ding volledig opnieuw op te starten?

Als je het vliegtuig zelf bedoelt kan dat wel 20 minuten zijn dacht ik, van helemaal 'uit' naar 'aan'.
Dat is natuurlijk veel te lang voor een tussenstop, want daarna komen alle checks en voorbereidingen voor de volgende vlucht er weer bij.

[Reactie gewijzigd door Lempke op 22 juli 2024 18:23]

[JUST_me]

Nee, dat klopt niet. Een 737 duurt ongeveer 11 minuten voordat alles weer helemaal opgestart is (langste tijd neemt de oplijnen van het traagheidsnavigatie systeem in beslag).

Maar ik kan alles doen in de tijd die dat oplijnen in beslag neemt om de vlucht voor te bereiden. Route programmeren, systemen in schakelen..... Als het navigatiesysteem eenmaal werkt, kan je meteen weg. Nou ja, dan kan je de motoren starten.... Wat weer 45 sec/stuk duurt.

Een tussenstop (737) duurt 35-45 min. Tijd zat om dat alles te doen.

[burne]

Ongeveer 25 minuten.

[Barnagma]

uiterlijk elke 149 uur rebooten

Ik ga er van uit dat ze de reboot wel uitvoeren voordat ze een (lange) vlucht hebben

[pennywiser]

Doen ze on the fly

[Zynth]

Ze moeten gewoon die nieuwe software installeren. OTA.

[jpsch]

Berlijn Brandenburg?

[ELD]

Lach maar, ik vlieg ongeveer 20 keer per jaar en heb al meerdere malen over de boordradio de term reset gehoord om e.g. een sensor te clearen.

[dmantione]

Dat zal niet zo snel gebeuren, van wat ik ervan lees:

• Er zijn twee computers, als de ene aan het herstarten is kan op de andere computer gevlogen worden
• Mocht het zo zijn dat beide computers inactief zijn (vanwege bijvoorbeeld een reboot), dan mist de piloot een hoop informatie, zijn alle beveilgiingsmechanismen inactief, maar is het vliegtuig zelf (via de fly-by-wire) nog bestuurbaar.

[GeoBeo]

Ik heb zelf veel aan systemen geprogrammeerd waar sensor data binnenkomt en als ik dit lees gecombineerd met "elke 149 uur rebooten":

De fix van Airbus betreft nieuwe software voor de core processing input / output module en de common remote data concentrator. Laatstgenoemde systeem verzamelt data van verschillende sensoren aan boord van de vliegtuigen.

Dan denk ik dat ik weet wat het probleem is: race condition/data race of een ordinair memory alloc probleem (data die per ongeluk buiten de geserveerde geheugenruimte geschreven wordt, tot iets stuk gaat). Als die 149 uur consequent 149 uur is tot het fout gaat, dan denk ik dat dat laatste het probleem is.

Is ergens te vinden wat de bug was?

[Reactie gewijzigd door GeoBeo op 22 juli 2024 18:23]

[__fred__]

Staat in het AD dat er een internal timer gereset moet worden. Meest waarschijnlijk dus een integer overflow, waarna vergelijkingen niet meer goed gaan.

[GeoBeo]

Staat in het AD dat er een internal timer gereset moet worden. Meest waarschijnlijk dus een integer overflow, waarna vergelijkingen niet meer goed gaan.

Oh, dat is een veel simpeler probleem.

Heel vreemd dat zoiets erdoor komt?!

[FreezeXJ]

Waar had dit gespot moeten zijn? Bij code reviews betwijfel ik of de meesten nog weten hoe groot een 'int' (of uint) eigenlijk is, laat staan dat ze gaan redeneren hoeveel milliseconden je kunt tellen met zo'n intje (ruim 24 dagen voor een 32bit signed int).
En dat alles is aannemend dat ze een taal gebruiken die je nog zelf controle geeft over het type, in plaats van een let, var of def, waarbij de compiler / runtime bepaalt wat het nou eigenlijk gaat zijn.

Hoe vaak doe jij performance tests en endurance tests? Veel builds gaan tegenwoordig live binnen 150 uur na build, dus zo lang zal er nooit aan 1 stuk door getest zijn...

[__fred__]

Ik ontwikkel nog wel eens wat embedded spul en bij elke hardware timer staat toch heel duidelijk vermeld wat er gebeurt als ie rond gaat of nul bereikt (Flag in status register meestal). Zie bijvoorbeeld een ARM cortex core:

http://infocenter.arm.com...oc.ddi0434a/JHBFIIIE.html

Eigenlijk zijn het altijd unsigned counters, dus 8khz frequentie voor een 32 bits timer is ongeveer 149 uur.

[GeoBeo]

Waar had dit gespot moeten zijn? Bij code reviews betwijfel ik of de meesten nog weten hoe groot een 'int' (of uint) eigenlijk is,

Daar is geen standaard voor in veel talen. Dus dat zoek je op voor het specifieke systeem en de specifieke compiler waar de software in draait. In het geval van een hardware timer staat in de documentatie exact uitgelegd hoe groot het timer getal is en welke register (en/of interrupt) bijhoud of er een overflow was.

laat staan dat ze gaan redeneren hoeveel milliseconden je kunt tellen met zo'n intje (ruim 24 dagen voor een 32bit signed int).

Sorry, maar dit is 1 van de eerste dingen die je doet als je weet dat je systeem een timer nodig heeft en je gaat uitzoeken hoe de timers werken. ZEKER in de luchtvaart lijkt me.

Ik snap dat een gemiddelde web/java programmeur daar misschien niet over nadenkt, maar geloof me: in de embedded wereld zoek je dat uit. Zeker wanneer veiligheid kritiek is. Sterker nog: als het goed is (en dat is het vaak niet ) staat er in de requirements (en software beschrijving) exact hoe lang zo'n timer minimaal moet kunnen lopen en wat er moet gebeuren als de timer overflowed.

En dat alles is aannemend dat ze een taal gebruiken die je nog zelf controle geeft over het type, in plaats van een let, var of def, waarbij de compiler / runtime bepaalt wat het nou eigenlijk gaat zijn.

Ik kan me niet voorstellen dat ze voor zo'n systeem een hogere dynamische taal gebruiken. Ik weet vrijwel zeker dat dit een taal is met statische types. Gecompileerd.

Hoe vaak doe jij performance tests en endurance tests?

Toen ik failure analyse deed in de luchtvaart? Ik doe bijna niets anders bij dat soort opdrachten.

Ik heb overigens nooit vliegtuigen zelf of kritische subsystemen getest, dus weet de details hier niet van.

Ik neem aan dat de tests niet mals zijn en dat er ook duurtests plaatsvinden.

Veel builds gaan tegenwoordig live binnen 150 uur na build, dus zo lang zal er nooit aan 1 stuk door getest zijn...

En dan heb je het over builds voor vliegtuigen die binnen 150 uur live gaan? Waar baseer je dit op?

150 uur is niet eens genoeg om alle tests te kunnen draaien. We hebben het hier over een software build voor de luchtvaart die niet alleen een software test door moet, maar ook op hardware moet draaien die environment tests door gaat (trilling, mechanische shock, thermische schok, verkeerde voltages, EM instraling, enz).

Als dit losse systeem (kastje) dit overleeft mag hij minstens nog een aantal testvluchten mee in een echt vliegtuig. Ongetwijfeld met een minimum aantal vlieguren.

Voor dat alles gaat er helemaal niets live. En als iedereen z'n werk goed gedaan heeft gaat er in de hele historie van dat type vliegtuig maar 1 build live.

[Reactie gewijzigd door GeoBeo op 22 juli 2024 18:23]

[t_weak]

Je schrijft dat je ervaring hebt met 'failure analyse' en niet zozeer ’met het testen van vliegtuigen zelf of kritische subsystemen'. Zou je zo vriendelijk willen dit toe te lichten? Wat is het verschil? En vooral: wat is jouw werkervaring? Ik ben zeer benieuwd!

Trouwens: veel problemen zijn ontstaan, door verkeerde declaraties van variabelen als 'unsigned integers', ook wel bekend als 'short integers'. Tsja, dat scheelde weer een byte...

Wie het verschil niet weet tussen 'call by value' en 'call by reference', is uiteraard een gevaar.

Ik denk de grootste ellende is voortgekomen uit het verkeerd gebruik van pointers...

Iedereen nog enthousiast over C, C++, Java etcetera? Met alle respect, mooie talen, portable, snel en (terecht) zeer populair. En vooral: alles is mogelijk! Maar tegelijkertijd potentieel gevaarlijk, zeker indien gebruikt door iemand die over onvoldoende discipline en kennis beschikt! Trouwens, wat is niet mogelijk in assembly? Object georiënteerd werken wellicht? Maar: dat valt en staat toch bij gebruik van pointers? Sorry, ik dwaal af.

[GeoBeo]

Je schrijft dat je ervaring hebt met 'failure analyse' en niet zozeer ’met het testen van vliegtuigen zelf of kritische subsystemen'. Zou je zo vriendelijk willen dit toe te lichten? Wat is het verschil? En vooral: wat is jouw werkervaring? Ik ben zeer benieuwd!

Disclaimer: dit zijn mijn eigen woorden. Er zijn vast luchtvaart termen voor (of liever nog: afkortingen, daar houden ze enorm van ).

Faal analyse is het vinden van de oorzaak van het niet volgens verwachting functioneren van een apparaat. Inclusief fysiek kapot gaan (dus niet alleen software bugs). Het is belangrijk in het achterhoofd te houden dat apparatuur dat een vliegtuig in gaat vaak ontworpen is (of zou moeten zijn) voor zo'n 10 vliegjaar met geen/weinig onderhoud. Uit m'n hoofd. Het kan ook iets meer zijn. Een gemiddeld vliegtuig gaat zo'n 18 - 20 jaar mee. Er staat me ook iets bij dat een fabrikant vanaf het moment dat ze stoppen met de productie van een systeem, ze nog minstens 15 jaar support en reparatie diensten moeten kunnen leveren nadat het systeem dat uit productie is gegaan.

Maar goed, ik dwaal af. Vlucht kritische sub-systemen, zijn simpel gezegd alle deel systemen waar de veiligheid van het vliegtuig vanaf hangt. Als 1 van die systemen uitvallen (inclusief hun backup) is het einde verhaal en heb je een crash. Denk aan: stuurknuppels van piloten, de vleugels, het landingsgestel, het uit kunnen zetten van de autopiloot, de autopiloot zelf, enz Een niet kritisch systeem zijn dingen als: schermpjes in de stoelen voor entertainment, de stoelen zelf, de toiletten, lampjes, elektriciteit in de passagiers cabine, keuken apparatuur en hun bedrading en power supply enz. Let wel: dat die apparaten wel of niet werken is niet essentieel voor een veilige vlucht, maar ze kunnen er des ondanks wel voor zorgen dat een vliegtuig neerstort als ze ernstige fouten bevatten. Denk aan het schermpje in de stoel dat in de fik vliegt terwijl je een film kijkt

Ik schrijf hier liever niet waar ik exact aan gewerkt heb (en dat mag ik juridisch ook niet), maar het gaat dus om een elektrisch deel-systeem dat niet vlucht kritisch is

Trouwens: veel problemen zijn ontstaan, door verkeerde declaraties van variabelen als 'unsigned integers', ook wel bekend als 'short integers'. Tsja, dat scheelde weer een byte...

Wie het verschil niet weet tussen 'call by value' en 'call by reference', is uiteraard een gevaar.

Zelfs als je het verschil wel weet is het een enorm gevaar. Vooral in een taal als C of C++. Zelfs in een taal als Java kun je prima, dead locks, race conditions en data races bouwen. Zelfs als je alleen call by value doet.

Ik denk de grootste ellende is voortgekomen uit het verkeerd gebruik van pointers...

Dit schijnt inderdaad zo te zijn (herinner me daar een onderzoek over), maar er zijn genoeg andere potentiële bugs. Zomaar wat veel voorkomende: priority inversions, dead locks, data races. Allemaal mogelijk zonder pointers Zodra je iets met interrupts of threads doet loop je daar potentieel tegen aan. Zomaar een voorbeeld dat ik wel eens heb gezien dat ook niks met pointers te maken heeft: te vaak (onnodig) naar flash geheugen schrijven, waardoor het geheugen veel te snel corrupt raakt en het systeem uit gaat van incorrecte waardes (of geen waardes = vastlopen = apparaat terug sturen naar fabrikant ter reparatie).

Iedereen nog enthousiast over C, C++, Java etcetera? Met alle respect, mooie talen, portable, snel en (terecht) zeer populair. En vooral: alles is mogelijk! Maar tegelijkertijd potentieel gevaarlijk, zeker indien gebruikt door iemand die over onvoldoende discipline en kennis beschikt! Trouwens, wat is niet mogelijk in assembly? Object georiënteerd werken wellicht? Maar: dat valt en staat toch bij gebruik van pointers? Sorry, ik dwaal af.

Er zijn de laatste tijd genoeg programmeurs die stellen dat het gebruik van C, C++ e.d. in 2019 helemaal van de pot gerukt is en dat een modernere taal als Rust veel beter is, omdat die veel betere memory safety heeft. Daarmee neemt het risico op pointer en memory problemen flink af. Ik ken alleen C en C++ goed (Rust niet), maar veel erger dan C en C++ kan het niet. Dus ze zullen vast een punt hebben dat Rust beter is

Assembly kan ook, maar dat is nog erger dan C wat potentiële bugs betreft.

Object georiënteerd werken lost ook weinig van het risico van die bugs op, die staan los van je ontwerp methode en zijn gewoon inherent aan de taal die je gebruikt. Bovendien is de hele informatica gemeenschap het er niet echt over eens wat OOP nou eigenlijk precies is De definitie ervan lijkt ook te veranderen na verloop van tijd. En er zijn genoeg hele goede ervaren programmeurs die OOP onnodige en/of complexe onzin vinden.

Genoeg complexe projecten ook die volledig zonder OOP opgebouwd worden in o.a. C.

[Reactie gewijzigd door GeoBeo op 22 juli 2024 18:23]

[t_weak]

Hé @GeoBeo !

Wat een ontzettend interressant antwoord, dank je! En trouwens: gaaf dat je je houdt aan principe-afspraken wat betreft geheimhouding en integriteit. Je gaat heel concreet in op zaken die ik noem, maar die tegelijkertijd vraagtekens voor me vormen. Dat heb je goed in de gaten en je geeft heldere richtlijnen over de beste weg, zoals Rust. Intrigrerend vind ik jouw opmerking over OOP! Want: waarom zijn bijvoorbeeld Lisp, Eiffel, Object Pascal en Swift nooit zo populair geworden? Het is net als mode...

Hé, nogmaals dank!

[t_weak]

Wat mij verbaasd: kennelijk mogen dit soort machines worden gebruikt terwijl de software *niet* is bijgewerkt naar de laatste versie!!! Hoe is dat mogelijk? Wordt in de `zwarte doos' precies vermeld, welke versies van welke software in gebruik is? Of was, voordat een ernstig incident zich voordeed?

Stel je voor: het systeem wordt uitgebreid en aangepast om een herhaling van de MH17-ramp te voorkomen. Dan zou het kennelijk mogelijk zijn om rond te vliegen met een gevleugelde machine die deze aanpassing niet heeft doorgevoerd. Dat is toch onvoorstelbaar?

@Verwijderd : ik dacht dat de automatisering, van onder andere vliegtuigen, volkomen dubbel is uitgevoerd. Twee onafhankelijk van elkaar ontwikkelde en functionerende systemen, die het eens moeten zijn over een te nemen beslissing. Het lijkt me uiterst onwaarschijnlijk dat er sprake kan zijn van veel bugs. Deze software wordt uiteraard niet door bijvoorbeeld een stagiair (met alle respect) of assistent in opleiding (met alle respect) gemaakt, aangepast of getest. Denkt u dat er anders piloten zouden zijn die het aandurven telkens opnieuw het luchtruim op te zoeken en verantwoording te dragen voor alle passagiers? Begrijp me goed, ik probeer u niet aan te vallen, maar de discussie meer inhoud te geven.

Hoe raar zal het zijn: de piloot of passagier informeert onder welke versie het vliegtuig draait. Afhankelijk daarvan wordt besloten al dan niet te gaan vliegen. Hoe zit het met verzekeringsmaatschappijen? En annuleringsverzekeringen?

Off topic: zouden ze bij Tesla ook op deze manier werken? Nou, ik dacht het niet!

[JUST_me]

Stel, er wordt een probleem zoals dit ontdekt.

Een probleem dat mogelijk tot een groter probleem kan leiden.

Vind jij het dan logisch dat een regelgevende instantie direct vereist dat alle toestellen van dat type wereldwijd binnen 24 uur van een update voorzien worden?

Dat is toch niet haalbaar? Vooral widebodies als een 350 zwerven over de hele wereld. Het kan wel een week duren voordat een toestel weer terug op de home base is.... Een update is vaak meerdere uren werk.... Je kan toch niet tegen je passagiers zeggen.... Ja, sorry. U heeft het hele jaar gespaard voor uw vakantie maar we moeten 'even' een update doen en daarom is de vloot volgende week weer inzetbaar.... Of mensen die naar een bruiloft/begrafenis/belangrijke meeting/etc gaan......

Een airline heeft zowel de capaciteit niet in de vloot om dit op te vangen als bij de technische dienst......

Daarom wordt een airworthiness directive uitgevaardigd. Een toestel moet asap van een update worden voorzien en zolang dat niet gedaan is moet xxx procedure uitgevoerd worden om een fout te voorkomen.

Klinkt best logisch toch? En kennelijk werkt het, want luchtvaart staat op eenzame hoogte qua veiligheid..... Al decennia....

[Ik&www]

Ben industtieel programmeur en er zijn inderdaad soms zoveel mogelijke "what if" dat het niet te doen is om ze allemaal te voorkomen. Wat je dan idd krijgt is dat operators "leren" om problemen "op te lossen" (hand voor een sensor houden bijv.). Maar neemt niet weg dat je mag verwachten dat er netjes word geprogrammeerd (niet delen door 0, niet oneindige objecten declareren, max. waardes int/float e.d ). Lijkt mij dat de eisen en controles ook wel hoger liggen bij de luchtvaart branch (o.a.). Het is echter wel mijn ervaring dat hoe meer een operator moet doorlopen, hoe meer de kans op fouten toeneemt..

[JUST_me]

Klopt. En daarom is alles in de luchtvaart streng gereguleerd. Alles staat in procedures omschreven. De letterlijk honderden stappen/switches/schakelingen die we moeten doen zijn allemaal omschreven.

We MOETEN deze procedures tot op de letter volgen. Dan hebben we nog checklists on elkaar en jezelf te controleren. En zijn er nog systemen in het vliegtuig die de configuratie bewaken.

Oplossingen zoals jij die beschrijft (hand voor een sensor houden) zal je bij een respectabele maatschappij nooit aantreffen. Een doodzonde.

De eisen en controles zijn (binnen de westerse wereld, in andere werelddelen is het een ander verhaal) zeer streng. De controle daarop eveneens. En daarom is de kans op een fataal ongeluk in de luchtvaart 5x10-9. De industrie standaard, wereldwijd.

[t_weak]

Dank voor deze uitstekende aanvulling, die ik zelfs als rectificatie beschouw! Het is duidelijk dat u spreekt uit ervaring.

[Powermage]

Je weet dat MH17 uit de lucht is geschoten door een raket, en dat dit weinig met software te maken heeft van een vliegtuig...

" Off topic: zouden ze bij Tesla ook op deze manier werken? Nou, ik dacht het niet! "
Nee, Tesla gebruikt zijn hele vloot als beta-testers voor het zelfrijdende systeem.... die zijn nog veel erger.

[t_weak]

Het moge duidelijk zijn dat ik geenszins de ramp met de MH17 op ongepaste wijze in herinnering wil brengen. Ik ben nog maar kort actief met het plaatsen van reacties. Het is me inmiddels duidelijk, dat waar het gevoelige onderwerpen betreft, je beter je woorden kunt wegen op een goudschaaltje.

Ik schreef: `Stel je voor: het systeem wordt uitgebreid en aangepast om een herhaling van de MH17-ramp te voorkomen.

Ik heb het dus uitdrukkelijk niet over (uitsluitend) software!!!

Lees vooral: https://www.kijkmagazine....liegtuigen-uit-met-lasers

[onsgeluk]

Wat heeft software met MH17 te maken? Dat was een BUK, geen bug.

[T-men]

Wat mij verbaasd: kennelijk mogen dit soort machines worden gebruikt terwijl de software *niet* is bijgewerkt naar de laatste versie!!! Hoe is dat mogelijk?

Die machines hebben periodiek onderhoud. Hét perfecte moment om updates uit te voeren. Wanneer een gevonden bug geen direct gevaar oplevert is er geen reden om niet op zo 'n onderhoudsbeurt te wachten. Bij een kritisch probleem is het een ander verhaal, maar dat is niet waar we het hier over hebben.

@T_Men : ik dacht dat de automatisering, van onder andere vliegtuigen, volkomen dubbel is uitgevoerd. Twee onafhankelijk van elkaar ontwikkelde en functionerende systemen, die het eens moeten zijn over een te nemen beslissing. Het lijkt me uiterst onwaarschijnlijk dat er sprake kan zijn van veel bugs.

'Veel' is een relatief getal. In de luchtvaart is goed getest en zijn er hopelijk flink wat bugs weggevangen, maar dát ze er zitten is gewoon ervaring, en niet alleen de mijne.

Dan dat dubbel uitgevoerd zijn...: veel systemen zijn inderdaad dubbel UITGEVOERD (dus niet onafhankelijk van elkaar ontwikkeld) dat wat anders. En natuurlijk is alles goed getest en betrouwbaar genoeg gevonden om meet te vliegen, maar het is een utopie te denken dat alles PERFECT is.

Stel je voor: het systeem wordt uitgebreid en aangepast om een herhaling van de MH17-ramp te voorkomen.

Een ramp als de MH17 ???? Ik denk dat ik die opmerking maar even negeer....

[Reactie gewijzigd door T-men op 22 juli 2024 18:23]

[t_weak]

Mooie aanvulling. Ik heb de volgende vraag: mij is ooit vertelt door een gespecialiseerd onderhoudsbedrijf voor schepen, dat een vrachtschip was uitgerust met twee netwerken. Eentje draaide onder Novell, de ander wellicht IBM Token Ring. Linux bestond toen nog niet en Unix draaide uitsluitend op erg kostbare mini's. Verder was de software afkomstig van twee bedrijven, die uiteraard geen onderlinge banden hadden voor wat betreft softwareontwikkeling. Kortom: dubbel uitgevoerd, volstrekt onafhankelijk van elkaar. Ben ik toen niet goed voorgelicht? Het lijkt zo vanzelfsprekend... Of wordt er tegenwoordig anders gewerkt dan in die tijd? Heeft u ooit iets gelezen over de automatisering van een onderzeeboot?

[michielsweb]

Zal op zich wel meevallen meeste lr vliegtuigen vliegen 1 of 2 legs en gaan Dan vaak voor enkele uren stil staan.


Neem aan dat uit en daar a opgestart worden ook een reboot is.

[renevanh]

Een totale reboot kost nogal tijd. Het is geen auto die je even parkeert en weer opstart. Bij veel tussenstops blijven de meeste systemen doorgaans gewoon ingeschakeld en draaien op ground power.

[JUST_me]

Onze vliegtuigen staan tussen de 35-50 min aan de grond voordat ze weer de lucht in gaan. Slechts in de nacht staan ze daadwerkelijk meerdere uren stil. Een vliegtuig op de grond kost geld. Alleen vliegend levert het geld op.

Tussen twee vluchten is het niet noodzakelijk om het vliegtuig volledig opnieuw op te starten. Vaak wil je dat ook niet, vanwege de extra werkdruk.

[michielsweb]

dat bedoel ik ook JUST, als me geheugen me goed is. staan longs juist vaak overdag stil ( ochtend aankomst tegen de avond vertrek

ik ben geen expert
had iets te maken met aankomst en vertrek sloten op langere vluchten. ooit eens gelezen.