Managed hosting door True

'Schakelsoftware back-up oorzaak treinchaos'

ProRail: Fout doet zich nergens anders voor

 

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.'

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4459158). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Al in 2007 publiceerde Computable het artikel "ICT-vernieuwing Prorail duurt nog jaren" (zie http://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: http://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.

"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.

Verbaast me dat zo'n failover blijkbaar niet goed getest wordt dan...

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 ;)

"...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.

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 er was natuurlijk geen back-up voor de schakelsoftware ...

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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×