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.'
Al in 2007 publiceerde Computable het artikel “ICT-vernieuwing Prorail duurt nog jaren” (zie https://www.computable.nl/artikel/achtergrond/beheer/1973454/1277800/ictvernieuwing-prorail-duurt-nog-jaren.html) , beginnend met de regel “In 2008 neemt de kans op verstoringen volgens Prorail af omdat de computersystemen dan met een back-up zijn uitgevoerd”. Jaren dus inderdaad…
Read more: https://www.computable.nl/artikel/achtergrond/beheer/1973454/1277800/ictvernieuwing-prorail-duurt-nog-jaren.html#ixzz1psYyxh8x
Wat me hier opvalt, maar dat komt steeds vaker voor, is dat ‘de wet van Murphy’, steeds vaker een grote rol speelt in een materie als IT. Het bevreemd me namelijk dat dit soort fouten optreden en dat men een redundancy, tenminste, corrigeer me in deze als ik het niet bij het juiste eind mocht hebben, heeft geïmplementeerd, fouten op te vangen die dan vervolgens ook niet werkt.
Ik kan me niet aan de indruk onttrekken dat implementaties steeds vaker worden geïmplementeerd met geloof op onschuldig knipperende bruine of blauwe ogen met dit soort te voorziene gevolgen.
Al ben ik natuurlijk intrinsiek niet op de hoogte van hetgeen men heeft geïmplementeerd, ik weet nog altijd wel dat wanneer men zelfs van de meest basale kennis van IT en ITIL zaken zou hebben neergezet, men hier niet tegen aan zou zijn gelopen.
Maar wie ben ik. Ik hoef de frustratie van de benadeelden niet aan te horen en sterker, ik hoef de rekening niet te betalen.
@NumoQuest:
ik kan me wel voorstellen dat ICT-inrichtingen die volgens ITIL en Prince2 richtlijnen ingericht zijn toch een storing kunnen vertonen. Het probleem lijkt meer: de onbeheersbare situatie met gedeeld beheer tussen NS en ProRail.
Op één punt ben ik het niet met je eens: de rekening ligt nl bij eenieder van ons belastingbetalers.
Typisch een geval van overmacht.
Verbaast me dat zo’n failover blijkbaar niet goed getest wordt dan…
“Het bevreemd me namelijk dat dit soort fouten optreden…”
Juist deze naïeviteit (niet negatief maar wel realistisch bedoeld; in het algemeen dus), zorgt dat er onverantwoordelijk veel mensen vóór kernenergie zijn. Ook bij kernenergie speelt software een steeds grotere rol.
Het is en blijft nl. allemaal mensenwerk. Zelfs als je een ‘passief’ veilige kerncentrale hebt, want de mens is altijd slimmer dan de machine die ie bediend die bedoeld is om de fouten van de mensen op te vangen.
“… en dat men een redundancy (..) heeft geïmplementeerd, fouten op te vangen die dan vervolgens ook niet werkt.”
100% Redundancy is uitermate duur, indien al mogelijk. En al helemaal als er iets uiterst ingewikkelds als software en/of onregelmatige benodigde updates bij betrokken zijn.
En 2,5 uur later wist men op de stations in het land niet de details wat wel of niet reed?
De info die ik kreeg was dat er t/m Amsterdam Zuid gereden werd.
In Amersfoort de trein uitgegooit, en conform ‘de wet van Murphy’ ging de trein terug ook niet meer.
Noemt de conducteur die je cynisch antwoord dat het allemaal wel went je een pessimist 😉
Als software niet doet wat het doen moet of had moeten doen, zoals hier dat de ‘schakelsoftware’ niet werkte, vraag ik af: Had de back-up niet handmatig ingeschakeld kunnen worden? Ik bedoel, die schakelsoftware voorziet waarschijnlijk in het geautomatiseerd afhandelen van een procedure, die, in mijn ogen, ook altijd handmatig uitgevoerd moet kunnen worden. Vergelijk het handboek in een vliegtuig, waarin voor de meest voorkomende problemen een andere procedure staat beschreven. En het inschakelen van een back-up lijkt me nu niet het meest ingewikkelde. Of het moet zijn dat Prorail onvoldoende competent personeel heeft om zoiets snel te regelen. Maar ja, ik sta ‘op de wal’ zeg maar.
“…en sterker, ik hoef de rekening niet te betalen.”
Niet alleen het spoor zelf maar ook een groot deel van de andere mensen die niet op hun werk kunnen komen, worden betaald door u en ik (nl. door onze belastingen).
Het is wat naïef te denken dat het de ’toeschouwer’ niks kost als ‘het spoor’ fouten maakt.
“…ik weet nog altijd wel dat wanneer men zelfs van de meest basale kennis van IT en ITIL zaken zou hebben neergezet, men hier niet tegen aan zou zijn gelopen.”
Ik weet nog altijd wel dat wanneer er men nog zoveel geld tegenaan gooit, dat systemen waar software bij betrokken is, altijd kunnen mislopen al bouw je financieel gezien onverantwoordelijk veel redundancy in.
Een (ver) doorgevoerde ITIL blijkt in de praktijk vaak niet alleen duur/inefficient, belemmerend en bureaucratisch te werken, maar ook zelf weer voor nieuwe problemen te kunnen zorgen.
En er was natuurlijk geen back-up voor de schakelsoftware …