(On)geleerde lessen spoorwegbeveiliging
dossier Ertms

(On)geleerde lessen spoorwegbeveiliging

door Lieuwe Zigterman in rubriek artikel, spoor
2 reacties

Voor wie afscheid neemt van het actieve werkleven, is een terugblik op zijn plaats. Lieuwe Zigterman, expert spoorwegbeveiliging, deelt graag enkele lessen die hij heeft geleerd. Ook enkele ongeleerde lessen laat hij niet onbesproken.

Wat betreft keuzes die gemaakt moeten worden rondom de spanning, laten besluitvormers zich vaak niet overtuigen door een puur technische onderbouwing, zoals energieverlies in de vorm van warmte in de bovenleiding. Ook problemen met elektromagnetische beïnvloeding leven niet in de wereld der besluitvormers. Een bedrijfseconomische onderbouwing maakt al wat meer kans, maar de spoorwegwereld wordt niet zuiver bedrijfsmatig gestuurd. Tenslotte is een MKBA (Maatschappelijke Kosten Baten Analyse) ook niet op voorhand voldoende voor het maken van – politieke – keuzes. Dit hangt weer samen met de grote verzameling van aannames die nodig is voor een MKBA, voor het in geld vertalen van bijvoorbeeld milieuaspecten.

Spanningssysteem
Daarnaast is de crux: de migratie van het bestaande systeem, dat is uitgerold over duizenden kilometers spoor en is ingebouwd in honderden voertuigen. De wijziging van een spanningssysteem is een hevige ingreep en zal daarom vele jaren, zo niet decennia vergen. Als je zo’n ingreep doet, moet je daarom ook meteen voor ‘het beste systeem’ kiezen. Technisch gezien is dat een, niet in Europa voorhanden zijnd, systeem van een hoge gelijkspanning. Daarmee kun je namelijk de stromen flink verkleinen, zonder EMC-problemen te introduceren, zoals bij 25 kV~. Wanneer gekozen moet worden uit systemen die in Europa voorhanden zijn, is 25kV~ de beste keuze. Een betere keuze dan 3kV=, omdat het eindresultaat voor dit wisselspanningssysteem beduidend beter is dan van het nog steeds relatief lage gelijkspanningssysteem, terwijl de migratie niet wezenlijk eenvoudiger is.

Maar het antwoord op de vraag hoe je in een politieke wereld met een horizon van amper 4 jaar met een zo ingrijpend besluit om moet gaan, heb ik niet kunnen vinden. Wellicht kan de klimaatproblematiek, waar de tijdshorizon zich ook over decennia, zo niet vele generaties uitstrekt, hierbij een positieve rol spelen. Mijn advies: zet in op de voordelen voor het klimaat, zodat je bij dit actuele en dringende probleem aansluit.

ERTMS / ETCS
De problematiek om tot een Europese standaard te komen op het gebied van de treinbeveiliging, leert dat dit een lange en zeer complexe weg is. Ik vat het resultaat vaak samen als het product dat wordt gekenmerkt door de ‘werkgroep’ die het tot stand heeft gebracht: elk lid wil iets van zijn gading terugzien in het eindresultaat.

Concreet betekent dit bijvoorbeeld dat de Deutsche Bahn nagaat of zij de functionaliteit van het ooit door hen bedachte systeem LZB (Linien Zugbeeinflussung) na kunnen bouwen in ETCS. Zo doet de SNCF dit ook met hun TVM (Transmission Voie-Machine), bovendien rekeninghoudend met het vermijden van de beperkingen van dit systeem. Daarnaast is er een partij die graag een lus (EUROLOOP) wil voor het zogeheten ‘in-fill’-probleem van ETCS Level 1, waar een andere partij hiervoor radio (gsm) wil benutten. In de tussentijd hebben de Italianen een eigen nieuw systeem (SCMT) gebouwd, dat heel erg op ETCS lijkt, maar het net niet is. Met de ontwikkeling van dit SCMT kon de eigen industrie alvast ervaring opbouwen met de voor ETCS benodigde technologie.

De enige weg hieruit is, het zoeken naar de kleinste gemene deler in plaats van het opbouwen van het grootste (en daarmee complexe) gemene veelvoud.

Ook hier is het de vraag hoe je dit in een Europese constellatie met 28 (of binnenkort 27?) lidstaten plus als belangrijke gangmaker Zwitserland voor elkaar krijgt. Om een compact resultaat te krijgen, moet je juist met een kleine groep specialisten werken. Dit vereist een andere aanpak vanuit ‘Europa’, die niet zo eenvoudig tot stand kan worden gebracht.

Het product
Beveiligingsprojecten willen nogal eens grote organisaties worden, voorzien van vele secundaire functies als kwaliteitsmanager, configuratiemanager, veiligheidsmanager, omgevingsmanager en risicomanager. Hoe belangrijk dergelijke ondersteunende functies ook mogen zijn, het gaat uiteindelijk om het te leveren product. En dat lijkt soms uit het oog te worden verloren.

Evenzo is het veiligheidsdossier (of in het jargon safety case) een middel dat nooit een doel mag zijn of worden. Het gaat immers om het uiteindelijke resultaat. Stel de functionaliteit van het te leveren product dan ook centraal in het project.

Koppelvlakken
We spreken vaak over ‘interfaces’, maar koppelvlakken vind ik een mooier Nederlands woord hiervoor. De alternatieve Nederlandse term ‘scheidsvlak’ benadrukt te veel de scheiding, terwijl het juist om de positieve boodschap van “aan elkaar knopen”, oftewel het koppelen van twee systemen gaat.

Mijn stelling: twee gekoppelde systemen werken net zo goed (of slecht) samen, als de personen die verantwoordelijk zijn voor de betreffende systemen hebben samengewerkt bij het tot stand brengen van deze koppeling. Bij het koppelen van systemen, behoeft deze samenwerkingscomponent daarom gerichte focus.

