Systeem dat perron toewijst aan treinen veroorzaakte storing Schiphol

Een bug in de software die automatisch een perron toewijst aan treinen, veroorzaakte dinsdag de grote treinstoring rond Amsterdam en Schiphol. Een trein stond net op de verkeerde plek, waardoor de software dacht dat er 32.768 keer een trein aankwam en een integer overflow veroorzaakte.

De software, die ProRail aanduidt als DVM of dynamisch verkeersmanagementsysteem, moest een perron toewijzen aan een trein, toen een winkeldief de spoortunnel in vluchtte, waardoor de trein stil moest staan. Vervolgens bracht een medewerker handmatig een mutatie aan voor die trein, meldt ProRail. Daardoor raakte de software in de war.

Door een bug probeerde de software 32.768 keer de trein een perron toe te wijzen, waarna het DVM crashte, meldt de NOS. Daardoor gaat het volgens Tweakers-ontwikkelaar Kees Hoekzema vermoedelijk om een signed 16-bits integer overflow. Volgens ProRail is de software aangepast, zodat de integer overflow niet meer voor kan komen.

Het DVM is nodig, omdat treinen die op Schiphol aankomen pas op het laatste moment een perron toegewezen moeten krijgen. Zo zijn er minder sporen nodig in de tunnel en kon de tunnel kleiner en goedkoper gebouwd worden. Na de bug moesten medewerkers de treindiensten met de hand regelen, wat zorgde voor enorme vertragingen. Uiteindelijk loste ProRail de bug 's nachts op, waarna alle treinen weer als normaal konden rijden.

Reacties (96)

KoffieAnanas 22 augustus 2018 19:05

Een trein wordt volgens mij toegewezen aan een spoor, en niet een perron. De treinen op Schiphol hebben in principe een vast perron dat ze aandoen. Alleen het spoor kan wisselen. De trein stopt of links of rechts op het perron, spoor X of spoor Y.

Edit:
In Nederland gebruikt de NS inderdaad het spoor om de locatie van de trein aan te duiden, en niet het perron. Aan een perron kunnen meerdere sporen liggen. Apart dat ProRail het zelf heeft over het perron ipv spoor. Misschien zijn ze zelf het spoor bijster na deze softwarefout.

https://nl.m.wikipedia.org/wiki/Perron_(platform)

@jpsch Dat klopt, maar dat is dan bijvoorbeeld spoor 5a en spoor 5b. Zo staat het op de perrons aangeduid.

[Reactie gewijzigd door KoffieAnanas op 22 juli 2024 22:52]

jpsch @KoffieAnanas • 22 augustus 2018 19:18

Maar je kunt ook nog a en b hebben op een perron.

faim @jpsch • 22 augustus 2018 20:19

Wij hebben spoor 35 in Nijmegen

jpsch @faim • 22 augustus 2018 20:34

Lachen.

https://indebuurt.nl/nijm...op-station-nijmegen~8876/

Jerie

@faim • 25 augustus 2018 20:25

In Sittard is/was een Spoor 20. De andere 2 sporen waren 1 en 2. 20 was anders te bereiken. Daarvoor hoefde je (vanuit het busstation & centrum) niet via de trap/lift naar beneden onder de andere sporen door.

[Reactie gewijzigd door Jerie op 22 juli 2024 22:52]

Arator @KoffieAnanas • 22 augustus 2018 21:21

Dus bij ons werd er vroeger (vooraleer het automatisch gebeurde) al wel eens omgeroepen, "Spoor 9, spoorwijziging, de trein naar Brussel zal vertrekken van spoor 10. Zelfde perron, draai u om"

Een perron is een bouwsel dat toegang verleend naar naastliggende sporen. Een perron kan toegang geven tot meerdere sporen, spoorgedeeltes (zones a, b, ...)
Dan heb je nog de sporen, die genummerd zijn voor het gemak van de reiziger. En liefst zo logisch mogelijk. Herentals mist bijvoorbeeld een spoor 4, naast spoor 3 ligt spoor 5.

Antwerpen-Centraal gaat tot spoor 24, maar heeft in totaal maar 14 sporen. Voor het gemak telt men op +1 van 1 tot 6, op niveau -1 van 11 tot 14, en op -2 van 21 tot 24. Op zich wel logisch. (Bij Brussel-Noord spreekt men ook wel eens van spoor 13 (NSFW), ligt echter buiten het station

)
En voor het gemak van het spoorwegpersoneel op het seinhuis, heb je nog de nummers van de spoorvakken langs het perron.

[Reactie gewijzigd door Arator op 22 juli 2024 22:52]

KoffieAnanas @Arator • 22 augustus 2018 21:51

Precies. En dan heb je in Nederland ook nog de treinlengtebordjes, of hoe je die ook mag noemen. Velen weten dit niet, ze vallen pas op als je er bekend mee bent. Je kunt via een app vooraf kijken hoe lang de trein is, en vervolgens weet je precies waar de voorkant van de trein stopt door naar het treinlengtebordje te kijken. Mits de machinist zich daar houdt, sommigen zijn niet zo exact... Een trein van dezelfde lengte zou altijd op dezelfde plaats tot stilstand moeten komen.

