Monteur trekt in z'n eentje de stekker uit het NOTAM systeem en legt vliegverkeer in de VS plat...

[Koning Lucht]

What is NOTAM? Here’s what caused the F.A.A. outage.

NOTAM alerts — short for Notice to Air Missions — are crucial to planning flights.

www.nytimes.com

FAA flight grounding debacle was caused by engineer

The grounding of all flights and FAA systems failure that occurred Wednesday morning across the United States was caused by a mistake made by an engineer.

www.dailymail.co.uk

Volgens de (normaal gesproken slecht geïnformeerde) pers, werd de storing in het NOtice To AirMen (ik verdom het om de nieuwe afkorting te gebruiken) systeem veroorzaakt door één monteur die een corrupt bestand op een server zette, veroorzaakt. Nou ben ik geen IT expert, maar dit lijkt op een 'single point of failure'. Als een vliegtuigfabrikant dit zou ontwerpen, zou die door de FAA voor rotte vis worden uitgemaakt en erger. Kan iemand die hier meer verstand van heeft uitleggen wat hier is misgegaan?

De NTSB heeft een aantal jaar geleden het NOTAM systeem al eens een "pile of garbage" genoemd, nadat Air Canada bijna bovenop 5 vliegtuigen landde die op een parallelle taxibaan stonden te wachten om te vertrekken. Dit was in San Francisco waar een van de parallelle banen buiten gebruik was. Dit was gemeld in het NOTAM systeem, maar er waren zoveel totaal nutteloze NOTAMS over taxilichtjes, hijskranen en obstakels dat de bemanning de belangrijke NOTAM over het hoofd had gezien. Hierdoor waren ze met de taxibaan op-gelijnd, omdat ze verwachtte op de rechterbaan te landen. De verlichting op de gesloten linkerbaan stond uit, wat bijdroeg aan de verwarring...

Op een vlucht van 2,5 uur binnen de VS krijgen wij regelmatig een briefing-pakket van 50 pagina's mee. Hoe gaat dat bij jouw vliegclub?

 

[PPP]

Als IT'er kan ik met zo weinig informatie ook weinig uitleggen. Een bestand vervangen? Wat voor bestand? Een programma? Een databestand? Een configuratiebestand? Bij moderne computersystemen worden dit soort updates gedaan door een geautomatiseerde procedure die je eerst uitvoert op de ontwikkelomgeving, dan op de testomgeving, dan op de gebruikersacceptatieomgeving en uiteindelijk op de productieomgeving. Omdat het geautomatiseerd gebeurt gebeurt er op al die omgevingen precies hetzelfde en kun je dus fouten in het bestand veel eerder constateren. Als mensen tenminste de moeite nemen om na de update iets te testen.

De grote hoeveelheid NOTAMs verbaast mij ook altijd. We zien al sinds het begin van de oorlog in Oekraïne drie NOTAMs langskomen. Zo uit mijn hoofd: 1. Je kunt beter niet over Oekraïne vliegen want daar is oorlog. 2. Vliegtuigen uit Rusland mogen niet in het Nederlandse luchtruim komen. 3. Vliegtuigen uit Belarus mogen niet in het Nederlandse luchtruim komen. Erg belangrijk als je van Lelystad naar Texel vliegt.

 

[berggeit]

Volgens interview hier

US flights grounded because engineer accidentally 'replaced one file with another': Official

The FAA is monitoring its systems at 'high level' after its NOTAM failure grounded all planes, a senior official told ABC News.

abcnews.go.com

ging het om een "Database file". Als dat klopt, is dat een aanwijzing wat hier misgegaan kan zijn.

De "engineer" waar ze het over hebben is dan geen monteur maar een IT operations engineer, die tijdens 'routine maintenance' een fout gemaakt zou hebben. Nou zie ik niet waarom je tijdens 'routine maintenance' met je typvingers aan de interne bestanden van een database zou moeten zitten, maar à la.

Om het even in niet-IT termen uit te leggen: Databases zijn altijd een achilleshiel van IT systemen geweest, en tegen beschadigde data zijn ze vaak slecht beveiligd. Zeker bij oudere database systemen zijn de systemen zelf misschien wel dubbel uitgevoerd of beter, maar de data wordt soms klakkeloos gesynchroniseerd tussen die verschillende zogeheten replica's. En als daar dan wat aan mankeert, dan ben je gezien - dan zijn ze allemaal tegelijk stuk. Dat is een beetje alsof je wél drie airspeed indicators hebt, echter maar één pitot. En laat daar nou net een wesp in nestelen.

Dus deze engineer heeft het systeem dan precies daar geraakt waar het pijn deed. Dat die engineer vervolgens onbekend zou zijn, lijkt me heel vreemd. Dat is OF niet waar, OF ze hebben qua beveiliging/auditing iets ernstig niet op orde bij de FAA. Niemand hoort zoiets te kunnen doen zonder dat op z'n minst bekend is onder wiens verantwoordelijkheid dat gebeurd is.

En waarom zijn die systemen dan niet volledig gescheiden? Heel simplistisch gezegd: een nieuwe NOTAM moet meteen op alle replica's weggeschreven worden. Het is die wens, die zelfs een meervoudig uitgevoerd systeem kwetsbaar maakt. Wil je dat echt volledig scheiden, dan moet je elke nieuwe NOTAM drie keer in laten voeren door drie verschillende mensen op drie verschillende, volledig gescheiden computersystemen. En die vervolgens doorlopend automatisch met elkaar vergelijken. Dan pas heb je iets wat vergelijkbaar is met de systemen aan boord van een vliegtuig. Zo'n procedure scheelt misschien ook in het aantal NOTAMs, dat wel

