Nou kun je je natuurlijk afvragen of één dodelijk slachtoffer nu miljarden aan investeringen moet uitlokken.
Een dilemma voor Nederland is natuurlijk dat wie met het systeem begint ook met de kinderziekten te maken krijgt.
Maar ja, als iedereen in Europa op elkaar gaat zitten wachten, gebeurt er niets en juist Nederland heeft belang bij integratie van dat soort transporttechniek.
Een dilemma voor Nederland is natuurlijk dat wie met het systeem begint ook met de kinderziekten te maken krijgt. Maar ja, als iedereen in Europa op elkaar gaat zitten wachten, gebeurt er niets en juist Nederland heeft belang bij integratie van dat soort transporttechniek.
We zijn niet de eersten, zoals elders al aangegeven, maar zelfs dat is geen garantie. Bovendien zolang er nog geintjes zijn als incompatible software versies ed moet je het gewoon niet op het hoofdrailnet willen draaien, tenzij het naast het huidige systeem kan er er dus een goed backup-scenario is.Trouwens : http://mirt2012.mirtprojectenboek.nl/Images/587xx_tcm322-307304.pdfHet zou fijn zijn als Den Haag de uitkomsten van zo'n pilot zou afwachten. Die laat dan zien :- Of en hoe ATB en ERTMS samengaan (handig als fallback tijdens de implementatie, haalt de druk een beetje weg bij diverse vervoerders)
- Of het systeem nu wel stabiel te krijgen is (je leest overal nog dat ERTMS de nodige kinderziekten bevat)
- Wat zo'n beetje de te verwachte kosten en doorlooptijd voor aanpassen rollend materieel zijn
Klopt, maar met 1 systeem voor heel europa kun je die wissel doen als hij daadwerkelijk aan zijn rijtijd zit, niet wanneer hij toevallig halverwege zijn dienst de verkeerde stippellijn op de landkaart passeert....
Ander voordeel: Als je 1 systeem hebt met 1 duidelijke keuring dan kun je die overal in europa laten doen en weet je dat wanneer die loc jouw land in komt dat het ding goed beveiligd is. Het zal nog lang duren voordat dit werkelijkheid is, maar het lijkt erop dat in ieder geval nederland gaat stoppen met navelstaren... (nu de werkelijke invulling nog afwachten natuurlijk)
Zelfs de programeertaal verschilt onderling hier en daar.
De programmeertaal maakt geen donder uit. Het protocol (zoals HTTP, POP3, IMAP en SMTP protocollen zijn die je gebruikt voor web-pagina's en e-mail) maakt al heel wat meer uit. Maar ik weet te weinig van ETCS om te zeggen of er zo'n dergelijk protocol bestaat, of het deugdelijk in elkaar steekt en in hoeverre het correct is geïmplementeerd door de diverse fabrikanten.
Als een machinist zoiets in z'n dienst aantreft, zal hij vooraf aangeven dat hij die dienst niet kan draaien. Machinistendiensten worden over het algemeen zo gemaakt dat het personeel deze ook kan rijden. Dus zomaar halverwege een dienst ontdekken dat je de grens overgaat en niet verder mag is uitgesloten. Verder zijn er vele Nederlandse machinisten die in de goederendienst op Duitsland rijden, hebben diensten waarin ze de hele rit naar de eindbestemming rijden en de volgende ochtend na een hotelovernachting weer terug. ERTMS/ECTS zal daar niets aan veranderen. Gewoon een kwestie van de diensten goed in elkaar zetten. Voor langere ritten zal personeelswissel altijd nodig blijven, omdat de prioriteit "doorrijden" groter is dan "met één machinist de trein naar de eindbestemming brengen". Bij "met één machinist doorrijden" zal de stop namelijk de lengte hebben van een overnachting, terwijl een personeelswissel de lengte heeft van 5 tot 10 minuten. Wat zal nou effeciënter zijn?
Keuringen kun je nu ook al buiten Nederland laten doen en locs die nu de grens overkomen en in Nederland rijden, hebben hier al een toelating (dat zal niet anders worden). Dus ook nu voldoen deze locs aan de veiligheidseisen. Ik ben benieuwd wat ERTMS/ECTS daar aan gaat verbeteren of veranderen.
Denken we hier nou werkelijk dat we het beter weten dan de vaklui die er al jaren mee bezig zijn?
Is er iemand die de specs en de andere documentatie grondig gelezen en begrepen heeft?
Dat is nou juist de gedachte achter ERTMS. Alleen de specificaties worden vooraf vastgelegd. Als er zus-en-zo signaal staat, dan moet de trein zo-en-zus reageren. Dat de ene leverancier dan de implementatie op een andere manier, met andere kastjes, programmeertaal, andere hardware en andere software oplost is prima, zolang maar aan die vooraf gestelde specs wordt voldaan.
Print