Arator @KoffieAnanas • 23 augustus 2018 08:58

Die hebben wij ook, maar die bevinden zich in het spoor, en zijn dus niet bedoeld voor de reizigers, maar enkel voor de treinbestuurder. Die bordjes hebben een officiële naam maar ik vergeet die steeds.
Voor HST-materiaal is/was er wel een aanduiding op het perron omdat daar de reiziger een specifieke plaats op de trein krijgt toegewezen (plaats x rijtuig y). Als de reiziger dan al staat ter hoogte van zijn rijtuig, maakt dit het boarden sneller en gemakkelijker.

B64

@KoffieAnanas • 22 augustus 2018 20:14

Mooi betoog, maar uiteindelijk is het lood om oud ijzer... Een ander spoor betekent op Schiphol ook een ander perron.

Volgens NOS.nl hebben treinen op Schiphol geen vast perron, maar een vast combinatie (bijv. 5 of 6), als gevolg van besparingen bij de bouw van de tunnel.

KoffieAnanas @B64 • 22 augustus 2018 21:45

Dat is incorrect. Ik ben regelmatig op Schiphol. De treinen hebben een vast perron, maar geen vast spoor.

Een ander spoor betekent op Schiphol niet dat het ook een ander perron is. Een ander spoor kan hetzelfde perron betekenen, en dit is meestal ook het geval. Alleen bij uitzondering, zoals calamiteiten, komt een trein niet aan op het vaste perron.

Jojakim 22 augustus 2018 19:09

Zo fragiel mag een van de belangrijke verkeerssystemen van dit land toch niet zijn? Ik vind het eigenaardig dat dit mogelijk is. Je zou toch zeggen dat incidenten meteen geïsoleerd moeten kunnen worden en niet zo'n grote regio voor uren moeten kunnen platleggen.

Jur_ @Jojakim • 22 augustus 2018 22:09

je vergeet dat de oorzaak (na de winkeldief) het menselijke ingrijpen is geweest. Mijns inziens gaat het dus eerder om het ontbreken van protocollen in handelen bij noodsituaties dan een fragiel software systeem. Als je al iets de schuld mag geven. Het leven van de winkeldief is bij deze dus gespaard gebleven.

thegve @Jur_ • 22 augustus 2018 23:59

Zweverig gedoe allemaal. Software had een check moeten bevatten die controleert of de input (de treindetectie) waarschijnlijk is, dat wil zeggen, dat er niet < x seconden al een trein is geweest, en daarnaast zou je nog een check kunnen hebben of er vervolgens een trein verschijnt op het betreffende spoor. Gezien het om mensenlevens gaat had het systeem bij het falen van de check vervolgens een totale shutdown moeten doen, alle treinen stopzetten.
Dat deze checks er niet in zitten, is op zich niet zo verwonderlijk, want een raar scenario, maar een bug is het wel. De kunst van de software ontwikkeling is om rekening te houden met het falen van alles, en dan toch nog de juiste actie doen.
In zijn algemeenheid kan je er rekening mee houden dat sensoren raar doen, dus controleren of de output van de sensor wel kan kloppen.

Jur_ @thegve • 23 augustus 2018 08:34

Tja, en de volgende keer zit er een andere software engineer en die bedenkt op het moment supreme een andere aanpassing. Dan zou je blij zijn dat er afspraken zijn gemaakt. Je weet dat hele ziekenhuizen runnen op dit zweverige gedoe?

thegve @Jur_ • 29 augustus 2018 18:42

Ik heb geen idee wat je probeert te zeggen, maar ik hoop wel dat als er een hartsensor in het ziekenhuis denkt dat mijn hartslag 1 bpm of juist 15000 bpm is, hij niet volautomatisch 300 liter medicijnen naar mijn infuus stuurt. Die input is volstrekt onlogisch namelijk, en daar gaat het om.

fo0 @Jojakim • 22 augustus 2018 20:07

Fragiel? Hoeveel fouten heeff dit systeem gemaakt? Een edge test zoals deze had gepakt kunnen worden maar is gewoon niet geschreven ommdat het ik de praktijk niet voorkomt. Nou ja; tot vandaah dan. Waarom zou je software compliceren voor situaties die nooit voorkomen.

Jojakim @fo0 • 23 augustus 2018 16:49

Het lijkt me dat er dagelijks wel treinen stilstaan op een punt tussen stations en dat er tientallen keren per jaar mensen op het spoor vallen/springen/lopen, met stilstaande treinen als gevolg.. Een realistisch scenario om rekening mee te houden dus.

fo0 @Jojakim • 23 augustus 2018 17:48

Dan was de situatie al eerder voorgekomen.

TheekAzzaBreek @Jojakim • 22 augustus 2018 19:27

Dat is een tweede fout, waar ik verder nog niet veel over gelezen heb. Als een centrale uitvalt, hoort een andere het over te nemen, in dit geval de centrale van Utrecht. Dat is niet gelukt, en dat lijkt me het belangrijkste probleem.

