Loopt de weg naar aantoonbare tunnelveiligheid via standaardisatie van ICT-processen?

De veiligheid van verkeerssystemen is voor een groot deel afhankelijk van ICT. Dat is zeker bij tunnels het geval. Maar wat als ICT-systemen falen? Wat betekent dat voor de veiligheid? Hoe kun je garanderen en aantonen dat falende ICT-systemen de veiligheid van de tunnelgebruiker niet bedreigen? En is een standaard ICT-proces daarbij de gedroomde oplossing?

Jørgen Heinrich (Movares) stelt dat de nieuwe Landelijke Tunnelstandaard (LTS) de eerste voorzichtige stappen zet richting een gestructureerd proces voor het creëren van veilig werkende software. Er worden echter nog geen standaard processen gevraagd voor het maken, verifiëren en in dienst stellen van software voor tunneltechnische installaties. Als het gaat om de inherente veiligheid van bijvoorbeeld een treinbeveiligingssysteem, draait het altijd om het aantonen van het veilig falen van de hardware en de software. Zeker in de huidige wereld waarin steeds meer software wordt gebruikt om beveiligingssystemen te bouwen, is het aantonen van de veilige en correcte werking van de software cruciaal. Vindt dit nu ook z’n weg naar tunnels? Jørgen Heinrich en Auke Sjoukema (ProRail) praten over nut en noodzaak van een standaard ICT-proces.

Is een standaard proces noodzakelijk om de goede werking van ICT-systemen aan te tonen?

Auke Sjoukema: “Bij ProRail zijn we erachter gekomen dat er ten aanzien van standaards en uniformiteit op het gebied van tunneltechnische installaties verbeteringen noodzakelijk zijn. Ten behoeve van adequaat beheer willen we documenten beter op orde hebben en ervoor zorgen dat tunnels op een uniforme manier bediend en beheerd  worden. Op dit moment kijken we vooral naar processen. De aantoonbaarheid van ICT-systemen is daar wel een onderdeel van, maar staat nu niet boven aan de agenda.”

Jørgen Heinrich: “In de LTS en het nieuwe Ontwerpvoorschrift Tunnels van ProRail worden voorzichtige stappen gezet om ook voor tunnels een gestructureerd proces te creëren. Er wordt gevraagd om een proces dat past binnen de IEC-61508 resp. NEN-EN 50126(de internationale functionele-veiligheidsnormen), of een equivalente oplossing. Dit dient te leiden tot een gestructureerde wijze van het maken, verifiëren en in dienst stellen van de tunnelinstallaties door de opdrachtnemer. Maar de eis betekent ook het nodige voor de opdrachtgever. deze zal namelijk veel strenger moeten toezien op het nakomen van de procesafspraken en het geleverd krijgen van de bewijzen voor correcte en veilige werking. Alleen een proceseis stellen is niet voldoende om een cultuur van veiligheid en aantoonbaarheid te verkrijgen.”

Er wordt kennelijk (nog) niet om zo’n standaard gevraagd. Hoe komt dat?

Jørgen Heinrich: “Er wordt niet expliciet om gevraagd, maar een standaard zou wel een logisch gevolg zijn van de vraag naar aantoonbare beschikbaarheid en veiligheid. Het heeft te maken met volwassenheid van de markt. Je ziet dat er steeds meer op basis van systems engineering wordt gewerkt. Daar volgt uit dat je duidelijke afspraken wilt maken.”

Auke Sjoukema: “Standaardiseren past inderdaad bij de wens om steeds meer te certificeren en valideren. Je moet een bepaalde mate van betrouwbaarheid kunnen aantonen. Daarom sluit ik ook niet uit dat een standaard ICT-proces gevraagd zal gaan worden voor tunneltechnische installaties. Wellicht is er nu nog sprake van onderschatting van het afbreukrisico. Voor treinbeveiligingsystemen zien we een heel strikte normering.  De aanpak bij tunneltechnische installaties is gebaseerd op de certificeringseisen vanuit het Bouwbesluit, onder andere voor brandmeldinstallatie, rookwarmteafvoer en  bluswatervoorziening,  en de Europese eisen voor validatie uit de TSI Safety in Railwaytunnels.”

Wat zou de volgende stap moeten zijn om tot een standaard te komen?

