In het project Spookfiles A58 werken zo’n dertig publieke en private partijen aan de ontwikkeling en uitrol van coöperatieve technologie. Daarmee is ook veel ervaring opgedaan met de transities zoals beschreven in de Routekaart Beter Geïnformeerd op Weg. In deze paper zoomen we in op het transitiepad ‘Van overheidsregie naar publiek-private samenwerking en allianties’. Samenwerking staat in Spookfiles A58 centraal en om die reden is het werk in ‘percelen’ opgeknipt en is er gekozen voor pre- commercial procurement. Maar de samenwerking is ook gefaciliteerd met een aanpak voor systeemintegratie, testprotocollen, een expertgroep, een Change Control Board die aanpassingen aan het systeem begeleidt en bewaakt en een ticketingsysteem dat het volgen en afhandelen van de issues overzichtelijk houdt.
Het Beter Benutten-project Spookfiles A58 is een initiatief van de provincie Noord-Brabant en het Ministerie van Infrastructuur en Milieu. Samen met Rijkswaterstaat, marktpartijen en kennisinstellingen wordt sinds eind 2014 hard gewerkt aan de introductie van het coöperatieve voertuig-wegkantsysteem. De A58 tussen Tilburg en Eindhoven is het proefterrein: hier staan inmiddels 34 wegkantbakens voor snelle communicatie over wifi-p. Dankzij het systeem en z’n bakens kunnen (coöperatieve) voertuigen en de weginfrastructuur voortdurend informatie delen en zo ‘samenwerken’ aan een efficiënt en veilig verkeerssysteem.
Om te zien hoe de technologie zich in de praktijk houdt, hebben de projectpartners meteen een eerste coöperatieve dienst ontwikkeld, de spookfiledienst. Op basis van nauwkeurige informatie over snelheidsverschillen op het proeftraject krijgen deelnemers gepersonaliseerde in-car snelheidsadviezen. Deze dienst is begin december 2015 met succes beproefd. (In mei 2015 was ook al een initiële test gedaan. Maar in december ging het om een eerste echte, complete proef. De dienst wordt in 2016 verder getest met een grotere groep gebruikers.)
In diezelfde maand nog werd een tweede dienst opgezet: Road Works Warning, oftewel in-car waarschuwingen en aanwijzingen bij wegwerkzaamheden. Het Nederlandse projectteam Coöperatieve ITS Corridor van Rijkswaterstaat had de specificaties voor deze dienst ontwikkeld en al eerder op de A16 getest. De partijen van Spookfiles A58 hebben vervolgens laten zien dat de specificaties vrijwel naadloos passen in de open architectuur van de A58. In slechts twee weken tijd werd de Road Work Warning-service geïmplementeerd én op het proeftraject gedemonstreerd.
Beter Geïnformeerd op Weg is een initiatief van het Ministerie van Infrastructuur en Milieu en dateert uit februari 2013. Het betreft een ‘koersbepaling’ van de rijksoverheid en de verkeersindustrie voor de thema’s Verkeersmanagement en Verkeersinformatie. Doel van het actieprogramma is om te komen tot een slimme en inhoudelijk consistente mix van informatie via smartphones, navigatiesystemen en collectieve informatiekanalen.
Om deze doelen te realiseren is Beter Geïnformeerd op Weg later in 2013 nader ingevuld met een Routekaart. Deze ‘kaart’ stippelt de koers uit naar het einddoel, met een doorkijk van tien jaar (2013 tot 2023). De samenstellers van de Routekaart, een informele overlegtafel bestaande uit vertegenwoordigers van wegbeheerders, serviceproviders, industrie en onderzoeksinstellingen, hebben eerst vastgesteld waar we staan en wat de maatschappelijke trends zijn. Vervolgens is gekeken hoe de trends moeten worden bijgestuurd, om het eindplaatje van Beter Geïnformeerd op Weg zo goed mogelijk te benaderen. Die exercitie resulteerde in zes zogenaamde ‘transitiepaden’, die staan voor de belangrijkste veranderopgaven van de komende periode. Zie figuur 1.
Het project Spookfiles A58 levert door zijn doelstelling, product en een bijdrage aan alle transitiepaden uit de Routekaart.
Om te beginnen is het hele concept van coöperatieve technologie gericht op individuele dienstverlening (pad 1). Een voorbeeld is de spookfiledienst, waarin deelnemers een individueel, gepersonaliseerd snelheidsadvies krijgen. Daarnaast maakt de coöperatieve infrastructuur voertuig-voertuigcommunicatie mogelijk.
Door de adviezen in-car te brengen, verandert de rol van wegkantsystemen (pad 2). Ook de samenwerking tussen publiek en privaat wordt op dit punt anders ingevuld: op het proeftraject op de A58 hebben leveranciers nu de eigen coöperatieve roadside units gekoppeld aan de systemen van Rijkswaterstaat.
Figuur 1: De zes transitiepaden van de Routekaart Beter Geïnformeerd op Weg.
Spookfiles A58 richt zich vanwege het experimentele karakter alleen op de A58, maar het hele systeem is zo opgezet dat het opschaalbaar en continueerbaar is (pad 3). De ervaringen worden bijvoorbeeld al gebruikt in het Innovatiepartnership Talking Traffic. Ook bij het opzetten van de nieuwe Brabantse testomgeving wordt voortgebouwd op de in Spookfiles A58 opgedane kennis.
Dan is er nog de marktwerking (pad 4). Het opgeleverde coöperatieve systeem is sowieso niet één product van één leverancier, maar bestaat uit afzonderlijk ontwikkelde deelsystemen van verschillende leveranciers. Het feit dat er steeds is uitgegaan van internationale ETSI-standaarden, maakt een goed samenspel van meerdere commerciële partijen mogelijk.
Daarnaast is de architectuur zo opgezet dat meerdere serviceproviders rechtstreeks met weggebruikers (dat wil zeggen: hun klanten) kunnen communiceren. Er zijn hierbij kansen voor zowel business to business, met bijvoorbeeld diensten aan logistieke bedrijven, als business to consumer. De toekomst moet uitwijzen of de gekozen marktordening optimaal is, maar de basis voor samenwerking, competitie en doorontwikkeling is gelegd.
Data hebben een cruciale plek in Spookfiles A58. Overheidsdata worden door private partijen maximaal ontsloten (pad 5) en gemixt met privaat ingewonnen data. Daarbovenop komen nog de nauwkeurige en waardevolle gegevens die de coöperatieve voertuigen genereren. Die kunnen door zowel wegbeheerders als serviceproviders worden gebruikt.
En dan de publiek-private samenwerking en allianties (pad 6). Die samenwerking is een logisch gevolg van de ontwikkelingen op de andere paden en dan met name op 2, 4 en 5. In het onderstaande gaan we dieper in op de ervaringen die de Spookfiles A58-partijen hierbij hebben opgedaan.
Provincie Noord-Brabant en het Ministerie van Infrastructuur en Milieu hebben met het project Spookfiles A58 van meet af aan ingezet op publiek-private samenwerking en een publiek-privaat ‘eindproduct’: een coöperatief platform waarin verschillende overheids- en marktpartijen een rol hebben in het bouwen en operationeel houden van (deel)systemen en diensten.
Om naar dat eindproduct toe te werken, is ervoor gekozen om het coöperatieve platform open en generiek op te zetten, waar mogelijk gebruik makend van internationale standaarden zoals ETSI. Hiermee blijft toegang van nieuwe leveranciers en deelnemers geborgd.
Verder is bewust gekozen voor een onderverdeling in drie percelen die ook door meerdere (verschillende) partijen worden ingevuld:
De drie percelen zijn goed zichtbaar in de zogenaamde High Level Architecture van het coöperatieve systeem – zie figuur 2. In de architectuur is afzonderlijk een plek ingeruimd voor aanbieders van data, aanbieders van diensten en aanbieders van de coöperatieve wegkantsystemen. Op die manier blijft er ruimte voor uiteenlopende bedrijven van verschillend formaat en wordt de markt minder gedomineerd door een handvol grote spelers. De gestandaardiseerde koppelvlakken (de lijnen tussen de blokken) verbinden de producten van de verschillende leveranciers tot één geheel. Ze stellen nieuwe bedrijven ook in staat om vlot aan te haken met nieuwe diensten.
Merk op dat de aanbieders van data, diensten en wegkantsystemen elk een afgebakend deel van de waardeketen invullen en zo samen één ‘product’ mogelijk maken.
Figuur 2: De architectuur (‘High Level Architecture’) van het coöperatieve systeem van Spookfiles A58. De drie percelen Data (rood), Diensten aan de weggebruiker (blauw) en Communicatie (groen) kunnen door verschillende partijen worden ingevuld, zowel in samenwerking als in concurrentie met elkaar.
In de geest van het einddoel is ook het project zelf zo opgezet dat verschillende marktpartijen bijdragen: er is gekozen voor een PCP-constructie. PCP is een afkorting van ‘pre-commercial procurement’, een instrument dat sinds enkele jaren door de EU wordt gepromoot. In een PCP-constructie werken marktpartijen in drie fasen aan een oplossing voor een maatschappelijk probleem, die zij na het project als commerciële dienst of product kunnen aanbieden. Belangrijke voorwaarde is dat de gekozen oplossingen schaalbaar, overdraagbaar en continueerbaar zijn.
Voor Spookfiles A58 zag dat proces er als volgt uit. In fase 1 (start januari 2014) hebben elf consortia, bestaande uit zo’n dertig bedrijven en kennisinstellingen, een gezamenlijk solution design gespecificeerd. Op basis daarvan hebben de consortia vervolgens elk een ontwerp voor hun eigen deelsysteem gemaakt. Deze ontwerpen zijn getoetst op haalbaarheid, waarna zeven consortia verder konden in fase 2 (vanaf mei 2014) om hun ontwerp te implementeren in een prototype. Dit betreft een dienst gebaseerd op lange-afstandscommunicatie en een proof of concept voor de snellere korte-afstandscommunicatie. Na een laatste competitie en doorselectie zijn in fase 3 zes leveranciers gestart (vanaf juli 2015) met de field tests: de fysieke uitrol van coöperatieve communicatie langs de A58, de opschaling van de dienst die van 3G/4G gebruik maakt en ook de uitrol van een dienst die werkelijk coöperatief is.
Na afloop van het project kunnen de diensten commercieel worden uitgerold. Ook eerder afgevallen of nieuw instappende bedrijven kunnen zich op dit punt (weer) in de strijd werpen als data-aanbieder, dienstenaanbieder en/of aanbieder van wegkantsystemen. Het landelijke Innovatieppartnership Talking Traffic en de Brabantse testomgeving laten zien dat dit ook daadwerkelijk gebeurt. Zie ook figuur 3.
Figuur 3: De verschillende fasen in de PCP-constructie die Spookfiles A58 gebruikt.
Dankzij de onderverdeling in percelen en de PCP-constructie hebben provincie Noord-Brabant, het Ministerie van Infrastructuur en Milieu en Rijkswaterstaat in zijn rol als wegbeheerder in alle fasen van het Spookfiles A58-project met meerdere marktpartijen samengewerkt. Er is hierbij waardevolle ervaring opgedaan op pad 6 van de Routekaart Beter Geïnformeerd op Weg. Wat zijn de belangrijkste lessen?
Eén grote uitdaging op dit pad is om ervoor te zorgen dat al die ‘halfproducten’ van de verschillende leveranciers op een gegeven moment samenkomen en (bij uitbreidingen, wijzigingen of updates) ook samen blijven tot één werkend geheel. Er is immers niet één opdrachtgever die als system integrator optreedt – de integratie is een gezamenlijke verantwoordelijkheid. Hoe pak je dat aan? Hoe voorkom je dat de ene partij de belangen van de andere partij schaadt, of zelfs het systeem of de dienst als geheel? En hoe zorg je ervoor dat bij problemen de een niet naar de ander gaat wijzen of de een op de ander wacht? Voor de wegbeheerders komt daar nog de extra uitdaging bij om vanuit de eigen publieke rol het collectieve belang te bewaken in de samenwerking met commerciële partijen, die een ander doel en een andere cultuur hebben. Om dit alles in goede banen te kunnen leiden, is het essentieel om vooraf en gezamenlijk de spelregels en de werkwijze vast te stellen.
In het project Spookfiles A58 is hiervoor een bruikbare aanpak geïntroduceerd – zie figuur 4. De figuur toont zowel de oorspronkelijke systeemintegratie als de mechanismen om issues af te handelen en de regie op ‘changes’ te houden.
Figuur 4: Systeemintegratie in Spookfiles A58
Vertrekpunt van dit plaatje zijn de gezamenlijk vastgestelde Operational Concept Description (beschrijving van het systeem en de dienst in termen van eisen stakeholders, relatie met de omgeving en het beoogd gebruik), de High Level Architecture (de functionaliteiten van het systeem en hun relaties) en een overzicht van de eisen die gelden voor de externe koppelvlakken (de ‘schakels’ tussen de verschillende functionaliteiten).
De systeemintegratie start vervolgens linksonder, bij de specificatiecyclus. In deze cyclus worden de afspraken gemaakt over de koppelvlakken. Om ervoor te zorgen dat alle partijen – privaat én publiek – hun kennis kunnen inbrengen, vindt dit werk plaats in werkgroepverband. Als de specificaties voor de systemen en diensten aldus zijn uitgewerkt en gereviewd, worden ze voorgelegd aan deze (strategische) expertgroep. (Deze groep bestaat uit strategische adviseurs en heeft als taak de grote (strategische) lijnen te bewaken. Elk opgeleverde specificatie, product of dienst wordt vóór vrijgave eerst aan dit team voorgelegd.) Deze checkt de specificatie en na eventuele aanpassingen wordt een nieuwe set specificaties vrijgegeven.
Dat is de input voor de tweede cyclus: de ontwikkelingscyclus. Dit betreft het bouwen van de (deel)systemen of diensten. Het werk wordt hier door de afzonderlijke leveranciers verricht. Omdat andere partijen wellicht afhankelijk zijn van de producten van de betreffende leverancier, worden er wel duidelijke afspraken gemaakt over deadlines.
Vóór de definitieve oplevering test de leverancier zijn product zelf aan de hand van vooraf opgestelde testprotocollen. De expertgroep checkt op basis van de rapportages of de oplevering akkoord is.
Hiermee zijn we bij de derde cyclus beland, de testcyclus. Waar de leveranciers in de voorgaande cyclus nog zelfstandig hun eigen producten testten, wordt er hier gezamenlijk getest.
De opgeleverde producten worden eerst als deelsysteem getest. Bijvoorbeeld: verloopt het hele traject van het inwinnen, bewerken en beschikbaar stellen van data goed? Kunnen er succesvol berichten worden verzonden via de wegkantbakens? Enzovoort. Daarna wordt het systeem als geheel getest, maar nog in een geïsoleerde ‘acceptatieomgeving’: een compleet werkend systeem, inclusief zendmasten langs de weg, die echter uitsluitend met testrijders communiceert. Het gaat aan om kleine testgroepen met friendly users, zoals medewerkers van de leveranciers.
Als de expertgroep de tests heeft gecheckt en geaccordeerd, wordt de productieomgeving vrijgegeven: het systeem kan dan ‘live’.
De vierde cyclus is de productiecyclus, waarin elke leverancier zijn deel doet: data beschikbaar stellen, communicatie verzorgen of diensten aanbieden. Vanuit zo’n stevige basis kan eventueel aan een gecontroleerde opschaling worden gewerkt.
In een perfecte wereld zou het proces daarmee zijn afgerond: alles is immers getest en draait nu ook ‘live’. De realiteit is echter dat er in de productiefase, op het moment dat reguliere deelnemers de Spookfiledienst gebruiken, er nog geregeld iets aangepast of verbeterd zal worden. Daarom beschrijft figuur 4 ook hoe met issues – een verzoek of incident dat met hoge prioriteit moet worden opgelost – en changes om te gaan.
Als het gaat om een issue probeert de 'signalerende partij' die eerst zelf (als het de veroorzaker is van het probleem) of bilateraal met de veroorzaker op te lossen. Als dat niet snel genoeg tot resultaat leidt, wordt het Change Control Board ingeschakeld. Dit team bestaat uit vertegenwoordigers van alle betrokken partijen en is verantwoordelijk voor het snel oplossen van incidenten.
Het eerste wat de Board doet, is bepalen bij wie het probleem ligt. Afhankelijk van de urgentie worden experts uit het consortium gemobiliseerd voor ondersteuning. Samen met de ‘probleemeigenaar’ wordt bekeken wat de impact van de benodigde reparatie is: klein (minor) of groot (major). Een wijziging is minor als er geen aanpassing van de specificaties nodig is en als de wijziging geen effect heeft op eigenschappen van het betreffende product. De betreffende leverancier kan dit in principe zelf afhandelen. Alle andere wijzigingen zijn major.
De Change Control Board bekijkt nu waar de change request neergelegd moet worden. Vereist het een aanpassing van de specificaties? Dan worden de werkgroepen van de specificatiecyclus aan het werk gezet. Ligt het op productniveau? Dan gaat het verzoek naar de leverancier van dat product. Omdat het een major aanpassing is, worden alle stappen vanaf die betreffende cyclus weer doorlopen. Na een wijziging van een specificatie wordt de nieuwe specificatie dus weer voorgelegd aan de expertgroep, daarna wordt het doorgezet naar de cyclus ‘ontwikkelen’, vervolgens wordt er getest en pas als alle tests in de acceptatieomgeving naar behoren zijn doorlopen, kan de verandering in de live-omgeving worden doorgevoerd.
Het werken volgens de opeenvolgende cycli specificatie-ontwikkeling-test- productie en de Change Control Board heeft ertoe geleid dat de ontwikkeling van het coöperatieve systeem en de oplevering van de eerste diensten ordelijk en zonder tijdrovende issues en conflicten zijn verlopen.
Werkenderwijs bleken wel de volgende punten van (extra) belang:
Testprotocol. Het is essentieel dat goed wordt vastgelegd hoe de tests voor de verschillende componenten dienen te verlopen: wat gaan we testen, hoe doen we dat en wanneer noemen we een test geslaagd? Die afspraken gezamenlijk vormen het testprotocol.
Een voorbeeld is de test of er berichten verzonden kunnen worden via de wegkantbakens. Een eerste stap is testen of het überhaupt werkt. Maar daarna wil je ook weten hoe het systeem het onder druk houdt. Dan zul je eerst moeten nagaan wat de performance beïnvloedt en wat de risico’s zijn voor de performance – daarop baseer je dan de tests. Je komt dan uit op een protocol als: ‘berichtenverkeer met wegkantbaken moet probleemloos verlopen als x voertuigen tegelijkertijd een signaal uitzenden in het bereik van dat baken’.
In principe moet er voor alle onderdelen van het systeem zo’n testprotocol worden opgesteld. De betrokken partijen zullen testcases en testresultaten goed moeten documenteren, om zo kennis uit te wisselen.
Ticketingsysteem. De Change Control Board is een noodzakelijke ‘laag’ in de organisatie om issues vlot en op de juiste manier te kunnen afhandelen. Het blijft echter lastig om de status van de afhandeling te volgen: elke leverancier heeft zijn eigen ‘storingssystemen’ voor de melding en afhandeling van problemen. Daarom is in Spookfiles A58 afgesproken dat alle partijen een centraal (open source) ticketingsysteem gebruiken. Met dit systeem kan een issue worden aangemeld (er wordt een ticket aangemaakt), toegewezen aan een partij (die heeft de verantwoordelijkheid het probleem aan te pakken), waarna alle vorderingen worden gemeld en voor iedereen zichtbaar zijn. Na het oplossen van het probleem wordt het ticket gesloten.
Waarin een ticketingsysteem overigens niet voorziet is in een supervisor, bewaker en aanjager: wie zorgt ervoor dat problemen niet blijven liggen of al te snel weer worden doorgezet naar een andere partij? Dit lijkt geen taak van de Change Control Board, maar zou wellicht belegd kunnen worden bij een ‘issuemanager’, wiens taak het is puur toe te zien op de afhandeling van door de Change Control Board aangevraagde changes. Daarbij is het natuurlijk voor de waarde van het systeem van belang dat alle betrokken partijen hun ‘change management informatie’ altijd vlot, volledig, juist en eenduidig doorgeven.
Het project Spookfiles A58 is zowel wat doelstelling, product als aanpak betreft goed in lijn met de transities zoals voorzien in Beter Geïnformeerd op Weg. In deze paper hebben we ons geconcentreerd op de ervaringen op pad 6, de transitie naar meer publiek-private samenwerking en allianties.
Samenwerking zit al in de opzet van Spookfiles A58 gebakken, zo hebben we besproken. Denk aan de keuze om het project (en daarmee ook het uiteindelijke coöperatieve systeem) als gezamenlijke verantwoordelijkheid van deelnemende bedrijven te zien, het werk in percelen op te knippen en te kiezen voor ‘pre-commercial procurement’. Maar de beoogde samenwerking is ook gefaciliteerd met een aanpak voor systeemintegratie, inclusief testprotocollen en controles door een expertgroep. In de aanpak is verder een mechanisme opgenomen om problemen en veranderverzoeken af te handelen als het systeem eenmaal live is: een speciale Change Control Board die aanpassingen begeleidt en bewaakt en een ticketingsysteem dat het volgen en afhandelen van de issues overzichtelijk houdt.
Het project Spookfiles A58 heeft dus niet alleen een solide basis gelegd voor de uitrol van innovatieve coöperatieve technologie, maar ook een interessante blauwdruk geleverd voor grootschalige publiek-private samenwerkingsprojecten.