Dat een combinatie van omstandigheden die je vooraf niet hebt weten te verzinnen en dus niet getest hebt, tegen een onbekende bug oploopt is nooit uit te sluiten. En al helemaal niet met event-driven systemen. Het aantal mogelijke combinaties is gewoon te groot, en de variatie is altijd groter dan je je vooraf kan voorstellen.

Maar dat je fail-over niet werkt is een rampzalige fout, blijkt maar weer eens. En dat is wel te testen.

gekkeh3nk @TheekAzzaBreek • 22 augustus 2018 19:46

Probleem hier is wel dat als ze een fail-over hadden gedaan ze tegen precies hetzelfde probleem aanliepen. Het back-up systeem van Utrecht heeft waarschijnlijk dezelfde software met ook diezelfde bug er in. Uiteindelijk hebben ze alles wel kunnen laten draaien door handmatig de seinen en wissels te bedienen, misschien wat langzamer maar ook een oplossing.

TheekAzzaBreek @gekkeh3nk • 22 augustus 2018 20:01

Dat is maar de vraag. Op z'n minst zou precies dezelfde handmatige correctie moeten worden ingevoerd.

Handmatig werken is niet een beetje langzamer. Er kon een enkele trein naar Amsterdam: de ICE en een intercity. Stations in een ruime cirkel rond Amsterdam bleven onbereikbaar, tot Almere aan toe. Geloof me: ik heb het vijf uur lang op de voet gevolgd.

OT: Wat dan wel weer leuk is: als het echt goed misgaat maken we er altijd weer een gezellig feestje van

tonkie_67 @TheekAzzaBreek • 22 augustus 2018 21:16

Ik neem aan dat in principe fail over systemen van dezelfde data uitgaan.
Zeker als het een manual edit is waar een trein staat/is die niet live uit sensoren komt... als die data niet gesynct zou worden zou direct na een failover de 'nieuwe' software uitgaan van verkeerde positie info.
Dus nog steeds goed mogelijk om na edn perfecte failover ook bug in 2e systeem te zien.
Zou mogelijk wel eenvoudiver moeten zijn om een re-init te doen. Maar als je (nog) niet weet waarom syzteem crashte is dat wellicht niet direct een optie

Verwijderd @gekkeh3nk • 22 augustus 2018 23:01

Opstarten van de fail-over kost 4 uur, niet bepaald bedoeld voor dit soort kleinigheidjes.

M.M @Verwijderd • 23 augustus 2018 10:56

4 uur? Dat is geen fail-over meer maar disaster recovery..

Verwijderd @M.M • 23 augustus 2018 11:42

Klopt, over het algemeen geldt dat het alleen word ingezet bij zeer langdurige verstoringen, niet dit soort kleinigheden.

ewoutw @gekkeh3nk • 23 augustus 2018 13:46

DMV wordt alleen in Amsterdam (amstedam zuid en Schiphol) gebruikt. Dit kan dus ook alleen daar fout gaan.

Verwijderd @TheekAzzaBreek • 22 augustus 2018 23:02

Fail-over werkt wel maar er is bewust gekozen deze niet te gebruiken.

Glashelder

@TheekAzzaBreek • 23 augustus 2018 06:49

Dat een combinatie van omstandigheden die je vooraf niet hebt weten te verzinnen en dus niet getest hebt, tegen een onbekende bug oploopt is nooit uit te sluiten.

Detail, maar dit was geen onbekende bug. ProRail vond het onbelangrijk en gaf andere zaken hogere prioriteiten.

William_H @Glashelder • 23 augustus 2018 19:20

Waar basseer je, vooralsnog, deze aanname op. Heb je bronnen die dit kunnen onderbouwen?

Glashelder

@William_H • 23 augustus 2018 19:59

Inside knowledge

William_H @Glashelder • 23 augustus 2018 20:26

Ik vind dit persoonlijk een beetje makkelijk, maar misschien is dit rede genoeg om deze informatie door te geven aan Tweakers!? Dat zou een heel ander licht op de situatie kunnen schijnen, en misschien wel tot cultuurverandering.
Mocht je dit niet persoonlijk met naam en toenaam willen doen dan moet je weten dat Tweakers meedoet aan PubLeaks, en je op deze manier anoniem dit soort gegevens kunt delen.

Hilus 22 augustus 2018 19:09

Vast heel voor de hand liggend, maar waarom 32.768 en niet 65.535 (als in: 2¹⁶)?

P1nGu1n

@Hilus • 22 augustus 2018 19:12

Het gaat om een signed 16-bit integer, waarbij de eerste bit een signing bit is. De signing bit geeft aan of de waarde positief of negatief is. Hierdoor blijven er nog maar 15 bits over voor de absolute waarde.

Een signed 16-bit integer kan van -32.768 (-1x2¹⁵) tot 32.767 (2¹⁵-1).
Een unsigned 16-bit integer van 0 tot 65.535 (2¹⁶-1)

Wat er hier gebeurd is:
De teller van treinen liep maar op tot de max (van 32.767) bereikt werd, binair gerepresenteerd als:
01111111 11111111: de sign bit is 0 (want positief), de overige bits zijn 1

