28 augustus 2023 is een dag die de Air Traffic Control medewerkers in het Verenigd Koninkrijk niet snel zullen vergeten.

Meer dan 1000 vluchten werden die dag gecanceld. Bron Sky channel.

Het complete luchtverkeer kwam tot stilstand en de gevolgen waren tot ver over de wereld merkbaar.
Wat is er gebeurd? Zelf heb ik vaak vluchtplan verwerkingssystemen geprogrammeerd. En daar ook weleens wat onverwachte zaken meegemaakt.
De NATS (Nationale Air Traffic Services) in het VK vertelde dat er een probleem was met het vluchtplan verwerkings systeem “Flight Plan Reception Suite Automated - Replacement (FPRSA-R)”.
Er was volgens hen blijkbaar sprake van een vluchtplan dat twee “waypoint markers”, ook wel Reporting Points of RP’s genoemd, namen bevatte die verschillende informatie bevatten. En dat buiten het luchtruim van het Verenigd Koninkrijk. Dat laatste lijkt mij persoonlijk minder relevant. Hoe kunnen buitenlandse RP’s verantwoordelijk gehouden worden voor een probleem binnen het eigen systeem. Nou ja …..
De software van het systeem kon dit probleem blijkbaar niet aan. Het backup systeem bevatte dezelfde software en omdat de data identiek was crashte dat daarom ook.
Wat er fout moet zijn gegaan is dat er geen goede uitzonderingsafhandeling voor een dergelijk probleem was. De integriteit van de database was waarschijnlijk niet in orde.
Het interpreteren van het vluchtplan was blijkbaar fout gegaan en het zal een tijd geduurd hebben voordat het vluchtplan dat de fout zichtbaar had gemaakt was gevonden was en was verwijderd.
Om te begrijpen wat er fout kan zijn gegaan eerst maar eens een korte beschrijving van de procedures.
Als een piloot ergens op de wereld een vlucht wil boeken moet hij eerst een vluchtplan indienen.

Vluchtplan zoals door ICAO (International Civil Aviation Organization) is voorgeschreven.

De piloot bevindt zich in een FIR (Flight Information Region). Dat is een gebied dat meestal overeenkomt met de landsgrenzen. Soms is een land zo groot dat er meerdere FIR’s zijn.
In het eerste gedeelte van het vluchtplan geeft hij aan via welke andere FIR’s hij naar zijn einddoel wil vliegen.
Daarna komen de gegevens van het vliegtuig aan de orde. De Identificatie, het type etc.
Ook geeft hij aan van welk vliegveld hij vertrekt en wat het vliegveld van bestemming is. Daarnaast de vertrektijd. Deze wordt uiteraard niet in lokale tijd maar in UTC (Universal Time Control) ingevuld.
Een cruciaal gedeelte voor ons verhaal is het route veld. De route gaat via zogenaamde airways, te vergelijken met onze snelwegen. Als er van airway veranderd moet worden gaat dat via Reporting Points (RP’s), knooppunten te vergelijken met steden. RP’s zijn vaak bakens, zoals NDB’s (Non Directional Beacons) en VOR’s (Vertical Omni Directional Radio Beacons). De piloten gebruiken deze bakens om hun positie te bepalen.
Via speciale telecommunicatie netwerken wordt het vluchtplan naar alle FIR’s verstuurd omdat men daar uiteraard wil weten wat en wanneer er iets staat te gebeuren en ook naar wie men de rekening voor het overvliegen moet versturen 😉. Vroeger werden de vluchtplannen in leesbare tekst via telex verbindingen, zogenaamde AFTN systemen, verstuurd.

2 vluchtplannen die via telex ontvangen zijn.