Waarschijnlijk hebben ze in dit geval dus het hele systeem - alle replica's - van een backup terug moeten zetten, omdat alle "online" exemplaren verprutst waren. Dat kost tijd, zeker als het een oud systeem is.

Er bestaan wel databases die beter tegen dit soort problemen bestand zijn, maar die zijn waarschijnlijk van recenter datum dan het oude NOTAM systeem.

Deze uitleg zit natuurlijk vol met speculatie en aannames, maar daar vroeg je om ;-)

 

[berggeit]

Wat ik niet begrijp is hoe het NOTAM systeem in Canada een vergelijkbaar probleem kreeg. Gaat het hier dan niet om een probleem met een databestand, maar om een software update aan die database, die in Canada precies zo uitgevoerd is? Dat zou inderdaad onder 'routine maintenance' vallen.

Maar dan heeft die engineer geen fout gemaakt. Dan zat er een probleem in die update. Maar dan zeg ik ook wat PPP zegt: daar heb je toch een test of acceptatie omgeving voor, om te voorkomen dat een kapotte update schade aan kan richten? En ook eentje in Canada?

Wat gebruikelijk is, zeker bij oudere systemen, is dat je een volledige kopie van het productie systeem hebt staan en daar al je updates eerst op uitprobeert en zorgvuldig test, voordat je ze naar 'de klant' brengt. En dan heb je daar bovenop liefst nog een procedure om een update snel terug te kunnen draaien. Dat dat blijkbaar niet kon, zou toch weer op een probleem in de databestanden kunnen wijzen.

Kortom, dit begrijp ik met de beperkte beschikbare informatie ook niet helemaal. Maar net als bij vliegtuig ongevallen - er gaat ontzettend veel bijna mis waar je nooit wat van hoort. Alleen die ene 'perfect storm' waarbij alles tegelijk foutging komt in het nieuws.

 

[Europe-American]

Sinds de deregulering van de luchtvaart industrie onder Reagan is het een houtje touwtje zooitje.
FAA wordt gerund door gepensioneerden en hun budget is uitgehold.
Zal me niets verbazen als dit allemaal op Windows 2.0 en floppy’s draait.
Die hele ATC infrastructuur hangt van single point of failures aan elkaar.

 

[digits]

Wat ik niet begrijp is hoe het NOTAM systeem in Canada een vergelijkbaar probleem kreeg. Gaat het hier dan niet om een probleem met een databestand, maar om een software update aan die database, die in Canada precies zo uitgevoerd is? Dat zou inderdaad onder 'routine maintenance' vallen.

Maar dan heeft die engineer geen fout gemaakt. Dan zat er een probleem in die update. Maar dan zeg ik ook wat PPP zegt: daar heb je toch een test of acceptatie omgeving voor, om te voorkomen dat een kapotte update schade aan kan richten? En ook eentje in Canada?

Wat gebruikelijk is, zeker bij oudere systemen, is dat je een volledige kopie van het productie systeem hebt staan en daar al je updates eerst op uitprobeert en zorgvuldig test, voordat je ze naar 'de klant' brengt. En dan heb je daar bovenop liefst nog een procedure om een update snel terug te kunnen draaien. Dat dat blijkbaar niet kon, zou toch weer op een probleem in de databestanden kunnen wijzen.

Kortom, dit begrijp ik met de beperkte beschikbare informatie ook niet helemaal. Maar net als bij vliegtuig ongevallen - er gaat ontzettend veel bijna mis waar je nooit wat van hoort. Alleen die ene 'perfect storm' waarbij alles tegelijk foutging komt in het nieuws.

Canada beweert dat het ongerelateerd was. Het zou daar ook enkel het toevoegen van nieuwe notams zijn geweest wat niet meer werkte.

 

[berggeit]

Ze zullen in elk geval (harde) lessen trekken. Dit 'incidentje' was vast een stuk duurder dan een fatsoenlijk systeem bouwen.

 

[PPP]

Dit 'incidentje' was vast een stuk duurder dan een fatsoenlijk systeem bouwen.

Voor wie? De kosten die nu gemaakt zijn komen op rekening van de luchtvaartmaatschappijen. De FAA is verantwoordelijk voor het computersysteem. Ander budget. Geen leverancier/klant-relatie waarbij je als klant een schadeclaim naar de leverancier kunt sturen.

Vergelijk het even met onze Belastingdienst. Die geven zo veel geld uit aan het in de lucht houden van ouwe meuk dat niemand er meer wil werken en er ook geen geld is om het opnieuw te bouwen. Interessant leesvoer: https://www.nrc.nl/nieuws/2023/01/1...gdienst-honderden-miljoenen-per-jaar-a4154058.

 

[berggeit]

Ook weer zo, maar de FAA voelt indirect ook wel pijn hoor.

De belastingdienst zou eens kunnen beginnen met marktconform betalen. Niet alleen de oude zooi is reden dat ze niet aan personeel kunnen komen. If you pay peanuts...

Maar dat terzijde.

 

[Koning Lucht]

Ook weer zo, maar de FAA voelt indirect ook wel pijn hoor.

Mwoah, ik denk dat dat wel meevalt. Er wordt niemand ontslagen. Er komt een rapport "met de kennis van nu..." en iedereen drinkt een glas, doet een plas en alles...

De maatschappijen moeten bij vertraging (die binnen hun schuld valt) fors betalen aan passagiers, als ze ze te lang aan boord houden. Het lijkt mij redelijk dat de FAA nu een vergelijkbare som zou moeten betalen voor de vertraging van de vluchten door de FAA. Dat gaat natuurlijk nooit gebeuren, maar zou een financiële prikkel kunnen zijn om de FAA te motiveren hun zaakjes op orde te houden.