Bij de volgende trein die het systeem dacht te detecteren, werd hier 1 bij opgeteld. Dit had niet gemogen omdat er geen ruimte meer voor was, hier dient op gecontroleerd te worden.

01111111 11111111 (32.767) + 00000000 00000001 (1) = 10000000 00000000 (-32.768, indien signed)

Om dat de absolute bits van de integer 'vol' zaten, is de signing bit gebruikt. Dit heet een integer overflow: de absolute bits overflowden in de signing bit. Het systeem kon niet omgaan met een negatief aantal treinen en crashte blijkbaar.

[Reactie gewijzigd door P1nGu1n op 22 juli 2024 22:52]

GekkePrutser @P1nGu1n • 22 augustus 2018 23:25

Ach, al hadden ze meer bits of unsigned integers gebruikt, feit is dat daar geen 32768 treinen per dag aankomen. Dus er zat sowieso iets goed fout in de software en als hij tot 65536 had moeten tellen dan was het ook gecrasht maar had het net wat langer geduurd. Zelfs als het niet gecrasht was door de negatieve waarde te voorkomen dan nog heb je een belangrijk systeem met rare incorrecte waardes er in die elders in het systeem problemen kunnen veroorzaken.

De echte oorzaak is het incorrect detecteren van zo enorm veel treinen. Een probleem met de detectiesensoren en sanitering van de input.

Of met andere woorden: Wat de daadwerkelijke crash heeft veroorzaakt (de overflow) is niet zo heel relevant, de kern van het probleem is dat een waarde in het systeem die de werkelijke situatie moet weergeven (het aantal treinen) hier totaal niet mee klopte. Als je alleen die integer unsigned maakt dan los je de crash (symptoom) misschien wel op maar de oorzaak niet. Dat is juist slordig programmeren.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 22:52]

ewoutw @GekkePrutser • 23 augustus 2018 13:45

Klopt dat de trein eigenlijk maar 1 keer gedetecteerd had moeten worden. Maar toch kan je ook van slecht code spreken. DMV wordt alleen in Amsterdam toegepast (Amsterdam Zuid & en Schiphol). Een fout in DMV had de andere systemen van post21 mogen raken. Maar helaas viel vrijwel alle systemen uit inc. PRL waardoor treinsturing onmogelijk werd.

zoek34 @ewoutw • 24 augustus 2018 10:29

Tot zover ik weet Amsterdam Zuid niet meer sinds de aanleg van 4 sporen tussen de aansluiting ten westen van Amsterdam Zuid en Duivendrecht.

Goed voorbeeld hierin is o.a. een trein vanaf Schiphol spoor 1 naar Amsterdam Zuid, die kan alleen nog maar naar spoor 1 op Amsterdam Zuid.

ewoutw @zoek34 • 24 augustus 2018 14:32

Oh dat zal zomaar kunnen. Ik heb geen idee hoe de treinloop dat terplaatse is. Maar hoe dan ook, dit stukje software wordt maar heel weinig gebruikt. Alleen VL-post Amsterdam loop risici hierdoor plat te gaan. Wat trouwens gewoon niet goed is.

Zalmanman

@P1nGu1n • 22 augustus 2018 19:44

Zou je misschien ook een verklaring weten voor waarom de DMV überhaupt negatief wil kunnen tellen? Een unsigned int zou mij logischer lijken namelijk. Er zullen vast geen -n treinen toegewezen worden ergens, toch?

Enai @Zalmanman • 22 augustus 2018 20:41

Neen, maar ook geen dertigduizend treinen. Wellicht was 32K zo ver buiten de normale range dat het niet uitmaakte wat voor type integer gebruikt werd.

Zarhrezz

@Enai • 22 augustus 2018 23:52

Ik vermoed dat het systeem ook op z'n toeter was gegaan bij een ander type int (of gewoon een int, in talen als Python die al die 'oude types' int niet hebben). Dat het systeem 32K keer iets probeert toe te wijzen, duidt op een endless loop. In dit geval is de loop doorbroken doordat er een int uit z'n range loopt, maar het echte probleem is de loop. Zonder crash op overflow was het systeem waarschijnlijk unresponsive gegaan en had iemand handmatig moeten rebooten.

ewoutw @Enai • 24 augustus 2018 14:35

Hier kan je sommetje op los laten.
Trienen moeten (planmatig) 3 minuten uit elkaar liggen. Dat is dus maximaal 20 treinen per uur per spoor.
2 sporen.
24 uur in een dag
20 * 2 * 24 = 960 treinen op een dag. Dus die teller kan dus een maand mee.

Zezura @Zalmanman • 22 augustus 2018 20:00

Je gebruikt ooit signed int om een aparte waarde aan te geven. Als bijvoorbeeld een opdracht mislukt dat je -1 kan aangeven i.p.v. een positief getal. Echter zou ProRail robuust moeten programmeren waarbij er dus veel checks en ook runtime checks Voor fouten en deze afhandelen. Dit zijn systemen waarbij fouten dodelijk kunnen aflopen.En vind ik dat er een systeem moet worden ontworpen die fouten kan detecteren kan melden, en kan afhandelen op een manier waardoor er weinig mis zou moeten kunnen gaan. Wie weet hebben ze dit al geïmplementeerd.