Auke Sjoukema: “Het belang van standaardisatie staat zeker al op de agenda. ProRail heeft nu de interne opdracht om een nieuw treinstilstanddetectiesysteem te ontwikkelen voor de Willemsspoortunnel in Rotterdam. We kijken verder dan alleen die tunnel, door een ‘kookboek’ te ontwikkelen met daarin de receptuur die voor alle tunnels toepasbaar is. Zo komen we tot eenduidige afhandeling.”

Jørgen Heinrich: “Het bewustzijn is absoluut aanwezig. Het ‘kookboek’ dat Auke noemt, kan zeker een goede volgende stap zijn. Daarin leg je de functionaliteit vast, zodat je per tunnel een keuze kunt maken. Dan voorkom je de discussie over wel of geen sprinkler en ga je terug naar de functie. Wil je een brand in een bepaalde tijd kunnen bestrijden, of moet de tunnel zodanig zijn gebouwd dat deze bestand is tegen een brand?”

Hoe moet zo’n standaard ICT-proces tot stand komen? Wie bepaalt?

Jørgen Heinrich: “Bij treintunnels is het vanzelfsprekend ProRail die bepaalt. Dat is dan de opdrachtgever.”

Auke Sjoukema: “Maar dan moeten we wel eerst ons huis op orde hebben. Daarna kunnen we aan dit soort optimalisaties gaan denken. En dat gaat misschien wel sneller dan we denken. Spoorzone Delft levert hopelijk een aantal best practices op die we snel kunnen invoeren.”

Tot slot. Komt zo’n standaard ICT-proces er ook echt?

Jørgen Heinrich: “Ja, dat gaat er komen. Het zou voor de branche en de belastingbetaler goed zijn als er voor het hele proces, vanaf het pakket van eisen, via engineering en bouw tot beheer aan toe, een uniforme aanpak komt. Dat levert meer kwaliteit en scheelt veel faalkosten.”

Auke Sjoukema: “Ja, maar ik weet nog niet met welke diepgang. Het ‘kookboek’ van ProRail zal nooit hetzelfde zijn als dat van Rijkswaterstaat. Maar de processen zijn wel gelijk, en daarin kun je van elkaar leren.”

 Reacties uit het netwerk

Daan Dörr, consultant industriële automatisering:

“Movares en Prorail denken in dezelfde richting als de dienst Stadsbeheer van gemeente Den Haag; zij beogen iets soortgelijks met de Haagse Tunnel Standaard (het ICT deel van de LTS voor stadstunnels).

Veilig werkende software vraagt om standaardisatie (hergebruik van al eerder gerealiseerde en bewezen software) én het in veilige toestand komen van de processen bij het falen van een hardware ICT-onderdeel. Dat laatste heeft alles te maken met de autonome bedrijfszekerheid van een onderdeel en de hardware-architectuur waarin deze is geplaatst.

Software zelf kan niet falen, het is immers niet aan slijtage onderhevig. Van belang is dat software goed is ontworpen en getest, zodat de beoogde tunnelveiligheid met behulp van programmatuur wordt bereikt. ‘Standaard’ software (waaronder systeemsoftware) en ‘standaard’ architectuur (waaronder standaardpakketten) zijn dus sleutelwoorden. Fabrikanten leveren verschillende veelvuldig toegepaste ‘standaards’, het is evident dat het gebruik daarvan meer zekerheid geeft over de goede werking.

Waar de LTS besturingsfunctionaliteit (veelal software) beschrijft, sluit deze niet aan op standaards van leveranciers. Technisch is dit geen probleem, met behulp van applicatiesoftware is alles te bouwen. De LTS heeft vooral een stap gemaakt bij de standaardisatie van de technische processen (TTI’s). De automatisering zal echter voor elke tunnel anders uitpakken. Daar valt veel te halen voor wat betreft veiligheid, en dan niet alleen bij de bouw maar ook bij de verwerking van updates van systeemsoftware.

Bij de Haagse Tunnel Standaard (HTS) wordt geprobeerd meer gebruik te maken van de standaard mogelijkheden van besturingsystemen en wordt door opdrachtnemers zelf gemaakte apparatuur (dit zijn feitelijk geen COTS-producten) uitgesloten. Ook zijn de besturingsarchitecturen en details voor de MMI verder gespecificeerd, tevens worden de applicaties die daaruit volgen eigendom van de opdrachtgever. Hergebruik van (bewezen) software bij verschillende tunnels is zo beter te organiseren.”