Binnen de FIR’s is de luchtruimte verdeeld in sectoren, die elk door een air traffic controller beheerd worden. Er zijn verschillende functies controller. Een runway controller, die zich bezig houdt met de veiligheid op het vliegveld, een approach of terminal controller, die verantwoordelijk is voor een gebied, de zogenaamde TMA, rondom het vliegveld (bijv. een cirkel van 100 mijl en een bepaalde hoogte). Deze begeleidt aankomende en vertrekkende vliegtuigen via SID’s en STAR’s (Standard Instrument Departure en Arrival routes). En tenslotte de sector controllers die de rest coördineren.
Het door een FIR ontvangen vluchtplan wordt nu verwerkt voor alle betrokken sectoren. De airway’s zijn eigenlijk een lijst van RP’s. De totale lijst van RP’s wordt verwerkt door het vluchtplan verwerking systeem met gebruikmaking van de geschatte aankomsttijd in de FIR tijd om op de geschikte tijden informatie aan de betrokken Air Traffic Controllers te sturen. Dat gaat in de vorm van Flight Progress Strips. Deze zijn gebaseerd op Posting Points. Dat zijn speciale Reporting Points, waarop de piloot zich bij de controller dient te melden. De Controller kan alle strips van verschillende vluchten op tijd sorteren en zo weet hij welke vlucht zich op een bepaalde tijd bij hem zal melden (posten).
Hierbij is de regel dat een niet aangemelde vlucht geweigerd zal moeten worden omdat er geen strip voor is gemaakt. De controllers zien dan dat er geen “clearance” voor die vlucht is. In de toren in Jeddah in Saoudi Arabie maakte ik dat ook eens mee en de controller gaf die vlucht de identificatie “Camel” 😉
Er zijn verschillende mogelijkheden om een vluchtplan in te voeren.
De van oudsher gebruikelijke manier is gebruik te maken van een TFIL (Telex Filed Flight Plan). Als de piloot het vluchtplan heeft ingevoerd wordt het per “telex” naar de FIR’s gestuurd.
Ook kan de piloot vanuit zijn cockpit een vluchtplan “sturen”. Dat heet een AFIL (Air filed Flight Plan).
In het geval van regelmatige vluchten is het gebruikelijk om Repetative Flight Plans (RPL) te gebruiken. Hierbij bevat een database vluchtplannen die op specifiek dagen en tijden actief worden. Dit scheelt uiteraard tijd voor de piloten en de maatschappijen.
Wat gebeurt er in het software systeem.
De vluchtplannen worden op een tijd voordat de vlucht binnenkomt of vertrekt ingelezen en op syntax en semantiek gecontroleerd. Dat gebeurt met een zogenaamde parser. Dat is een computerprogramma dat met behulp van tabellen het vluchtplan controleert en extraheert. De route is in ons geval het relevantst. De airways en de reporting points worden omgezet in een lijst van punten. En voor de posting points worden dan op gezette tijden strips gegenereerd voor de betreffende controller.

2 “paper strips” voor Jeddah airport met een M78i (Mannesmann) printer geprint en afgesneden,

De controller stopt ze in een strip houder, zet ze in een rek en sorteert ze op tijd. Tegenwoordig gebeurt dit ook vaak via een scherm en wordt door de software gedaan.
Niet alle controllers vinden dit handig want ze schreven nog weleens wijzigingen op de papieren strips.

Flight Progress Strips voor posting point BTN op tijd op een scherm gesorteerd.

Wat er fout kan gaan is dat de syntax en semantische informatie van RPL’en tussentijds verandert. De syntax controle gaat over de volgorde van het vluchtplan bijv. (FPL- etc. De symnatiek gaat over de inhoud van een veld. De route bestaat uit een volgorde van RP’s en airways en andere informatie zoals bijv. een geplande hoogte verandering. Er kan echter een airway veranderen of een reporting point kan van naam veranderen.
In dat geval is het mogelijk dat een RPL in de database met een bepaalde versie van de parser tabellen is ingevoerd. Als de tabellen (de symantiek) daarna wijzigen betekent dat dus dat voor bepaalde vluchtplannen RPL informatie in de database niet meer correct is. Het vluchtplan computer programma gaat er echter van uit dat de RPL informatie correct is.
Misschien zijn de RPL’en niet afdoende gecontroleerd nadat een route wijziging in de parser tabellen is ingevoerd. Als dan zo’n RPL geactiveerd wordt kan het programma dat zeker niet aan. Dan help een backup systeem ook niet meer want die werkt alleen voor het programma en de computers maar niet voor de database.
Wat er precies fout is gegaan is mij niet bekend maar mijn scenario is plausibel.
Sinds mijn professionele activiteiten met ATC systemen is er wel het een en ander veranderd. De telex bestaat in elk geval niet meer 😉