Microsoft heeft boeken over veilig programmeren. Ik dacht dat de boeken secure coding heten.

[Reactie gewijzigd door Zezura op 22 juli 2024 22:52]

P_Tingen @Zezura • 23 augustus 2018 09:14

Klinkt best aannemelijk, maar als je zelf programmeert, dan weet je dat je domweg niet op ALLES kan controleren. Er zullen ongetwijfeld checks in de systemen van ProRail zitten, maar bij een combinatie van factoren wordt het aantal mogelijke situaties al snel exponentieel groot en dat wordt een stuk lastiger af te handelen.

Mijn gok is dat de systemen van ProRail niet gemaakt zijn met de meest nieuwe fancy talen waarin allerlei beveiligingen hard zijn ingebouwd, maar dat het oude systemen zijn, gemaakt in een recht-toe, recht-aan ontwikkelomgeving.

In defense voor ProRail: ons spoornetwerk behoort tot de wereldtop als het aankomt op bezetting, dus ze zullen hun zaken relatief goed voor elkaar moeten hebben.

Zezura @P_Tingen • 23 augustus 2018 09:18

Klopt maar ik denk wel dat ze toegang hebben tot sockets, en zon beetje elke taal heeft asserts. Zoniet dan kan je zelf assert maken.

wvalk @Zezura • 22 augustus 2018 20:35

ipv deze bash mag er wel even hulde naar de programmeur die dus vannacht even heeft door gewerkt om deze bug te fixen! Welkom in de IT wereld waar fouten gemaakt worden.

/offtopic:
Er zit een bug op je portfolio pagina

.
Wellicht is https://www.freecodecamp.org/ iets voor je?

Zezura @wvalk • 23 augustus 2018 02:23

Sorry, maar wat moet ik hier op reageren.

Ten eerste het is geen bash, als je goed had gelezen dan had je gezien dat ik benoem dat ProRail dit mogenlijk al heeft, dat heb ik geschreven omdat ik niet bij ProRail werk. Daarbij geef ik alleen maar aan dat zo’n soort toevoeging in mijn ogen een welkome toevoeging is.

En serieus, bugs gaan zoeken op mijn portfolio site is gewoon laag, tweakers is een plek waar professionals met elkaar discussiëren, als je dat niet kan moet je het niet doen.

Tevens is mijn portfolio hooguit een aangepast template omdat ik het druk heb. Ik hoop dat je het leuk vond om je tijd te verspillen.

Tozz @Zezura • 23 augustus 2018 11:26

Het punt is denk ik het gezever op ProRail omdat er een bug in hun software zit en dat dat niet het geval zou moeten zijn. In elk software pakket zitten bugs, dat is niets nieuws en zal ook altijd zo blijven.

De reacties hier over wel of geen signed int, een int, float of dat het een symptoom is of niet is niet zo relevant. Er zat een bug in, kan gebeuren. Is gefixed, over tot de orde van de dag.

Zezura @Tozz • 23 augustus 2018 11:55

Ja kan ik wel begrijpen.

tweaknico @Zezura • 24 augustus 2018 12:07

Microsoft heeft boeken vol over veilig progameren... echter ze houden zich er zelf ook niet echt aan, zoek voor de grap eens op "Defence in Depth" "The Microsoft Way" Stefan Kanthak: https://duckduckgo.com/?q...rosoft+Way+Stefan+Kanthak
Er zijn al >50 van dergelijke artikelen, naast een specifieke serie over installers.
Ze hebben de afgelopen maanden nog een vc-runtime geleverd met tooling waarvan al jaren bekend is dat die problematisch is.

pegagus @Zalmanman • 22 augustus 2018 19:49

Dat wil het systeem niet. Alleen was er niet voorzien in deze mogelijkheid.

.oisyn Moderator Devschuur®

Bugs

@P1nGu1n • 22 augustus 2018 19:20

Overigens gebruikt zo'n beetje elke moderne processor two's complement en niet sign-and-magnitude (dat verandert de betekenis van de sign bit niet, maar wel hoe de overige bits geïnterpreteerd dienen te worden). Het resultaat hiervan is dat mogelijke waardes lopen van -32.768 t/m 32.767. Bij de 32.768e wijziging valt hij dus terug naar -32.768

[Reactie gewijzigd door .oisyn op 22 juli 2024 22:52]

Hilus @P1nGu1n • 22 augustus 2018 19:14

Helder, dank!

Neko Koneko 22 augustus 2018 18:43

Hebben ze die winkeldief te pakken gekregen? Indien ja laten opdraaien voor de schade, allemaal zijn schuld

TerraGuy @Neko Koneko • 22 augustus 2018 18:58

Inderdaad miljoenen aan schadevergoeding laten betalen om alle onkosten die het geintje heeft gekost terug te betalen. En 5000 euro teruggeven voor het meehelpen met het vinden van een kritische bug.

Maar zonder gekheid, zelfs zonder die bug heeft hij al voor heel wat vertraging gezorgd, wordt zoiets ook meegenomen in de aanklacht/geëiste schadevergoeding?