In het verlengde hiervan ligt het samenwerken op (lands)grenzen. Een belangrijke, misschien wel de belangrijkste, aanbeveling die wij hebben gedaan in een studie voor een Europese goederencorridor was: begin met het realiseren van ERTMS op de grensovergangen. Als op de grensovergang het systeem goed werkt, is het aan elke zijde vervolgens in één hand van de betreffende, nationale infrabeheerder om in zijn verantwoordelijkheidsgebied het systeem goed te laten werken. En per land ligt die verantwoordelijkheid eenduidig vast.

BB21: goede ideeën keren terug
Begin jaren 90 hebben wij met een team van vijf personen het concept BB21 ontwikkeld, dat staat voor: Beveiligings- en Beheersingssystemen voor (vóór) de 21e eeuw. De naamgeving sloot aan op: Rail21, Machinist21, Station21 en nog zo wat 21-projecten. Als ondertitel voerden wij: mogelijkheden voor capaciteitsverruiming.

Een integraal onderdeel vormde de verbeterde regeling van de treinbesturing met een Rij-Automaat in de Trein. Dat idee is destijds op de plank blijven liggen, omdat het project BB21 zich in de verdere uitwerking beperkte tot het beveiligingsdeel – en dan alleen de implementatie van ETCS. Momenteel komt ATO (Automatic Train Operation) weer in beeld, onder andere in relatie tot het automatisch rijden. Let wel, ATO kan ook voor een machinist uitstekende ondersteuning bieden.

De lessen die hieruit vallen te leren luiden: wanhoop niet bij het niet 1-2-3 implementeren van jouw briljante idee, want: goede ideeën keren om de zo veel tijd terug. Anders gezegd: resultaten hoeven niet meteen te worden geïncasseerd.

Symmetrische compatibiliteit
Het concept ETCS is van het begin af aan gebaseerd op de vrijheid van de infrabeheerder om keuzes te maken in ‘level’ en ook wat betreft systeemversie. Want, de ETCS-specificaties gaan er van uit dat het voertuig ‘alles’ kan: elk ‘level’ haalt en altijd met de nieuwste versie van de software. Dit leidt ertoe dat de vervoerder (de partij die – in tegenstelling tot de infrabeheerder – geacht wordt in een commerciële markt te opereren) steeds weer voor de kosten opdraait om elke software-update te implementeren.

Vanuit de gedachte van de infrabeheerder is dat een logische keuze. Maar, zoals duidelijk zal zijn uit voorgaande opmerkingen, voor de vervoerder uiterst onlogisch.

Kortom: reden om in de ETCS-kaders te pleiten voor symmetrische compatibiliteit. Dit deed DoorZigt B.V. in 2016 door middel van een poster-sessie tijdens de ERTMS-conferentie in Brussel. Het is inmiddels doorgedrongen in de ETCS-wereld dat deze vorm van compatibiliteit noodzakelijk is. Alleen is de nu gekozen wijze om dit concept vorm te geven op geen enkele wijze te vergelijken met hoe dit in de wereld van de mobiele telecommunicatie gestalte heeft gekregen.

De hieruit te leren les luidt: kijk niet eenzijdig vanuit infrastructuur, maar houd rekening met alle belangen. Het lijkt een open deur, maar is – zoals bovenstaande praktijk leert – geen gemeengoed in de wereld van de spoorwegbeveiliging.

2 reacties

  1. asierts
    13 september 2019 om 13:38- Reageren

    Het kernprobleen is dat Lieuwe nog uit de tijd en spoorcultuur van ‘technology push’ en eilandjesdenken komt. Die cultuur blokkeert effectieve klantgerichte innovatie, simpelweg omdat de vele eilandjes hun eigen belang doorzetten – zoals in bovenstaand en diverse andere schrijfselen van Lieuwe steeds weer valt te lezen. Wat in het spoorse domein ontbreekt, is integrale architectuur en een architect die het geheel adequaat overziet. Architectuur is de brug tussen gebruik, vernieuwing en techniek. Die coordinerende rol was vroeger niet nodig, want de ingenieur bepaalde gewoon wat er gebeurde. Maar zo werkt het dus niet meer anno nu. In de ICT heeft architectuur ook voor een effectievere beheersing gezorgd. ProRail is er ook al een tijdje mee bezig. Leestip: “werken onder architectuur”, uitg. Van Gorcum, 2010.

  2. asierts
    13 september 2019 om 13:58- Reageren

    Een mooi voorbeeld is het extreem-technische begrip ‘symmetrische compatibiliteit’. Dat zegt de meeste mensen niets. De klassieke ingenieur vindt dat “men” dat dus wel allemaal moeten leren snappen. Daarmee vervreemdt de klassieke ingenieur zich van zijn omgeving. Het werkelijke probleem in deze is dat het businessmodel niet klopt. Als upgrades nuttig zijn, dan moet de eindgebruiker daar niet teveel mee lastig gevallen worden – en al helemaal niet met torenhoge upgrade-kosten! Dat laatste is dus het echte probleem. ETCS-treinapparatuur is te vergelijken met een Slimme Meter in de meterkast. Die hoeven wij als eindgebruiker toch ook niet zelf te betalen en van dure upgrades te voorzien?!? Er is dus vantevoren niet goed over dit (eigendoms- en beheer-)aspect van ETCS nagedacht. Dat komt omdat er teveel vanuit de techniek is geredeneerd, en onvoldoende vanuit proces, gebruik en eindgebruiker. Met een adequaat architectuurmodel en ruime ICT-ervaring was dit nooit gebeurd.

Laat een reactie achter

Lees ook