Haperende schakelsoftware die het back-upsysteem moest inschakelen is de oorzaak van de treinstoring op 22 maart 2012 in en rond Amsterdam. Door de ict-storing konden de seinen en wissels rondom de hoofdstad niet bediend worden. Spoorbeheerder ProRail zegt maatregelen genomen te hebben om herhaling te voorkomen.
Bij het opstarten van de treindienst trad in één van de systemen op de verkeersleidingspost Amsterdam een storing op. Alle systemen bij ProRail zijn meervoudig uitgevoerd om dergelijke storingen op te vangen. Echter, bij het overschakelen naar het back-upsysteem heeft zich een fout voorgedaan in de schakelsoftware en kon het back-upsysteem niet in werking treden. Vervolgens konden de seinen en wissels niet bediend worden.
‘We hebben vanochtend direct gecontroleerd of de softwarefout van Amsterdam zich ook op andere verkeersleidingsposten kon voordoen', aldus een woordvoerder van de spoorbeheerder. ‘Dat is niet het geval. Rond 4.30 uur donderdagmorgen trad de storing op. Om 8.40 uur was de softwarefout hersteld en konden de seinen en wissels weer worden bediend.'
Ik ben benieuwd wie hier nu precies verantwoordelijk is. Is dat Pro-rail zelf of hebben ze hier een externe partij voor?
Het inrichten van heldere processen op basis van ITIL zoals Numoquest stelt kan helpen maar is absoluut niet de oplossing voor alles.
Je kan als bedrijf-zijnde fantastische processen en procedures hebben, maar als ze niet correct en tijdig worden uitgevoerd heb je er helemaal niets aan.
Toen ik voor de Gasunie werkte werd het dubbel-uitgevoerde centrale SCADA systeem elke dag omgewisseld van het ene systeem naar het andere. Met andere woorden: de schakelprocedure werd elke dag getest, 365 dagen per year. Herstel van een database backup werd ook letterlijk elke dag getest. Voor dit soort kritische systemen lijkt mij dat geen overbodige luxe.
Tja, blijkbaar was door de software alles bevroren.
Oplossing : voorverwarmen?
Wat ik mij afvraag is waarom hebben bedrijven nog steeds een active/standby configuratie voor dit soort systemen en gaan ze niet voor de active/active configuratie met een max van 45% capaciteit verbruiken op beide sites. Je weet tenminste op zo’n manier dat je altijd twee werkende systemen heb.
Omdat dit waarschijnlijk een systeem is wat alle acties synchroon uitvoert, maar het echte schakelen enkel door de “Master” gebeurt.
het is niet te “Load Balancen” omdat je dan onzekerheid kunt hebben over wie wat mag schakelen.. “Collision Detection” zou niet werken met echte treinen ipv met bitjes op een netwerk…
“schakelsoftware” wat is dat nu weer? Nooit van gehoord. Mislukte poging om IT in lekentermen uit te leggen?
Nu weten we nog niets. Was het de infra, de applicatieserver of de applicatie zelf? Clustering? load balancing?
Computable is een IT blad, leg ons gewoon uit wat er aan de hand is.
Volgende keer even journalistiek werk doen en een belletje naar Prorail?
Goh, dit soort problemen waren bij de Rabobank al twintig jaar geleden opgelost met Tandem en K20.000 systemen.
Er zijn fout-tolerante systemen genoeg, maar in het spoor is men eigenwijs…
Voor deze storing is geen excuus.
De software krijgt weer eens de schuld.
Het treinverkeer lag donderdag 22 maart weer eens stil. Nu eens niet rond Utrecht maar rond Amsterdam. Geen blaadjes, geen sneeuw dus wie krijgt dan de schuld? De software. Een fout in de schakelsoftware maakte dat de verkeersleiding na een systeemstoring niet snel kon herstellen.
Waar precies die fout in de software zit en hoe het verbeterd moet worden is dan natuurlijk de eerste vraag. Maar wat eigenlijk veel belangrijk is, is de vraag wie de fout heeft gemaakt en nog belangrijker is de vraag waarom die fout niet is gevonden. Iedereen maakt namelijk fouten. Dat is onvermijdelijk bij het creëren van complexe softwaresystemen. Daarom wordt er geverifieerd of er geen fouten zijn. Dat gaat meestal door middel van testen. Maar de systemen zijn te complex om alles te kunnen testen. Dat zou jaren en jaren duren.
Daarom moeten er keuzes gemaakt worden. Welke onderdelen zijn het meest kritisch? Die onderdelen moeten aan een intensievere test onderworpen worden. De meest intensieve testen maken gebruik van formele methoden. Een model wordt opgesteld van waaruit testen gegenereerd worden. Als de resultaten met het model overeenkomen, dan is het goed. Zo niet dan is er een fout gevonden die gecorrigeerd moet worden.
Een academisch software engineer moet in staat zijn om te beslissen welke onderdelen intensiever geverifieerd moeten worden en waar nodig de modellen te maken om de tests te genereren. Model-based testing wordt echter nog maar weinig toegepast in de praktijk. Ik heb het vermoeden dat het daar bij de schakelsoftware aan ontbroken heeft. Gelukkig zijn er academische Masters Software Engineering aan de Universiteit van Amsterdam (voor deeltijdonderwijs) en aan de Open Universiteit (voor afstandonderwijs). Als de daar opgeleide software engineers de systemen van de toekomst ter hand nemen, dan komt het wel goed met het treinverkeer. Waarschijnlijk krijgt de software dan niet meer de schuld.
Professor Marko van Eekelen, Hoogleraar Software Technologie, Open Universiteit.