Odious Trident @TerraGuy • 23 augustus 2018 08:24

Ik denk het niet. Een strafrechter kan een schadevergoeding toewijzen als deze niet te complex van aard is en direct verband houdt met het misdrijf/overtreding. Die winkeldief zich in casu niet alleen schuldig gemaakt aan winkeldiefstal maar ook aan het overtreden van art.3 spoorwegwet: Het is een ieder verboden zich zodanig te gedragen dat gevaar op de spoorweg wordt veroorzaakt of kan worden veroorzaakt of dat het verkeer op de spoorweg wordt gehinderd of kan worden gehinderd. Hij kan er nog een straf van die overtreding bovenop krijgen (is 3 maanden hechtenis of een geldboete van de tweede categorie=€3900). Hier gaan echter (wat iemand hieronder aangeeft) vragen over causaliteit en zo (en dan met name de vraag van toerekening naar redelijkheid) een rol spelen, en dan wordt het meenemen van een schadevergoeding al heel gauw te complex van aard om in het strafproces nog mee te nemen. Vreemd trouwens dat art. 3 als overtreding wordt gezien en niet als misdrijf.

[Reactie gewijzigd door Odious Trident op 22 juli 2024 22:52]

Zen1581 @TerraGuy • 22 augustus 2018 19:31

Ga er maar niet van uit. Alle schadevergoeding etc. gaat via het civiele recht en niet via het strafrecht, waar winkeldiefstal wel onder valt. Slachtoffers kunnen wel schadevergoeding eisen bij de strafrechter, maar hierbij moet je eerder denken aan slachtoffers bij een verkeersongeluk dan grote organisaties als ProRail.

De officier van justitie kan het wel meenemen in de strafeis en de rechter uiteindelijk in de straftoemeting, maar de kans dat in ieder geval dat laatste gebeurd acht ik niet erg groot. (Daarnaast is de oorzaak voor de storing imho niet de winkeldief, maar de bug in het systeem, maar dat is een andere discussie)

Denk niet dat de winkeldief een hele zware straf gaat krijgen.

[Reactie gewijzigd door Zen1581 op 22 juli 2024 22:52]

Verwijderd @Zen1581 • 23 augustus 2018 11:54

Ho ho, de wet maakt geen onderscheid als het gaat om het claimen van schade als gevolg van een dere, het is wel zo dat slachtoffers van bijvoorbeeld een verkeersongeluk meer rechten hebben waardoor het gemakkelijker is om hun schade te claimen.

Ns, niet prorail, die hebben weinig schade, kan perfect naar de rechter en daar een schadevergoeding eisen, zeer grote kans dat die wordt toegewezen.

Echter is de gang naar de rechter inclusief advocaten meestal duurder dan de opbrengst.

segil @Neko Koneko • 22 augustus 2018 21:45

Nee natuurlijk niet. Ik zie het al voor me bij de rechter:
"beste dief, je bent schuldig bevonden aan al deze kosten, want je had best kunnen weten van te voren dat als je die tunnel inrent, een trein precies op dat punt komt stil te staan, vervolgens een medewerker een bepaalde handmatige actie uitvoert, waarna een software bug een crash veroorzaakt en de back-up ook niet meer werkt. Sukkel."

En hoe ver loopt die schuld dan door? Stel dat een Schiphol medewerker door deze vertraging te laat op werk komt, erg gehaast is, een fout maakt bij het controleren van een onderdeel aan het vliegtuig, en het vliegtuig stort neer... zeker ook de schuld van deze winkeldief?

ajolla @segil • 23 augustus 2018 02:13

Ja, want gevolgschade. Voorzienbaar of niet, maakt niet uit.

iAdema @Neko Koneko • 22 augustus 2018 18:44

Die is inderdaad aangehouden

friend @Neko Koneko • 22 augustus 2018 18:47

'allemaal'? Een ex-software developer, die ook verantwoordelijk was voor de software bug?

stefanass @kuurtjes • 22 augustus 2018 19:56

Want voordat scrum in gebruik raakte waren er geen bugs?

Yalopa @stefanass • 22 augustus 2018 21:41

Natuurlijk niet, er waren ook geen opleveringen

Rhys08 22 augustus 2018 18:57

Lees ik het nu goed dat er eerst een menselijke handeling plaatsvond waardoor waarna de software crashte?

Ben benieuwd wat er was gebeurd als de ProRail medewerker geen handmatige input had gegeven.

[Reactie gewijzigd door Rhys08 op 22 juli 2024 22:52]

mflameling @Rhys08 • 22 augustus 2018 22:05

Dan was een winkeldief platgereden door een trein. Beetje extreme straf voor een dief. De ProRail medewerker heeft correct gehandeld door handmatig een trein te laten stoppen omdat er een mens op het spoor was.
Dat de trein net op een ongelukkig punt stil komt te staan waardoor een fout in het systeem denkt dat er treinen aan blijven komen is minder fijn. Jammer dat er geen handmatige override is die deze check uit kan zetten zolang de seinen op rood staan.

jpsch @Rhys08 • 22 augustus 2018 20:44

Waarschijnlijk niets. Moet je je afvragen of je wel handmatige mutaties op een productiesysteem wilt toestaan.

Neko Koneko @jpsch • 22 augustus 2018 21:00

Waarschijnlijk niets. Moet je je afvragen of je wel handmatige mutaties op een productiesysteem wilt toestaan.

Op zich moet dat mogelijk kunnen zijn, zolang je er maar voor zorgt dat de software daar vervolgens mee om kan gaan (wat in dit geval duidelijk dus niet zo was). Soms is het gewoon nodig om bij uitzonderingen handmatig iets te wijzigen.

necessaryevil @Neko Koneko • 22 augustus 2018 21:19

Het ligt er natuurlijk ook aan wat je verstaat onder een handmatige wijziging. Daarnaast zijn handmatige wijzigingen in productiesystemen welleens nodig, in dit geval om te voorkomen dat er een persoon verongelukt.

Een handmatige spoorwijziging lijkt me verder in alle gevallen nou juist iets wat standaard aanwezig moet zijn.

Verder ben ik het met je eens dat menselijk ingrijpen ook juist problemen kan veroorzaken, (niet in dit geval vind ik), je kan het een en ander ook afvangen met sleutels en logboekadministratie.

jpsch @Neko Koneko • 22 augustus 2018 21:12

Handmatig als in rechtstreeks quick en dirty muteren van de database. Ken de details van deze case natuurlijk niet.

ajolla @jpsch • 23 augustus 2018 02:14

Wil je ingrijpen onmogelijk maken?

kuurtjes 22 augustus 2018 19:09

Technische info over wat er juist gebeurd is $_/-\o_$

well0549 22 augustus 2018 23:40

Waarschijnlijk hebben ze het opgelost door er een int32 van te maken

Blokker_1999

Cartech
Bugs
Trein
Nederland

22 augustus 2018 18:45

Niets zo goed als treinen op vaste perrons. Duidelijk voor de reiziger en geen beheersoftware nodig. Vereist natuurlijk wel redelijk stipte treinen.

KoffieAnanas @Blokker_1999 • 22 augustus 2018 18:48

Ik heb liever dat een trein vaker rijdt, dan dat een trein links of rechts op het perron staat.

Trouwens, de trein stopt op hetzelfde perron op Schiphol, alleen het spoor kan wisselen. Je loopt dus op het perron of naar links, of naar rechts.

[Reactie gewijzigd door KoffieAnanas op 22 juli 2024 22:52]

Wokschotel @Blokker_1999 • 22 augustus 2018 18:51

Heb je ook gelezen waarom op dit station die software er is?

Verwijderd @Blokker_1999 • 22 augustus 2018 18:47

Wil ik wel eens zien in België $_/-\o_$

Arator @Verwijderd • 22 augustus 2018 21:20

De meeste treinen komen bij ons toch aan op het voorziene perron, nu ja buiten Antwerpen-Centraal misschien. Daar zit je met zowat de steilste hellingen van België (op spoorwegdomein), en moet er soms al wel eens een trein boven ontvangen worden wegens te weinig tractie.

Bij ons is het zo dat elke nacht de perrons en sporen worden toegewezen. Dus bij normale toestand is dat gewoon copy-paste van de dag ervoor. Zijn er echter geplande werken, dan kunnen er reeds spoorwijzigingen gepland worden, en weet het systeem het dus ook. Deze planning houdt dus rekening op de infrastructuur maximaal te benutten.
Moet er in real-time een wijziging gebeuren, is het altijd een handmatige wijziging. Dan kiest het systeem de "kortste route naar bestemming" en is het aan de bediende op het seinhuis om de trein de juiste wissels toe te wijzen, wil men optimaal profiteren van de infrastructuur.

@Zen1581 Ik vermoed dat ProRail toch ook wel een klacht zal indienen. Of is spoorlopen in Nederland wel toegestaan? Sowieso vermoed ik dat ze hun kosten zullen proberen te verhalen op die winkeldief, de spoorwegondernemingen zullen wel facturen sturen naar ProRail.
Als ik moet tussenkomen (interventiedienst Infrabel), wordt er puur alleen voor mijn tussenkomst al een factuur opgemaakt door de bureaudiensten. Van zodra er een identiteit gekend is, worden die kosten gewoon opgestuurd, bij ongevallen naar de verzekering, bij moedwillige daden komt het gewoon bij de dader in de bus. Ik geloof dat ze voor een zondagnacht voor mij 248€ per uur vragen, zonder verplaatsingen. En ik kom dan alleen de vaststellingen doen, gegevens uitwisselen met politie, en eventueel het treinverkeer ter plekke een beetje regelen. Facturen van 10-20.000 euro bij een dodelijk ongeval zijn geen uitzondering (verdeeld over de spoorwegondernemingen en de infrastructuurbeheerder)

William_H @Arator • 23 augustus 2018 19:41

Hoe vaak ik op Luik en Leuven al niet spoorwijziging heb gehoord...
Valt mij op dat dat in Nederland, op Schiphol na idd, veel minder vaak gebeurt. Zeker op Utrecht Centraal. Maar daar hebben ze, net als laatst op Zwolle en binnenkort ook op Amsterdam Centraal, een flink aantal wissels weggehaald waardoor het aantal spoorveranderkeuzes per definitie beperkter is.

Arator @William_H • 24 augustus 2018 09:15

Ik ken vooral de situatie in Antwerpen en de Kempen. Daar valt het qua spoorwijzigingen nogal mee.
Ik heb, zal ondertussen al wel bijna 10 jaar geleden zijn, het seinhuis van Rotterdam eens bezocht. Het viel me daar op dat "de computer" daar veel meer automatisch de treinen liet rijden. Terwijl bij ons (België) toen nog elk beheerd sein moest gestuurd worden door iemand vanop een seinhuis. Dat maakt natuurlijk dat er bij ons veel meer aan micromanagement werd gedaan. Stond er een trein aan te schuiven om binnen te komen aan een perron, kon men sneller een ander spoor kiezen, aangezien men toch al met de sturing bezig was. Ik heb ooit eens contact gehad met Rotterdam om een trein op tegenspoor/ verkeerd spoor naar hun te sturen over de HSL. Wat een poespas er toen verkocht werd om het toch maar niet te doen, terwijl dit bij ons de normaalste zaak van de wereld is om tragere treinen in te halen via tegenspoor (wanneer het verkeer het toelaat natuurlijk).
Ik denk dus dat het met versporingen ook zo zal wezen, als je niet gewend bent om effectief in te grijpen in de sturingen van de seinen, laat je ook langer het systeem naar oplossingen zoeken. Ben je echter gewend om hands-on de sturingen te doen, zal je ook sneller geneigd zijn om je volledige capaciteit van je station te benutten.
Waar ik van spreek, gaat dan wel over systemen van enkele jaren terug. Ondertussen zijn wij ook overgestapt op een systeem waarbij "de computer" meer handelingen uitvoert, en moeten de seinen ook eerder manueel gesloten worden gehouden ipv geopend te worden. Door dit systeem is het voor sommige spoorconfiguraties moeilijker geworden om te versporen, voor andere spoorconfiguraties is het echter maar een streepje verplaatsen met de muis.

William_H @Arator • 27 augustus 2018 01:18

Ah, dit vindt ik een hele interessante uitleg. Zo zie je maar dat geautomatiseerd niet altijd beter maakt, als in flexibeler.

jpsch @Blokker_1999 • 22 augustus 2018 21:15

Perron is het eindresultaat, denk dat je alsnog beheerssoftware nodig hebt voor de sporen en wissels. Zijn meerdere mogelijkheden om van A perron x naar B perron y te komen.

mongkut 22 augustus 2018 20:48

Welke tweaker heeft hier nu of in de toekomst wat aan deze info?
We zijn aan de "goden"overgeleverd bij deze grote bedrijven.

jpsch @mongkut • 22 augustus 2018 21:19

De tweaker die met een voorbeeld duidelijk wil maken, dat je niet alles kunt testen en een incident grote gevolgen kan hebben?

Weet je nog, die vent in de tunnel van Schiphol?

dennisfr @mongkut • 22 augustus 2018 21:43

Omdat dat dit een IT gerelateerde oorzaak had die ook nog een praktisch verklaard is (integer overflow).
Dit soort loops implementeer ik (noodgedwongen) ook wel eens en je probeert altijd alles af te vangen, maar ik zal niet zeggen dat dit mij nooit had kunnen overkomen. Gelukkig valt er in mijn geval dan een machine stil en niet in compleet OV systeem.

xmenno 23 augustus 2018 10:49

ProRail komt er weer makkelijk vanaf "Door een unieke samenloop van omstandigheden ontstond een fout in de software."
Volgens mij heeft die fout er altijd al in gezeten. Als ze het binnen een paar uur in de code op kunnen lossen dan was het blijkbaar niet zo heel ingewikkeld. Misschien hebben ze niet goed getest, of bij het maken van de software hier geen rekening mee gehouden.
Het is altijd een samenloop van omstandigheden waardoor een vliegtuig crashed, de trein het niet meer doet, etc... maar je kunt wel je best doen om dit te voorkomen. Ik heb nu het idee dat dit morgen weer in een ander stukje code van ProRail voor kan komen en wij als test gebruikers weer de pineut zijn.

ewoutw @xmenno • 23 augustus 2018 15:33

Dit vraag ik mij dus erg af. Software wordt al jaren gebruikt zonder 1 probleem. En nu kunnen ze het verbeteren en testen binnen 24uur.

En als oud-prorailer weet ik hoe streng prorail is (behalve als er treinen stil staan)

William_H @ewoutw • 23 augustus 2018 19:51

...
En als oud-prorailer weet ik hoe streng prorail is (behalve als er treinen stil staan)

Welk deel van deze zin is er nu sarcastisch bedoeld?

Op dit item kan niet meer gereageerd worden.

Systeem dat perron toewijst aan treinen veroorzaakte storing Schiphol

Lees meer

Reacties (96)

Sorteer op:

Weergave: