Spookfiles A58. OCD en Solution Design. Het gemeenschappelijke eindrapport (deliverable) van de Haalbaarheidsfase WP1 in het Spookfiles A58 Project

Spookfiles A58 OCD en Solution Design Het gemeenschappelijke eindrapport (deliverable) van de Haalbaarheidsfase WP1 in het Spookfiles A58 Project

versie 1.1 datum: 16 juli 2014

Colofon Wie zit er achter het project? Spookfiles A58 is een project van de Provincie Noord Brabant en de Stadsregio Eindhoven. Deze werken hierbij nauw samen met het Ministerie I&M (Programma Beter Benutten) en een groot aantal marktpartijen. Gezamenlijk ontwikkelen zij een oplossing voor het effectief bestrijden van spookfiles op de A58 die in de praktijk pre-commercieel uitgerold zal worden.

Wat is de strekking van het OCD en Solution Design document? De Spookfiledienst is opgebouwd volgens een heldere architectuur waarbij diverse koppelvlakken in detail zijn beschreven. Doel is om een dienst te ontwikkelen die niet alleen nu op de A58 werkt, maar die tevens het potentieel heeft om op grote schaal en door andere marktpartijen op competitieve wijze uitgerold te worden. Dit document beschrijft de gemeenschappelijke visie en solution design van de Spookfiledienst A58. Belangrijke onderdeel hiervan is het mogelijk maken van marktwerking. Hiertoe worden in dit document de architectuur en de koppelvlakken gespecificeerd die door alle leveranciers in het project toegepast moeten worden.

Wie heeft wat geschreven Dit document is opgesteld door het Spookfiles A58 Ontwikkelingsteam als onderdeel van Werkpakket 1 (WP1). De marktpartijen, georganiseerd in werkgroepen en een 'Centrale Architectuur Groep'(CAG) hebben het document vorm en inhoud gegeven. De opdrachtgever heeft het specificatieproces van de OCD en Solution Design gefaciliteerd. De achterliggende visie, de uitgangspunten, de architectuuren koppelvlakspecificaties worden als zodanig door elk van de deelnemende marktpartijen geaccepteerd en ondersteund: -

DEEL I, Operational Concept Description is geschreven door de Centrale Architectuur Groep van het Spookfiles A58 project (marktpartijen met inbreng van RWS). DEEL II, bestaande uit: o High Level Architecture is geschreven door de Centrale Architectuur Groep van het Spookfiles A58 project (marktpartijen met inbreng van RWS). o Uitwerking specificaties van koppelvlakken en aandachtsgebieden is geschreven langs een zestal onderdelen door werkgroepen (Werkgroep 1, 5 en 6: marktpartijen met inbreng van RWS, Werkgroep 3: marktpartijen & met inbreng HMI aspecten door I&M, Werkgroep 2 en 4: marktpartijen).

Dit document reflecteert niet noodzakelijkerwijs de mening of voornemens van de Provincie Noord Brabant, het Samenwerkingsverband Regio Eindhoven of het Ministerie I&M.

Deelnemende marktpartijen Perceel 1 Be-Mobile NV 1. 2.

Goudappel Siemens

Innovactory International BV 1. Simacan BV 2. Tom Tom (Global Content) BV 3. TU Eindhoven

Prime Vision BV / Prime Data 1. Beijer 2. NXP 3. Sioux Embedded Systems 4. Tass / DITCM 5. TNO 6. Tom Tom

Perceel 2 Cygnify BV 1. 1. 2. 3.

Locatienet NXP Tom van de Ven TU Delft

Sioux Embedded Systems BV 1. Beijer 2. NXP 3. Prime Vision BV / Prime Data 4. Tass International / DITCM 5. TNO 6. Tom Tom 7. RTL Nederland

Technolution BV 1. 2. 3.

Imtech Traffic & Infra NXP TU Delft

1. 2. 3. 4. 5.

Andes- Geo Solutions Kapsch Organiq Tom Tom TU Delft

1. 2. 3. 4. 5. 6. 7. 8.

BE-Mobile Fourtress NXP Spring Holding TNO Beijer Fantazm .TIM

Vialis BV

V-Tron BV

Perceel 3 Imtech Traffic & Infra 1. NXP 2. Technolution BV 3. TNO

Siemens Nederland BV 1. BE-Mobile

Vialis BV 1.

NXP

Colofon .................................................................................................................................................... 3 Leeswijzer ................................................................................................................................................ 7 DEEL I: OPERATIONAL CONCEPT DESCRIPTION ....................................................................................... 8 1

Achtergrond en doel Spookfiles A58 project en -oplossing ............................................................ 9

2

De Spookfile nader gedefinieerd ................................................................................................... 11

3

2.1

Introductie op het fenomeen van (spook)files ..................................................................... 11

2.2

Definitie Spookfile ................................................................................................................. 11

Concept van de Spookfiledienst .................................................................................................... 14 3.1

Inleiding op een Spookfiledienst ........................................................................................... 14

3.2

Generieke beschrijving Spookfiledienst ................................................................................ 14

3.3

Beschrijving op basis van een vergelijking met bestaande diensten .................................... 15

4

Toekomstvisie ................................................................................................................................ 20

5

Afgeleide uitgangspunten ............................................................................................................. 22 5.1

5.1.1

Horizontalisering ........................................................................................................... 22

5.1.2

Borgen van de commerciële levensvatbaarheid van een Spookfiledienst.................... 24

5.2

Spookfiledienst coöperatieve kanalen .................................................................................. 25

5.3

Spookfiledienst coöperatieve berichten ............................................................................... 27

5.3.1

Standaard berichten ...................................................................................................... 27

5.3.2

Leverancier-specifieke berichten .................................................................................. 28

5.3.3

Ondersteunde berichten ............................................................................................... 28

5.4

Verkeersmanagementadvies in geval van meerdere Service Providers ............................... 30

5.4.1

Marktontwikkelingen en drie mogelijke toekomstscenario’s ....................................... 30

5.4.2

Onderscheid tussen testfase en commerciële fase, en het belang van innovatie ........ 30

5.4.3

Ruimtelijk of temporeel scheiden? ............................................................................... 31

5.4.4

Invloed van het gebruik van het Control Channel mbt het Service Channel ................ 31

5.4.5

Conclusies ...................................................................................................................... 32

5.5

Coöperatief verkeersmanagement langs de weg en in het voertuig ................................... 32

5.5.1

Functioneel .................................................................................................................... 32

5.5.2

Het hosten van coöperatieve applicaties ...................................................................... 33

5.5.3

Visie op de lokale communicatie infrastructuur ........................................................... 33

5.6 6

Spookfiledienst onderdeel van marktconform ecosysteem ................................................. 22

"Roaming" & "Interoperabiliteit" .......................................................................................... 34

Impact op gebruikers/stakeholders .............................................................................................. 37

DEEL II: UITWERKING SOLUTION DESIGN EN AANDACHTSGEBIEDEN .................................................. 39 7

High Level Architectuur ................................................................................................................. 40 7.1

Introductie ............................................................................................................................. 41

7.1.1

Overzicht functionele omschrijving laag in de HLA ....................................................... 41

7.1.2

Overzicht van functionele omschrijving per koppelvlak ............................................... 42

7.2

Introductie werkgroepen ...................................................................................................... 45

Annex I: gerefereerde documenten ...................................................................................................... 47 Annex II: afkortingen ............................................................................................................................. 47 Annex: Werkgroep 1.............................................................................................................................. 48 Annex: Werkgroep 2.............................................................................................................................. 49 Annex: Werkgroep 3.............................................................................................................................. 50 Annex: Werkgroep 4 M&E..................................................................................................................... 51 Annex: Werkgroep 4 Testen Plan van Aanpak ...................................................................................... 52 Annex: Werkgroep 4 Deelnemerswerving en -communicatie .............................................................. 53 Annex: Werkgroep 5.............................................................................................................................. 54 Annex: Werkgroep 6.............................................................................................................................. 55

Leeswijzer De Spookfiledienst is opgebouwd volgens een heldere architectuur waarbij diverse koppelvlakken grondig en tot in detail zijn beschreven met het doel een dienst te ontwikkelen die niet alleen nu op de A58 werkt, maar die tevens het potentieel heeft om op grote schaal ook elders en door andere marktpartijen op competitieve wijze uitgerold te worden. Dit document beschrijft de visie en gemeenschappelijke solution design van de spookfile dienst A58 die deze marktwerking dient te borgen. Het specificeert hiertoe de architectuur en de koppelvlakken die door alle leveranciers in het project toegepast moeten worden. Het OCD document is opgebouwd langs een pragmatische interpretatie van de system engineering aanpak waarbij eerst de Operational Concept Description (OCD) wordt afgeleid, vervolgens de architectuur en dan de koppelvlak-specificaties: 





DEEL I: Operational Concept Description: hierin wordt de Spookfiledienst beschreven in termen van project- en stakeholder-eisen, de relatie met de omgeving en de wijze waarop het gebruikt gaat worden. In dit hoofdstuk is veel aandacht gegeven aan de motivatie van keuzes in de architectuur van de Spookfiledienst en de relatie van deze keuzes met bijvoorbeeld de gewenste marktontwikkeling en aansluiting bij verkeersmanagement toepassingen; DEEL II: High Level Architectuur (HLA): hierin worden de functionaliteiten op overzichtelijke wijze zichtbaar gemaakt en met elkaar in relatie gebracht. Op deze wijze wordt duidelijk waar de belangrijke externe koppelvlakken bestaan (extern wil zeggen dat via dit koppelvlak functionaliteit die onder de verantwoordelijkheid van de ene marktpartij valt beschikbaar wordt gemaakt voor functionaliteit die onder de verantwoordelijkheid van een andere partij valt). De HLA vormt een basis voor verder specificatiewerk en de ontwikkeling van individuele partijen, maar dient evenals DEEL I zeker het communicatiedoel dat verschillende stakeholders elkaar beter begrijpen en dezelfde taal spreken; ANNEXES 1 - 6: Koppelvlak specificaties en uitwerking aandachtsgebieden: hierin worden de eisen beschreven die gesteld worden aan de Spookfiledienst waaronder de eisen die gelden voor de externe koppelvlakken. Deze specificaties vormen de basis voor de verdere ontwikkeling (gedurende fase II in het project zal hieruit een SSS, IRS en IDD worden afgeleid).

De koppelvlak-specificaties zijn uitgewerkt in werkgroepen waarbij er voor gezorgd is (door de Centrale Architectuur Groep CAG en 2-wekelijkse afstemming) dat elk van de werkgroepen dezelfde architectuur en uitgangspunten hanteerde. Vanwege de autonomie waarmee de specificaties zijn afgeleid, is er gekozen om de resultaten per werkgroep integraal per bijlage (dus met eigen inleiding, afleiding, etc...) op te nemen.

Spookfiles A58, Operational Concept Description en Solution Design versie 1.1

blz 7

DEEL I: OPERATIONAL CONCEPT DESCRIPTION


blz 8

1 Achtergrond en doel Spookfiles A58 project en -oplossing De marktpartijen ontwikkelen met de Spookfiledienst een oplossing die de frequentie en lengte van files ontstaan door schokgolfvorming effectief kan terugdringen. Met het beschikbaar komen van deze dienst in een competitieve markt - waarvan de komst met dit project wordt bespoedigd - wordt collectieve waarde gecreëerd in de vorm van verbeterde mobiliteit, verkeersveiligheid en duurzaamheid. De verwachting is dat de opdrachtgever en meer generiek de wegbeheerders in Nederland in deze markt een afnemer zullen zijn1. Daarnaast is het mogelijk dat de Spookfiledienst onderdeel wordt van een private dienst. De dienst zal dan wel aangeboden moeten worden op een wijze die voldoende meerwaarde biedt of differentiatie creëert die de investeringen en operationele kosten van een dergelijke dienst verantwoorden. Het is dus nog onduidelijk hoe de wereld waarin de Spookfiledienst commercieel operationeel is, er precies uit zal zien. Waar de experts en marktpartijen in dit project het wel unaniem over eens zijn, is dat de Spookfiledienst slechts één van de toepassingen zal zijn die gebruik maakt van de onderliggende 'ICT' infrastructuur. Er zullen dus geen 'kastjes' in auto's worden geïnstalleerd die alleen het doel hebben om berichten van de Spookfiledienst te ontvangen; er zal er geen systeem van coöperatieve wegkantstations uitgerold worden met als enige doel het versturen van ‘spookfileberichten'; en er zullen geen data-inwin en -verrijkingsprocessen geïmplementeerd worden exclusief voor de afleiding van een goed advies in de Spookfiledienst. Een direct afgeleide conclusie van bovenstaande constateringen is dat de ontwikkeling van een Spookfiledienst met name zinvol is wanneer er wordt toegewerkt naar: -

een grote onafhankelijkheid van de Spookfiledienst van de onderliggende technische ICT infrastructuur; een situatie waarin de Spookfiledienst opgebouwd is uit verschillende subdiensten die functioneel zoveel mogelijk onafhankelijk2 zijn; een situatie waarin de Spookfiledienst door verschillende entiteiten (marktpartijen en/of overheden) wordt aangeboden.

Bovenstaande drie kenmerken passen bij een horizontale markt. In een horizontale markt zijn er verschillende aanbieders die elk een onderdeel leveren van de dienst. De totale dienst (of waardeketen) wordt dus modulair opgebouwd uit de diensten van diverse marktpartijen die actief zijn op verschillende schakels (Figuur 1). In een verticale markt zijn er verschillende aanbieders die ieder één totale dienst leveren (Figuur 2).

1

denk ook aan de transitiepaden verkeersmanagement [4.] 'loosely coupled', zie voor een compleet begrip literatuur op het gebied bijvoorbeeld van Internet web services, SOA, etc... 2


blz 9

Content

Services

Vertical market x

Vertical market …

Vertical market 2

Vertical market 1

Service provisioning

Figuur 2: verticale markt

Service aggregation Backbone Network Access

Wifi access

Cellular access

Figuur 1: horizontale markt

Voor de spookfiles is het streven om het ontstaan van een 'horizontale markt' te faciliteren. Er wordt dan ook toegewerkt naar een project waarin op elk van de verschillende schakels meerdere partijen actief zijn (in concurrentie) en de totaaloplossing is opgebouwd uit tenminste drie schakels. Om die reden zijn er binnen de PCP procedure drie percelen benoemd. Per perceel zijn er meerdere marktpartijen actief. De percelen zijn: 1. data-inwinning, verrijking en levering; 2. verdere verrijking van de data en vervolgens afleiding van het (verkeerskundig verantwoorde) advies uit deze data en het op gepaste wijze aanbieden van dit advies aan de weggebruiker. Het kunnen sturen van dit advies door gebruik van bestaande 2,5G-4G of broadcast telecommunicatietechnieken te maken valt ook binnen dit perceel; 3. leveren van telecommunicatiecapaciteit op basis van coöperatieve wegkantstations. Omdat de coöperatieve aanpak het tevens mogelijk maakt om lokaal grote hoeveelheden data met een hoge snelheid (en dus actueel) te verwerken, wordt binnen de derde schakel tevens een hosting functionaliteit aangeboden waarmee partijen een toepassing lokaal op een coöperatief wegkantstation kunnen uitvoeren. Een uitgebreidere beschrijving van de verschillende functionaliteiten waarlangs de Spookfiledienst wordt opgebouwd is te vinden in het hoofdstuk 3.


blz 10

2 De Spookfile nader gedefinieerd 2.1 Introductie op het fenomeen van (spook)files De hoeveelheid verkeer die per tijdseenheid over een weg kan rijden, de intensiteit, is afhankelijk van de snelheid die kan worden gerealiseerd door de voertuigen. Als er weinig verkeer is zal een hogere snelheid leiden tot een grotere intensiteit. Bij een toenemende hoeveelheid verkeer zal de intensiteit op een gegeven moment afnemen omdat de voertuigen een veilige onderlinge afstand moeten aanhouden; deze veilige afstand neemt toe met de snelheid van de voertuigen. Als de hoeveelheid verkeer verder toeneemt, zal op een gegeven moment de onderlinge afstand zo onveilig klein worden dat het verkeer snelheid gaat minderen. De intensiteit neemt hierdoor af en de hoeveelheid verkeer zal verder toenemen. Door de grotere hoeveelheid verkeer zal de snelheid weer omlaag gaan, enzovoorts . Uiteindelijk ontstaat er zo een file. Nu blijkt dat de hoeveelheid verkeer niet de enige oorzaak is van afnemende snelheid. Zo zijn er bijvoorbeeld ook verstoringen in de snelheid te zien bij bochten, het tijdelijk wegvallen van de vluchtstrook, invoegende voertuigen of van rijstrook wisselende voertuigen. Deze verstoring in de snelheid verplaatst zich als een rimpel stroomopwaarts door het verkeer. Als er weinig verkeer is hebben de bestuurders voldoende onderlinge afstand om het tijdelijke snelheidsverschil op te vangen en zal deze rimpel na enige tijd uitdoven. Wanneer het echter druk is en de onderlinge afstanden klein, dan kan de rimpel van een snelheidsverstoring lokaal tot een bottleneck leiden waarvan het effect zich tegen de verkeersstroom in uit kan breiden. Ondanks dat de maximale capaciteit van de weg nog volledig benut is ontstaat er dan toch een file: een spookfile. Spookfiles kunnen spontaan ontstaan als gevolg van een verstoring in de snelheid (zie hierboven), maar kunnen ook voortkomen uit de filegolven die het gevolg zijn van verkeer dat tegen infrastructurele files oploopt (zijnde files als gevolg van beperkingen in beschikbare wegcapaciteit). In die zin kunnen spookfiles het ontstaan van infrastructurele files bespoedigen en de ernst ervan vergroten[2].

2.2 Definitie Spookfile Deze korte introductie leert ons dat een file een verkeerstoestand is op het wegennetwerk die gekarakteriseerd wordt door een lage snelheid, hoge verkeersdichtheid en een suboptimale intensiteit. In files is het rijgedrag van voorliggers in sterke mate bepalend voor het rijgedrag van achteropkomend verkeer. Dit betekent dat bij het achteropkomende verkeer vaak dezelfde ongunstige omstandigheden ontstaan als bij het voorliggende verkeer, waardoor ook daar een file ontstaat. De files zijn onderdeel van complexe gedragingen waarbij verschillende voertuigen interageren binnen een verkeersstroom. Verkeer op autosnelwegen wordt gekenmerkt door reguliere (en dus voorziene) en niet-reguliere verstoringen. In onderstaande analyse wordt een globaal overzicht gegeven van mogelijke verstoringen. Verstoringen kunnen leiden tot een verstoorde balans tussen de verkeersvraag en het aanbod aan wegcapaciteit, hetgeen leidt tot files [1].


blz 11

Wegverkeer

Fenomeen

Balans

verkeersvraag

Balans vrij stromend verkeer

aanbod aan wegcapaciteit

grote verkeersvraag gedurende spitsperioden

Frequente verstoringen

normale, maximum beschikbare wegcapaciteit

Spookfiles

Verstoorde balans

congestie

pieken in verkeersvraag gedurende afgebakende periode

beperkingen in beschikbare wegcapaciteit

Niet frequente verstoringen vakantiepiek evenementen

geplande beperkingen

onderhoud wegvak(ken) / tunnel / brug Variërende voorspelbaarheid verstoringen Figuur 3: overzicht

acties

niet geplande beperkingen

ongevallen / incidenten

brug‘openingen’ slechte weersomstandigheden

met verstoringen in verkeer

Binnen dit schema onderscheiden we twee oorzaken van files [5.]: -

-

Een file door een bottleneck. Bij de meeste files ontstaan door het ontbreken van evenwicht tussen de verkeersvraag (het aantal voertuigen dat een locatie wil passeren) en het verkeersaanbod (de capaciteit van een weg). Dit kan zowel veroorzaakt worden door een tijdelijk verhoogde verkeersvraag (bv. meer verkeer tijdens de spits,...) als door een lokaal verminderd verkeersaanbod (bv. wegversmalling, tijdelijke impact van een ongeval, structuur van het wegennetwerk, weersomstandigheden,...). We spreken dan van een file die door een bottleneck wordt veroorzaakt. Een spookfile Een tweede oorzaak van files hangt nauw samen met de instabiliteit van een verkeersstroom met een hoge intensiteit. Een kleine lokale verstoring is dan vaak voldoende om een file te doen ontstaan. Meestal is de verstoring gerelateerd aan het gedrag van een individuele bestuurder (bv. het wisselen van rijstrook, te bruusk remmen, gedrag tijdens het inhalen of invoegen, ...). Andere bestuurders reageren vaak op dit gedrag door af te remmen en initiëren zo een file. Doordat een waarnemer in dergelijke gevallen niet in staat is om een expliciete oorzaak aan te wijzen, werd de term spookfile geïntroduceerd. Omdat spookfiles niet ontstaan door een bottleneck, kunnen voertuigen gemakkelijk wegrijden uit de kop van de file. De kop van de file verplaatst zich hierdoor tegen de richting van het verkeer in (stroomopwaarts). De file groeit ondertussen aan de achterkant aan, waardoor ook de achterkant van de file zich tegen de richting van het verkeer in beweegt (bron [Leidraad SpookfilesA58]). De file verplaatst zich hierdoor als een schokgolf door het netwerk. Naast de term spookfile worden in de literatuur worden ook termen als ‘spontane file’, ‘bewegende file’ of ‘start-stop file’ gebruikt om een dergelijke type file aan te duiden.


blz 12

Bij het vaststellen van een eenduidige definitie van het begrip spookfile voor het project Spookfiles A58 is het begrip vanuit drie verschillende perspectieven middels een kwantitatieve afbakening en meetbare indicatoren gedefinieerd. Hierbij zijn de volgende drie perspectieven meegenomen: Vanuit weggebruiker perspectief : Een autobestuurder ervaart een spookfile wanneer hij bruusk moet remmen en, na een korte periode van stilstaand tot langzaam rijdend verkeer, weer vlot kan door kan rijden op hoge snelheid. Vanuit het perspectief van de weggebruiker is er geen heldere oorzaak aan te wijzen voor de filegolf die hij doorkruist heeft. Dit leidt tot volgend nodig criterium voor een spookfile:  

De snelheid van een weggebruiker daalt tot minder dan 60 km/u voor een afstand van maximaal 2 kilometer; De snelheid is na het doorkruizen van de filegolf hoger dan 60 km/u.

Vanuit wegkant perspectief: Een waarnemer op een vaste locatie bekijkt een spookfile als een tijdelijke vertraging van het verkeer. Dit leidt tot volgend nodig criterium voor een spookfile :  

De snelheid van het verkeer daalt voor een waarnemer op een vaste locatie tot minder dan 60 km/u voor een periode van niet langer dan 10 minuten; De snelheid na deze periode is hoger dan 60 km/u.

Vanuit een tijd – ruimte perspectief: Bij het weergeven van de gemeten verkeerssnelheid in een tijd-weg diagram kan een spookfile herkend worden door de afgelijnde golven met traag verkeer die zich tegen de rijrichting in voort planten. Daarnaast zijn in dergelijk diagram ook het voertuigen wegkant perspectief terug te vinden. Deze combinatie leidt tot de volgende criteria voor het definiëren van een spookfile:   

Een afgebakende zone van traag verkeer (trager dan 60 km/u) die zich voorplant met een snelheid tussen de 15 en 20 km/u tegen de rijrichting van het verkeer in (stroomopwaarts); De afgebakende zone van traag verkeer heeft op een vast tijdstip een lengte van maximaal 2 kilometer; De afgebakende zone van traag verkeer heeft op een vaste plaats een duurtijd van maximaal 10 minuten.

Op deze manier wordt een spookfile eenduidig gedefinieerd en kan op basis van waarnemingen de interpretatie gemaakt worden om spookfiles te identificeren.


blz 13

3 Concept van de Spookfiledienst 3.1 Inleiding op een Spookfiledienst Hieronder wordt een conceptbeschrijving gegeven van de Spookfiledienst. Eerst wordt hiertoe beschreven wat de meest belangrijke functies zijn. Vervolgens wordt er een vergelijking gemaakt met bestaande diensten die sterk lijken op de Spookfiledienst. Hierbij wordt met name gekeken naar de punten die de Spookfiledienst onderscheiden van de bestaande diensten. Belangrijkste reden hiervoor is om te komen tot een Spookfiledienst die de sterke punten overeind houdt en de zwakke punten wegneemt. Daarnaast maakt deze focus het ontstaan van geheel nieuwe vormen van spookfile-voorkoming en spookfile-demping mogelijk dankzij nieuwe hardware, algoritmes, software en data. Dit biedt bovendien de mogelijkheid om deze nieuwe instrumenten, methoden en vormen individueel aan te bieden en in te passen in het voertuig. Zoals eerder beschreven kan hierbij gedacht worden aan het uitbreiding en personaliseren van adviezen en deze in-car te brengen, maar ook aan het zetten van stappen richting meer ‘gezamenlijk’ rijden en het gedeeltelijk overnemen van systemen (ADAS-aanpak). Met name deze laatste stap kan gezien worden als een tussenstap richting automatisch rijden (autonomous vehicles). Bij nieuwe diensten wordt gedacht aan diensten die expliciet worden opgebouwd vanuit het voertuig (de mobiele gebruikers van de statische infrastructuur). Deze diensten dienen de mogelijkheden die hierbij ontstaan ten aanzien van hardware, software, en data te exploiteren. De hierboven genoemde 'verschillen met de status quo' worden hieronder beschreven en in de context geplaatst van de visie van de marktpartijen op het toekomstige landschap van verkeersinformatie, rijtaakondersteuning, en verkeersmanagement. De evolutie waarmee verticale systeemzuilen in de markt zich ontwikkelen tot diensten in een horizontale markt is hierin een belangrijk onderdeel dat mede bepalend zal zijn voor de wijze waarop huidige, traditionele, spookfile-remmende maatregelen gehandhaafd zullen worden. Het is dan ook belangrijk om expliciet de sterke en zwakke punten van de huidige maatregelen te beschouwen zodat een goed beeld ontstaat van de functionaliteiten en karakteristieken die behouden zouden moeten worden, alsmede van de functionaliteiten en karakteristieken die verbeterd zouden kunnen worden. Naast het inzichtelijk maken van de voordelen van de nieuwe aanpak ten opzichte van de huidige aanpak wordt het door deze expliciete afweging van sterke- en zwakke punten bovendien mogelijk om bewuste keuzes te maken in relatie tot mee te nemen functionaliteiten en karakteristieken en eventuele omissies te ondervangen.

3.2 Generieke beschrijving Spookfiledienst De Spookfiledienst geeft in-car advies aan de weggebruiker (in het voertuig). Op basis van dit advies kan de weggebruiker zijn snelheid en positionering ten opzichte van andere voertuigen in het wegvak aanpassen. Doel hiervan is om het ontstaan van een spookfile te voorkomen of om een bestaande spookfile te dempen. Om goede in-car adviezen aan te kunnen bieden, moet er veel gebeuren. Zo moet verkeersdata ingewonnen en beschikbaar gemaakt worden en moet er uit deze data een advies worden afgeleid dat op geschikte wijze in het voertuig aangeboden kan worden. Dit betekent dat er dus ook een telecommunicatiedienst geleverd moet worden en dat er een platform nodig is in het voertuig waarop het advies ‘ontvangen’ kan worden.


blz 14

3.3 Beschrijving op basis van een vergelijking met bestaande diensten De Spookfiledienst is een dienst die we vandaag de dag nog niet kennen maar wel eigenschappen heeft die we kennen vanuit bestaande ITS diensten. Spookfiledienst als verkeersinformatiedienst De Spookfile dienst is in zekere zin een verkeersinformatiedienst. Een verkeersinformatiedienst levert op basis van kennis van het verkeer informatie over de verwachte reistijd, route of zelfs het naderen van een filestaart3. Bestaande informatiediensten leveren echter geen advies dat gericht is op het voorkomen of beperken van files. Hiervoor is een ontwikkeling nodig in dit project. Dit moet leiden tot: 1. Advies dat op strategisch niveau (verder vooruit in de tijd en beperkte granulariteit) tot rijgedrag leidt waarbij de kans op het ontstaan van spookfiles afneemt zonder dat de collectieve doorstroming afneemt. Dit advies vraagt innovatie op het vlak van datafusie en verkeerskundige logica. De verwachting is dat met name de aangroei van spookfiles kan worden tegengegaan. Naar verwachting kan dit advies via het 'connected'4 spoor worden gerealiseerd; 2. Advies dat inspeelt op actuele, lokale ontwikkelingen in het verkeer en dat rijtaken op tactisch niveau kan ondersteunen. Dit vraagt om zeer actuele data met hoge granulariteit. Om dit te verkrijgen zijn ontwikkelingen nodig op het vlak van zowel data-inwinning als dataverwerking en in de afleiding tot de verkeerskundige inzichten. Verwachting is dat met 'connected technologie'4 de kans op het ontstaan van spookfiles kan worden verkleind, maar dat op het moment dat de spookfile toch dreigt te ontstaan ‘connected technologie’ alleen niet voldoende zal zijn en er ‘coöperatieve technologie’5 ingezet zal moeten worden voor effectieve oplossingen; Spookfiledienst als rijtaak ondersteunende dienst (ADAS) Ook zijn er diensten die in het voertuig van de weggebruiker rijtaak ondersteunende informatie leveren (zoals adaptive cruise control, lane departure warning system, ...). De Spookfiledienst lijkt in zeker opzicht op Advanced Driver Assistance Services (ADAS). Fundamenteel verschil is echter het coöperatieve karakter van de Spookfiledienst. Daar waar ADAS gebruik maakt van informatie die door het voertuig zelf verzameld wordt (en dus in hoge mate onafhankelijk is van de intelligentie van andere voertuigen en/of die van de wegkant), maakt de Spookfiledienst gebruik van informatie en intelligentie die mede aangeleverd wordt vanuit andere voertuigen en/of de wegkant. Dit betekent dat er data en informatie uitgewisseld moet worden tussen de onderliggende diensten (die naar alle waarschijnlijkheid door verschillende operatoren worden beheerd). Hiertoe moeten niet alleen de verschillende koppelvlakken op technisch inhoudelijk niveau worden gespecificeerd en geïmplementeerd, maar moeten ook procedurele en contractuele (wie doet wat wanneer, wie is waar verantwoordelijk voor, wie is eigenaar van welke data, ...) afspraken worden gemaakt.

3

Jam Ahead Alert gebruikmakend van 2,5G-4G eventueel in combinatie met DAB, zie leidraad [6.] 5 technologie gebruikmakend van Wifi-P 802.11p waarmee voertuigen onderling en met de wegkant kunnen communiceren 4


blz 15

Spookfiledienst als verkeersmanagementdienst De waarde die een Spookfiledienst creëert komt grotendeels ten goede aan het collectief: verbeterde mobiliteit, verkeersveiligheid en duurzaamheid. De Spookfiledienst kan hiermee een bijdrage leveren aan de invulling van de wettelijke taken van de publieke wegbeheerder en kan daardoor worden gezien als een verkeersmanagementdienst. Vanuit dit oogpunt dient de Spookfiledienst dus te voldoen aan de eisen en behoeften die de verkeersmanager stelt of zal stellen aan een dergelijke dienst. Hieronder volgt een (niet-beperkend) overzicht van functies die een Spookfiledienst, gezien als verkeersmanagementdienst, kan omvatten: -

-

-

Advies zoals het MTM systeem. Bij het ontstaan van files helpt de ‘automatische incident detectie’ (AID) bij de filestaartbeveiliging en daarmee bij het temperen van de filegolven die ontstaan in de staart van de file. AID is een standaard functie van het ‘Motorway Traffic Management’ (MTM) systeem; Dynamax. Bij het ontstaan van file helpt het systeem van dynamische maximumsnelheden (DynaMax) bij het temperen van de filegolven die ontstaan in de staart van de file. Dynamax is als additionele functionaliteit later toegevoegd aan de MTM; Toeritdosering. Bij opritten kan toeritdosering worden toegepast om het aantal voertuigen dat op een verzadigde hoofdrijbaan in wil voegen te doseren [2].

Wat alle bestaande verkeersmanagementdiensten gemeen hebben, maar geen onderdeel is van de Spookfiledienst, is de centrale 'controle' die de verantwoordelijk wegbeheerder kan uitoefenen op de kwaliteit en beschikbaarheid van de dienst. Om de eindverantwoordelijkheid voor het verkeerskundig effect van de spookfiledienst goed vast te leggen dienen, in een horizontaal functionerende markt, de procedures, verplichtingen en aansprakelijkheden goed op elkaar afgestemd te worden. Dit maakt innovatie noodzakelijk. filestaartbeveiliging via AID

DynaMax

toeritdosering

rijrichting verkeer

Figuur 4. Tegengaan en dempen filegolven met verkeersmanagement maatregelen in de huidige situatie

Een tweede belangrijk verschil, gerelateerd aan het eerste, is dat er traditioneel gezien maar één partij verantwoordelijk is voor het uitvoeren van de DVM6 maatregelen en/of het verstrekken van informatie aan de weggebruiker. Er is dus per definitie geen sprake van verschil in inzicht tussen de verschillende uitvoerders in wat het meest wenselijke verkeersmanagementadvies is (of

6

Dynamisch VerkeersManagement


blz 16

verkeersmanagementmaatregel)7. Één van de doelen van de Spookfiledienst PCP-procedure is het tot stand laten komen van een competitieve markt. In deze markt zijn idealiter twee of meer service providers actief die verschillende adviezen presenteren (in het voertuig) aan de weggebruiker op dezelfde locatie. Dit betekent dat, afhankelijk van de wijze waarop en de mate waarin de wegbeheerder in de toekomst private partijen toestaat (of zelfs inschakelt) om verkeersmanagement gerelateerde informatie aan de weggebruiker aan te bieden, hier dus misschien ook innovatie nodig is om de verschillende adviezen (die dermate van elkaar kunnen verschillen dat het beoogde effect en/of de verkeersveiligheid in het geding is) te kunnen 'harmoniseren'. Innovaties zouden in dit geval nodig zijn op zowel het procedurele vlak (regulering vanuit RWS) als op technisch-inhoudelijke vlak (het mogelijk maken dat adviezen kunnen worden vergeleken). De noodzaak en mogelijkheden hiertoe hangen nauw samen met de technische oplossingen die worden gerealiseerd, de ontwikkeling van een markt voor Spookfilediensten, de ontwikkelingen op het gebied van wetgeving en de ontwikkelingen in de automotive sector en in-car information services die buiten de controle van de directe stakeholders van dit project vallen (zie ook paragraaf 5.3 en 5.4). Een derde belangrijke verschil is de afhankelijkheid van de bestaande weginfrastructuur. Bestaande verkeersmanagementdiensten langs de snelweg maken gebruik van data die met behulp van lussen in het wegdek wordt verzameld. De Spookfiledienst dient onafhankelijk van deze data te kunnen functioneren. Er is dus innovatie nodig op het vlak van de data-inwinning waardoor de Spookfiledienst onafhankelijk wordt van lussen in het wegdek. De wijze waarop deze innovaties in de praktijk kunnen worden toegepast is afhankelijk van de hoeveelheid voertuigen die connected of coöperatief zijn. Een transitiemodel in de eerste jaren lijkt daardoor onvermijdelijk. Andere punten van de huidige verkeersmanagementmaatregelen die relatief sterk zijn in vergelijking met de Spookfiledienst zijn: 

 

Specifiek voor MTM: - landelijke uniformiteit en daarmee herkenbaarheid en begrijpbaarheid voor voertuigbestuurders; - continue monitoring van voertuigintensiteiten en snelheden op de hoofdrijbaan van de autosnelweg via dubbele sets van inductielussen; - beproefd systeem, dat over de afgelopen 3 tot 4 decennia de verkeersveiligheid en doorstroming op de uitgeruste autosnelwegen heeft gediend; Specifiek voor TDI’s: - dwingende maatregel (zeker met een flitspaal ernaast); Voor zowel MTM als TDI’s: - eenduidige communicatie met behulp van lichtsignalen, die door alle passerende voertuigbestuurders kunnen worden “gelezen en geïnterpreteerd”.

7

Overigens kunnen dergelijke verschillen wel weer optreden bij verdere professionalisering van verkeersmanagement waarbij op netwerkniveau maatregelen wenselijk zijn die op locaal niveau uitgevoerd worden en een impact hebben. In dat geval zullen centrale en locale wegbeheerders e.e.a dienen te coördineren. Nog is dit een andere uitdaging dan die er ligt in het geval van afstemming tussen verschillende private partijen die in concurrentie zijn met de wegbeheerder.


blz 17

Andere punten die relatief zwak zijn van de huidige verkeersmanagementmaatregelen in vergelijking met de Spookfiledienst zijn voor zowel MTM als TDI’s: 







Er is weinig ruimte voor doorontwikkeling: - het betreffen maatregelen van de wegbeheerder die organisatorisch zijn ingebed in de organisatie8; - de communicatiemogelijkheden met de weggebruiker beperkt zijn doordat er via vaste lichtsignalen wordt gecommuniceerd. Er is geen landelijke dekking: - het betreffen relatief dure maatregelen voor de wegbeheerder omdat hij de enige afnemer van de desbetreffende systemen is; - door het ontbreken van zowel MTM als TDI op een aantal locaties in het Nederlandse snelwegennet helpen dergelijk systemen niet altijd bij het doen afnemen of voorkomen van files. Maatregelen zijn vanuit de weg (de statische infrastructuur) opgebouwd en niet vanuit het voertuig (de mobiele gebruiker van de statische infrastructuur): - de adviezen en waarschuwingen zijn slechts korte tijd zichtbaar voor passerende weggebruikers. Langdurige zichtbaarheid vraagt om redundantie in actuatoren; - metingen van het aantal voertuigpassages worden gedaan op specifieke locaties in het netwerk (punten). Gedrag van voertuigen op een traject vraagt om redundantie in sensoren. De maatregelen zijn beperkt in scope: - de maatregelen zijn gebaseerd op specifieke en beperkte soorten data (met name lusdata), terwijl er (inmiddels) ook veel andere soorten data denkbaar en beschikbaar zijn (bijvoorbeeld Floating Car Data). Sommige van deze andere soorten data hebben mogelijkerwijs een (veel) hogere resolutie, een lagere latency en zouden relatief gemakkelijk op grote schaal beschikbaar kunnen worden gemaakt. Opgemerkt dient te worden dat dit niet direct impliceert dat lusdata niet waardevol meer is en vervangen kan worden. Met name de intensiteiten-gegevens zijn nog niet zomaar door andere bronnen in te vullen. - de maatregelen zijn gebaseerd op specifieke en beperkte soorten hardware, terwijl er (inmiddels) ook veel andere soorten hardware denkbaar en beschikbaar zijn. Goede voorbeelden hiervan zijn nieuwe in-car systemen en in-car sensoren, aftermarket devices (zoals navigatiesystemen en smartphones), nieuwe wegkant-systemen, coöperatieve technologie, etc. Opnieuw geldt dat het niet persé onmogelijk of zelfs heel lastig is om bepaalde extra technologieën (bv. coöperatieve technologie) toe te voegen aan die bestaande wegkant-hardware. Het is echter wel onwaarschijnlijk dat de overheid dit binnen afzienbare tijd voor veel nieuwe, extra technologie gaat doen. - De maatregelen zijn meestal gebaseerd op specifieke methoden (soms handmatig) en (automatische) algoritmes, terwijl (inmiddels) veel meer verschillende methoden en algoritmes denkbaar en beschikbaar zijn. Hieronder vallen ook de methoden waarbij expliciet via draadloze technologie informatie naar het voertuig gaat en van het voertuig komt. Hierbij dient opgemerkt te worden dat sommige van die algoritmes heel goed compatible zijn met bestaande wegkant-apparatuur, dat hier zelfs mee geëxperimenteerd is, maar dat uitrol op grote schaal vanuit de overheid niet (makkelijk/snel) gebeurt. - De maatregelen zijn voornamelijk reactief (m.n. MTM/AID). Er worden vaak pas maatregelen getroffen (handmatig dan wel automatisch) als de file al is ontstaan in plaats van proactief maatregelen te treffen om de spookfile te voorkomen (bv. door het dempen

8

Eigenlijk staat dit los van de technische systemen zelf. De systemen kunnen zondermeer worden doorontwikkeld, alleen de organisatie van de wegbeheerder zal dit niet snel toestaan. In de praktijk is die ruimte tot doorontwikkeling er dus niet in grote mate


blz 18

van schokgolven en/of maatregelen te treffen die expliciet anticiperen op filevorming in de nabije toekomst). Er wordt hier bewust gesproken over voornamelijk reactief, omdat er wel degelijk proactieve experimenten zijn geweest met betrekking tot harmonisatie. Deze experimenten sloegen echter niet goed aan bij de weggebruikers. - de bestaande methoden maken vooral gebruik van collectieve, generieke informatie (d.w.z. informatie die voor iedereen hetzelfde is), in plaats van gepersonaliseerde informatie (d.w.z. informatie die afhankelijk is van de exacte positie, voertuigtype, route en voorkeuren van de weggebruiker). De laatste vorm van informatie is inmiddels al mogelijk. - De bestaande methoden die gaan uit van weggebruikers die individueel handelen zonder dat deze handelingen worden gecoördineerd. Dankzij nieuwe technieken wordt het in de toekomst wel mogelijk om dergelijke handelingen te coördineren en coöperatief te maken.

Spookfiledienst als traditionele telematicadienst Bestaande telematicadiensten zijn in het algemeen vormgegeven op basis van een sterk gecentraliseerde data-inwinning gevolgd door een informatieverwerking en vervolgens de distributie via een client-server model. Deze opzet is geschikt voor een dienst die resulteert in informatie van strategische waarde met niet al te grote geografische spatiering. De Spookfiledienst, in elk geval in de coöperatieve fase, onderscheidt zich hiervan doordat zij het (tevens) mogelijk maakt (wil maken) om lokaal zeer grote hoeveelheden data te verwerken en met zeer geringe vertraging een advies te leveren dat is geoptimaliseerd voor een klein gebied (dus grote geografische spatiering). Hiervoor zijn belangrijke innovaties nodig waarmee data sneller beschikbaar komt , op een verkeerskundig fundamenteel andere wijze tot adviezen wordt verwerkt, en met geringe vertraging op de juiste plek aangeboden wordt. De verwachting is dat hierdoor enerzijds effectiever advies mogelijk is en dat zelfs het ontstaan van spookfiles kan worden tegengegaan; anderzijds is de verwachting dat het hiertoe noodzakelijk is lokaal (langs de weg in combinatie met in het voertuig) data in te winnen en de adviezen af te leiden.


blz 19

4 Toekomstvisie Het uiteindelijk doel van de Spookfiledienst is filevorming te voorkomen. Daartoe is het belangrijk de oorzaak van files weg te nemen. Een belangrijke oorzaak van filevorming is het suboptimaal menselijk gedrag van bestuurders bij de collectieve regeling van druk verkeer. Het wegnemen van deze oorzaak vraagt om een regelsysteem waar de bestuurder geen actief deel meer van uitmaakt. Dit is de stip op de horizon van coöperatief rijden. De weg er naar toe is een lange, stapsgewijze weg gericht op de lange termijn. In de tussentijd gaat het erom bestuurders te adviseren hun rijgedrag zodanig aan te passen dat het effect van automatisch rijdend verkeer zo goed mogelijk benaderd wordt. De automotive industrie De internationale automotive industrie heeft het doel van automatisch rijden omarmd. Alle toonaangevende merken claimen de technologie voor autonoom rijden inmiddels in huis te hebben en presenteren deelfuncties hiervan in hun nieuwe modellen ("Noch in dieser Dekade werden wir in einem Mercedes autonom fahren können"/ Prof. Dr. Thomas Weber, Daimler-Vorstand für Konzernforschung). Goede voorbeelden hiervan zijn: zelfstandig parkeren, filerijden, rijstrookhouden, platooning en het ontwijken van obstakels, inclusief rijbaanwissel. De doelstelling van de industrie is om allereerst de veiligheid te vergroten. Ook bij botsingen is de mens vaak de hoofdoorzaak (onoplettendheid). De automotive industrie werkt ook hard aan ICT technologie en standaarden voor Car2X communicatie die deze ontwikkelingen ondersteunen. Doel van de automotive industrie met autonoom rijden is 1) de veiligheid te vergroten, 2) het comfort van de inzittenden te verhogen en 3) emissies te verlagen. Het publiek De sterk gestegen publiciteit rondom dit onderwerp, mede door Google, heeft ook het publiek aan het denken gezet. Recent onderzoek in Duitsland (Continental Mobilitätsstudie 2013) geeft aan dat nu al meer dan de helft van de autorijders aangeeft te accepteren dat de auto de rijtaak (soms) overneemt. Het vertrouwen in de techniek is groot, iedereen vindt veiligheid belangrijk en filerijden vindt niemand leuk. Het publiek accepteert dat de auto rijfuncties overneemt, waar en wanneer dat nodig is.

veiligheid 0 emissie 0

doorstroming 0 comfort 0


blz 20

Autonoom rijden komt er aan. De ontwikkeling ervan wordt gedreven door de automotive industrie en heeft een eigen dynamiek. Deze dynamiek heeft een belangrijke synergie heeft met de ontwikkeling van Coöperatieve VM systemen. Coöperatieve VM systemen gebruiken dezelfde onboard systemen en ICT technologie, maar met een aanvullende, collectieve toepassing: verbetering van de verkeersdoorstroming, met een positief effect op de verkeersveiligheid, comfort en emissies. De toekomst van coöperatief rijden ligt ook in autonoom rijden. Dit geeft richting aan de roadmap voor de komende 15+ jaar. Tot die tijd is het de uitdaging om het verkeerssysteem met menselijke bestuurders steeds beter te laten lijken op een collectief geregeld verkeerssysteem met autonoom rijdende auto's.

Roadmap In de roadmap naar automatisch rijden zijn globaal drie, deels parallel lopende stappen te onderscheiden. Automotive industrie Spookfiles

Connected

Cooperative

Automated, partially

Automated, full

Connected Rijgedragadvies met betrekking tot snelheid, eventueel aangevuld met advies gericht op volgafstand en/of rijstrook. De infrastructuur-voertuigcommunicatie (I2V) heeft een actualiteit van circa 3-5 minuten. Momenteel is deze communicatie gebaseerd op cellulaire xG communicatie technologie en broadcast communicatie technologie . De auto neemt actief bepaalde rijfuncties over zoals afstand houden, remmen en doet dat alleen onder bepaalde omstandigheden (bv. bij botsingsrisico, kans op filevorming of filerijden). Hierbij worden afhankelijkheden van intelligentie bij andere auto's en/of de wegkant of de aanwezigheid van specifieke communicatietechnologie vermeden. Coöperatief Rijgedragadvies als bij Connected, maar met een actualiteit van enkele seconden, zowel V2V als I2V. Wordt ontwikkeld op basis van Wifi-P technologie. Volledig gebaseerd op rijgedragadvies; alle rijfuncties worden uitgevoerd door de bestuurder. De auto neemt actief bepaalde rijfuncties over, zoals afstand houden, remmen en doet dat ook alleen in bepaalde omstandigheden; botsingsrisico, kans op filevorming, filerijden. Hierbij communiceren auto's met elkaar en met de infrastructuur. (CACC-LDWA+ en vervolgontwikkelingen) Autonomous car, automated driving De auto neemt onder bepaalde omstandigheden alle rijfuncties volledig over. Implementatie hiervan gebeurt 'gefaseerd'. In eerste instantie zal de auto bijvoorbeeld alleen alle rijfuncties overnemen indien hier een aanleiding toe is (bv. vanwege de veiligheid, om de doorstroming te bevorderen of om files te voorkomen). Daarnaast zal de auto in eerste instantie ook alleen de rijfuncties overnemen


blz 21

indien dit technische beheersbaar is (bv. eerst alleen op de snelweg met stapsgewijze ontwikkeling naar complexere situaties (Platooning - Sartre - Google en vervolgontwikkelingen).

Randvoorwaarden Doorstroomapplicaties op basis van coöperatieve systemen hebben per definitie een collectief karakter en zijn daarmee afhankelijk van opschaling om voldoende effect te sorteren (marktpenetratie). In dit kader is het belangrijk hier de randvoorwaarden te benoemen die essentieel zijn voor de realisatie van coöperatieve systemen in Nederland en die wij, vanuit de Nederlandse situatie, eventueel kunnen sturen en beïnvloeden. Internationale harmonisatie De ontwikkeling van internationale harmonisatie met betrekking tot systeemarchitectuur en communicatieprotocollen is binnen de automotive en verkeersindustrie volop gaande. Vanuit het Nederlandse programma kunnen we daaraan bijdragen door voorwaarden in te brengen voor collectieve verkeersregeling en individueel gedragsadvies. Juridische basis De technische ontwikkeling van autonoom rijden gaat zeer snel. Voor de implementatie ervan ontbreekt echter een wettelijk en juridische basis. De ontwikkeling van EU-wetgeving heeft een lange doorlooptijd. Om te voorkomen dat dit over 15 jaar een remmende factor op de ontwikkeling zal zijn is het voor de lange termijn belang hier initiatieven in te nemen. Verkeersregelsysteem Bij de met systemen voor automatisch rijden uitgeruste auto's hoort de ontwikkeling van een overkoepelend dynamisch verkeersmanagementsysteem dat actief het verkeer regelt daar waar voertuigen dit onderling niet kunnen.

5 Afgeleide uitgangspunten 5.1 Spookfiledienst onderdeel van marktconform ecosysteem 5.1.1 Horizontalisering Zoals in het inleidende hoofdstuk staat beschreven (Achtergrond en doel Spookfiles A58 project en oplossing) is de algemene verwachting dat de Spookfiledienst slechts één van de toepassingen zal zijn die gebruik maakt van de onderliggende 'ICT' infrastructuur. Er zullen dus hoogstwaarschijnlijk geen 'kastjes' in auto's worden geïnstalleerd alleen met het doel de Spookfiledienst te ontvangen. Ook zullen er hoogstwaarschijnlijk geen coöperatieve wegkantstations worden uitgerold met als enige doel om Spookfiledienst 'berichten' te versturen en zullen er geen data-inwin en verrijkingsprocessen worden geïmplementeerd exclusief voor de afleiding van een goed advies in de Spookfiledienst. Dit betekent dat de Spookfiledienst als het ware onderdeel uit gaat maken van een 'eco systeem' van andere diensten en ICT infrastructuur. Een dergelijk ecosysteem is alleen mogelijk indien de bestaande “verticale” systeemzuilen worden vervangen door “horizontale” lagen van elkaar


blz 22

ondersteunende diensten. Dit is geïllustreerd in Figuur 5. Hierbij dient opgemerkt te worden dat Figuur 5 vooral dient om het principe van een horizontale markt te illustreren, niet om nu al specifieke keuzes te maken met betrekking tot de wijze waarop dat precies zal moeten gebeuren9.

Adviseren en waarschuwen van voertuigbestuurders

Adviseren en waarschuwen van voertuigbestuurders

Opstellen van adviezen en waarschuwingen

Opstellen van adviezen en waarschuwingen

Bewerken tot informatie

Bewerken tot informatie

Verzamelen van meetgegevens

Verzamelen van meetgegevens

Meten van gegevens

Meten van gegevens

Weggebruikersdienst

Informatiedienst

Voertuig – weg interactie dienst

Figuur 5: Van “verticale” systeemzuilen naar “horizontale” lagen van elkaar ondersteunende diensten

Het grote voordeel van horizontalisering10 is dat iedere laag zichzelf door kan ontwikkelen, waardoor er ruimte ontstaat om diensten aan te passen en nieuwe diensten te introduceren. Voor het Figuur 5 zou dat er als volgt kunnen uitzien:   

nieuwe weggebruikersdiensten: aanbieden van betere of nieuwe diensten aan weggebruikers, naast de spookfiledienst (voorkomen van filegolven, waarschuwen voor filegolven en dempen van filegolven); nieuwe informatiediensten: mogelijk maken van betere of nieuwe diensten voor weggebruikers door nieuwe soorten meetgegevens te verzamelen en nieuwe of betere informatie te produceren; nieuwe voertuig – weg interactie: bij het meten van gegevens en tonen van adviezen en waarschuwingen zijn het voertuig en de weg gescheiden werelden. Door beide werelden te koppelen ontstaan nieuwe mogelijkheden voor de innovatie in informatiediensten en daarmee weggebruikersdiensten.

9

Met de koppelvlak-specificaties in de bijlagen borgen de marktpartijen dat in het Spookfiles A58 wordt gewerkt aan de juiste randvoorwaarden voor het ontstaan van een horizontale markt. Met deze specificaties worden ook concrete en gedetailleerde keuzes gemaakt met betrekking tot welke functionaliteit zich in iedere horizontale laag (in het project 'percelen' genoemd) bevindt. Deze keuzes gaan verder dan noodzakelijk om een horizontale markt te faciliteren. Zij reflecteren dan ook niet noodzakelijkerwijs de verwachting van de marktpartijen van hoe de markt er in de toekomst uit zal zien, maar zijn gemaakt om gedurende het Spookfiles A58 project de 'totaalwerking' te kunnen garanderen. 10 Let op dat het concept wordt besproken en niet de exacte definitie van grenzen tussen de horizontale lagen


blz 23

5.1.2

Borgen van de commerciële levensvatbaarheid van een Spookfiledienst

Connected Spookfiledienst Aan het (huidige) ecosysteem waarin ITS diensten gebruik maken van de cellulaire netwerken (2,5G4G) of radio broadcast (RDS/TMC of DAB/TPEG) kan zonder meer een Spookfiledienst worden toegevoegd. Deze dienst zou zich kunnen richten op het dempen van filegolven en op het voorkomen dan wel beperken van de omvang, frequentie en duur van spookfiles. Een systeem dat waarschuwt voor files is vandaag de dag al beschikbaar in de vorm van een ‘traffic jam ahead alert’. De 'connected' Spookfiledienst gaat verder dan 'waarschuwen voor' en richt zich op het tegengaan van de filegolven. Door te informeren over, te waarschuwen voor en te adviseren rond de filegolven en deze informatie op de juiste wijze te presenteren moet de spookfiledienst spookfiles dempen en voorkomen. De directe waarde van een Spookfiledienst voor een individuele gebruiker zit in het comfort en de extra veiligheid die de dienst biedt. De collectieve meerwaarde zit in het voorkomen van filevorming (en daarmee het aantal voertuigverliesuren) en het verminderen van schadelijke emissies als gevolg van remmende en optrekkende voertuigen. Deze meerwaarde geldt voor het collectief en daarmee indirect voor het individu. Deze collectieve waarde is in de praktijk echter lastig te vertalen naar een business case voor private partijen. Wat is nodig om het connected ecosysteem mogelijk te maken? Om het ecosysteem voor de connected Spookfiledienst mogelijk te maken, is het van belang de extra kosten voor het 'spookfile' element laag te houden. Streven is om te zoeken naar een oplossing waarin:  het advies van de Spookfiledienst zoveel mogelijk onderdeel is van bestaande service modellen (verkeersinformatiedienst, navigatiedienst met real-time verkeersinformatie, VAS, LBS, ...);  de kosten voor de extra benodigde data zo beperkt mogelijk zijn (bijvoorbeeld doordat de data als onderdeel van de Spookfiledienst kan worden ingewonnen);  de Spookfiledienst zo onafhankelijk mogelijk is van het telematica platform waarop de service applicatie moet draaien en waarop het advies in het voertuig aan de weggebruiker aangeboden kan worden, opdat de kosten voor dit platform gedeeld kunnen worden met andere applicaties. Een dergelijk ecosysteem is noodzakelijk om opschaalbaarheid en continueerbaarheid (ten tijde van de commerciële fase die met dit project wordt nagestreefd) mogelijk te maken. Coöperatieve Spookfiledienst In het coöperatieve ecosysteem kan met de Spookfiledienst een andere waarde worden gecreëerd in het verlengde van de ‘day-one’ applicaties zoals gedefinieerd door de Automotive OEMs en de wegbeheerders. De ‘day-one’ applicaties bouwen voort op voertuig-bestuurder ondersteuningssystemen en zijn gericht op verkeersveiligheid. Met de Spookfiledienst kan daar het verbeteren van de doorstroming aan toe worden gevoegd. Een coöperatieve Spookfiledienst veroorzaakt hiermee een paradigma verschuiving van het dempen van filegolven en het voorkomen van spookfiles vanuit een centraal beeld van de verkeerstoestand (“informeren, sturen & geleiden”), naar het dempen van filegolven en het voorkomen van spookfiles vanuit voertuigen en wegkantsystemen die elkaar informeren en proactief op elkaar reageren. Met behulp van coöperatieve infrastructuur langs de weg en in voertuigen kan veel data snel lokaal worden verwerkt.


blz 24

Connected Spookfiledienst voorkomen en dempen van filegolven ontstaat vanuit een centraal beeld van de verkeerstoestand

Coöperatieve Spookfiledienst voorkomen en dempen van filegolven ontstaat uit voertuiginfrastructuur en voertuig-voertuig interactie.

Figuur 6. Coöperatieve Spookfiledienst komt met een paradigma verschuiving

Voor de individuele gebruiker ligt de meerwaarde van een Spookfiledienst in het verlengde van de systemen die rijtaakondersteunend zijn. Voor deze systemen is apart een business case op te stellen. Ook voor de coöperatieve Spookfiledienst geldt dat echte meerwaarde zit in de collectieve voordelen van de dienst (het voorkomen van filevorming en daarmee voertuigverliesuren en het verminderen van schadelijke emissies). Ook nu is de collectieve waarde in de praktijk lastig te vertalen naar een business case voor private partijen. De crux hierbij is dat de noodzakelijke investeringen om tot een coöperatief ecosysteem te komen hoger liggen dan voor een connected ecosysteem doordat de benodigde investeringen in een coöperatieve weg- en voertuigkant veel hoger liggen. Wat is nodig om het connected ecosysteem mogelijk te maken? Om het ecosysteem voor de connected Spookfiledienst mogelijk te maken, is het van belang de extra kosten voor het 'spookfile' element zeer laag te houden. Ook nu is het streven om te komen tot een oplossing, waarin de coöperatieve Spookfiledienst op een slimme wijze onderdeel uitmaakt van het ecosysteem. De Spookfiledienst dient hierbij zoveel mogelijk gebruik maakt van diensten, data en ICT infrastructuur die (ook) voor andere toepassingen worden ingezet. Dit streven vraagt additioneel om een coöperatieve wegkant die:  voorziet in een ‘facility’ laag, waarop zowel data-inwinners- en verstrekkers als service providers hun coöperatieve (service) applicaties kunnen plaatsen en executeren;  naast een G5 ‘control channel’ ook één of meerdere G5 ‘service channels’ biedt via welke service provider specifieke berichten kunnen versturen naar de eigen gebruikers. In het coöperatieve ecosysteem kan mogelijk met de Spookfiledienst significant meer waarde worden gecreëerd dan met de huidige diensten.

5.2 Spookfiledienst coöperatieve kanalen Om coöperatieve ITS toepassingen mogelijk te maken, is het noodzakelijk dat er snelle draadloze communicatietechnologie beschikbaar is waarmee voertuigen onderling en met de wegkantinfrastructuur kunnen communiceren.


blz 25

In 2008 besloot de Europese Commissie in haar strijd tegen verkeersongelukken en files om voor heel Europa een deel van het beschikbare bandbreedte exclusief te reserveren voor de coöperatieve ITS toepassingen die de verkeersveiligheid of de mobiliteit bevorderen. De wijze waarop toepassingen gebruik zullen kunnen maken van deze frequenties ligt nu vrijwel volledig vast in bestaande ETSI/CEN standaarden. Onderdeel van deze standaard is de specificatie van het coöperatieve wegkantstation, Roadside ITS Station (RIS). De RIS dient verschillende communicatie 'kanalen' ter beschikking te stellen waarmee een toepassing in een voertuig (Vehicle ITS Station, VIS) met een ander voertuig of met de wegkant RIS kan communiceren. Een eerste kanaaltype is het zogenaamde Control Channel (CCH). Het CCH is bedoeld om standaard coöperatieve berichten te versturen. Deze berichten dienen door alle coöperatieve eindstations ontvangen te kunnen worden en de algemene verkeersveiligheid en doorstroming te bevorderen. Het CCH zal dus niet worden gebruikt voor berichten die exclusief bij één ITS toepassing of bij één bepaalde ITS Service Provider horen. ETSI/CEN heeft een aantal berichten gestandaardiseerd die via het CCH verzonden kunnen worden. Binnen de geest van en de doelstelling achter de CCH is het mogelijk dat daar op termijn nieuwe standaard berichten aan toegevoegd zullen worden. Naast het Control Channel geeft de standaard de mogelijkheid om verscheidene Service Channels (SCH) beschikbaar te stellen. SCH maken het, in tegenstelling tot het CCH, wel mogelijk om dienstspecifieke informatie op coöperatieve wijze uit te wisselen. De wijze waarop coöperatieve wegkantstations in de toekomst uitgerold worden en het gebruik van het CCH en het SCH ondersteunen is een keuze die gebaseerd wordt op commerciële overwegingen en waarbij een inschatting van de wijze waarop de coöperatieve ITS markt zich gaat ontwikkelen van belang is. De consortia in het Spookfiles A58 project verwachten dat vanuit de automotive OEM industrie gevraagd zal worden om coöperatieve oplossingen in voertuigen zeker tijdens de eerste generatie producten zo goedkoop mogelijk te houden. Dit betekent dat wordt verwacht dat voertuigen die met een eerste generatie coöperatieve technologie door een OEM worden geproduceerd, worden uitgevoerd met 1-kanaals oplossingen (dus met ondersteuning voor een Control Channel CCH maar niet voor een Service Channel SCH). Tevens is de verwachting dat daarop volgende generaties van coöperatieve OEM technologie in voertuigen wel uitgevoerd zullen worden met meer-kanaals oplossingen en dat retro-fit oplossingen, afhankelijk van het aanbod van coöperatieve diensten waarvoor het hebben van een actief SCH noodzakelijk is, ook uitgevoerd zullen worden met meerdere kanalen. Hierbij is de veronderstelling dat het ontstaan en de ontwikkeling van een markt van coöperatieve diensten (en OEM en retro-fit coöperatieve technologie in het voertuig), baat heeft bij de beschikbaarheid van coöperatieve wegkantstations waarin niet alleen een Control Channel maar ook één of meerdere Service Channels actief zijn. De meerkosten voor een 2-kanaals wegkantstation ten opzichte van een 1-kanaals wegkantstation zijn laag en significant lager dan de kosten voor het upgraden van bestaande 1-kanaals wegkantstations naar 2-kanaals wegkantstations.


blz 26

In het Spookfiles A58 project zal daarom: 1. Iedere leverancier in Perceel 3 coöperatieve wegkantstations aanbieden / uitrollen die zijn uitgevoerd met tenminste 2 kanalen (CCH en één SCH); 2. Iedere leverancier in Perceel 2 vrije keus hebben om de coöperatieve technologie in het voertuig uit te voeren met één of met twee kanalen11 .

5.3 Spookfiledienst coöperatieve berichten Bij het aanbieden van een spookfile dienst door middel van coöperatieve berichten heeft een P2 leverancier de keuze uit twee fundamenteel verschillende mechanismes:  

een standaard bericht gebruiken dat via het Control Channel (CCH) verstuurd wordt of; een leverancier-specifiek bericht gebruiken dat via het Service Channel (SCH) verstuurd wordt.

5.3.1 Standaard berichten Met een standaard bericht wordt een bericht bedoeld dat voldoet aan de ETSI/CEN standaarden. Dergelijke berichten zijn openbaar, dienen het algemeen nut (verkeersveiligheid en doorstroming) en kunnen door elk voertuig ontvangen en gebruikt worden. De ETSI/CEN standaarden die voor het doorgeven van een spookfilebericht gebruikt zouden kunnen worden zijn op het moment van schrijven nog niet allemaal vastgelegd. Voorbeelden hiervan zijn MAP-, SPAT-, IVI-berichten (zowel qua uitvoering als qua inhoud). Het zou kunnen dat bepaalde gegevens die nodig zijn voor een spookfilebericht nog van het ene standaard berichttype verhuizen naar een ander standaard bericht type. Wel is het de verwachting dat de huidige ETSI/CEN berichten (CAM, DENM, MAP, SPAT, IVI) voor het op de markt komen van de eerste voertuigen met coöperatieve technologie zijn vastgelegd. Binnen het Spookfile project wordt de rol van een standaard coöperatief bericht voor spookfileinformatie aangeduid met JAM: Jam Advice Message. Gedurende fase 2 zal duidelijk worden:   

welk bericht, of welke berichten, uit de ETSI/CEN standaarden de JAM rol gaan vervullen, of er vanuit het Spookfiles project nog voorstellen gedaan moeten worden ter aanpassing van de ETSI/CEN standaarden zodat de JAM rol in voldoende mate vervuld kan worden12, of er binnen het Spookfiles project gewerkt gaat worden met een (tijdelijke) aanpassing van de standaard berichten zodat de JAM rol tijdens de PCP voldoende vervuld kan worden.

De P3 leveranciers zullen zorg dragen voor het coderen en decoderen van de JAM berichten. Hiermee wordt onder andere bedoeld dat, indien het JAM bericht nog geen standaard is, zij wel op de juiste wijze verwerkt moeten kunnen worden (bijvoorbeeld ge-encodeerd en gedecodeerd) door de wegkantstations. Dit verwerken gebeurt onder verantwoordelijkheid van de P3 leveranciers (om te voorkomen dat verschillende service providers en/of dataleveranciers elk hun eigen faciliteiten hiertoe moeten ontwikkelen en op de RIS moeten implementeren). Hierbij is het niet gegarandeerd dat deze oplossing wordt ondersteund vanuit OEM in-line manufactured en retro-fit coöperatieve ITS 11

Let op dat de keuze voor het implementeren van één kanaal betekent dat geen gebruik kan worden gemaakt van berichten zoals TSM die specifiek voor deze Service Provider zijn (zie onderstaande hoofdstuk). 12 Verschillende P3 leveranciers werken mee aan de totstandkoming van ETSI/CEN standaarden.


blz 27

diensten die zullen worden uitgerold. Het is dus mogelijk dat 'day 1' diensten geen ondersteuning bieden voor het JAM bericht; indien succesvol zou een tweede generatie van producten wel de noodzakelijke ondersteuning kunnen gaan bieden. Deze constatering vormt een factor van belang, ook kijkende naar de doelstellingen van het Spookfiles project om een opschaalbare, continueerbare maar ook effectieve oplossingen te realiseren. 5.3.2 Leverancier-specifieke berichten Het leveren van advies om de spookfile te bestrijden kan worden gedaan op verschillende niveaus (micro, macro, ...) en kan verschillende typen informatie omvatten. Er bestaat een commercieel en veelal strategisch belang bij een Service Provider om adviezen te kunnen sturen naar weggebruikers die klant zijn en om te voorkomen dat de weggebruikers die geen klant precies dezelfde adviezen ontvangen. Dergelijke adviezen kunnen niet via het CCH (zie hoofdstuk 5.2) worden verstuurd. Verscheidene leveranciers zijn daarom van mening dat het voordelen biedt om op een door ETSI/CEN toegestane wijze gebruik te maken van een leverancier-specifiek bericht via het Service Channel. Deze berichten zullen exclusief beschikbaar zijn voor de weggebruikers die klant zijn bij een Service Provider. Klanten ontvangen dergelijke berichten alleen van de Service Provider waarvan zij klant zijn. Binnen het spookfiles project is hieraan de naam Transparent Service Message (TSM) gegeven. De gegevens die via een TSM verzonden worden en de toegepaste codering zullen uitsluitend bekend zijn bij de Service Provider die het bericht verzonden heeft. Vanuit de P3 leveranciers zijn er twee methoden beschikbaar waarop een P2 Service Provider een TSM kan verzenden. Dit kan gebeuren vanuit de back office, waarbij de P3 leverancier zorg draagt voor het opnieuw verpakken van het bericht en de verzending over het Service Channel, of vanuit een P2 applicatie die vanuit de RIS zijn werk doet. Alleen in dat laatste geval biedt dit de P2 Service Provider de mogelijkheid om ook leverancier-specifieke berichten te ontvangen vanuit voertuigen van de klant. Het gebruik van TSM berichten en het Service Channel biedt ook kansen voor diensten anders dan de spookfiledienst en kan fungeren als katalysator voor het ontstaan van een commerciële markt voor deze toepassingen. P2 Service Providers mogen er niet zomaar vanuit gaan dat hun TSM oplossing wordt ondersteund vanuit OEM in-line manufactured en retro-fit coöperatieve ITS diensten die worden uitgerold. Het is daarom van belang dat zij een exploitatieplan hebben waarin rekening wordt gehouden met een zeer beperkte ondersteuning vanuit de OEM in-line manufactured oplossingen gedurende de uitrol van de eerste generatie coöperatieve oplossingen. Deze constatering, samen met het effectiviteitsperspectief en het marktperspectief (gebaseerd op een business case op basis van exclusieve adviezen), vormen een factor van belang. Zeker in relatie tot de doelstelling van het Spookfile project om een continueerbare en effectieve oplossingen te realiseren met verwachte marktwerking. 5.3.3 Ondersteunde berichten In het Spookfile project zullen tenminste de volgende drie berichten over het CCH verstuurd (kunnen) worden: 1. CAM (Cooperative Awareness Message): informatie die specifiek betrekking heeft op het coöperatieve eindstation (VIS, PIS of RIS) en die periodiek wordt verstuurd (dus niet event-


blz 28

driven) naar alle andere coöperatieve eindstations in de directe omgeving. Dit berichttype is reeds gestandaardiseerd door ETSI; 2. DENM (Decentralized Environmental Notification Message): informatie met betrekking tot de rij-omgeving en/of verkeerssituatie die wordt verstuurd op verzoek van een Road Hazard Warning toepassing naar aanleiding van een bepaalde gebeurtenis. Dit bericht kan V2V en I2V verstuurd worden. Dit berichttype is reeds gestandaardiseerd door ETSI; 3. Jam Advice Message (JAM): nog nader vast te stellen bericht, opgebouwd uit één of meerdere standaard berichten of aanpassingen daarop. Met als uitdrukkelijk doel standaardisatie door ETSI/CEN. En het volgende bericht over het SCH kanaal: 1. Transparent Service Message (TSM): dit bericht verschilt per Service Provider en kan alleen gedecodeerd worden door voertuigen die klant zijn van deze Service Provider. Deze methode is compliant met ETSI/CEN, maar de berichten zullen niet gestandaardiseerd worden. P2 Leveranciers hebben de keuzevrijheid om (in hun voorstel) te kiezen voor een oplossing die gebruik maakt van: 1. Het Service Channel (SCH) voor het versturen van TSM berichten. De P2 leverancier kiest er in dit geval voor om een exclusieve dienst aan te bieden aan haar klanten. De specificaties hiervoor worden opgesteld in WG2; 2. Het Control Channel (CCH) voor het versturen van JAM berichten (op een wijze zoals in WG2 invulling wordt gegeven aan deze JAM bericht). De P2 leverancier kiest er in dit geval voor om een gestandaardiseerd bericht te gebruiken ten bate van het gemeenschappelijk nut. 3. Een combinatie van bovenstaande twee mogelijkheden. De P2 leverancier dient zijn keuze te motiveren aan de hand van de marktwerking en de effectiviteit van de door hem gekozen oplossing. Onder marktwerking vallen aspecten als opschaalbaarheid en continueerbaarheid. Bij effectiviteit gaat het om de mate waarin de oplossing spookfiles daadwerkelijk weet te dempen en te voorkomen (voor meer informatie over zowel marktwerking als effectiviteit zie de Challenge documenten). De P3 Leverancier heeft hierbij de verantwoordelijkheid om te borgen voor zover het de eigenschappen van het coöperatieve wegkantstation betreft (RIS) dat: 1. een P2 Leverancier gebruik kan maken van de kanalen (CCH en SCH) en berichten zoals beschreven; 2. dat de 'facilities' op zijn coöperatieve wegkantstation, zoals wordt gespecificeerd in Annex: Werkgroep 2, de standaardberichten CAM en DENM op het CCH ondersteunen, en daarbij ook het JAM bericht op het CCH zoals dat door de gezamenlijke partijen zal worden vastgesteld, alsmede het TSM bericht op het SCH. De P3 leverancier zal dus moeten participeren in het PCP specificatie/selectie proces van het JAM bericht (met het oog op standaardisatie) en om door samenwerking met de P2 Leveranciers te borgen dat de TSM payload op WG2 conforme wijze kan worden verwerkt.


blz 29

5.4 Verkeersmanagementadvies in geval van meerdere Service Providers 5.4.1 Marktontwikkelingen en drie mogelijke toekomstscenario’s Er is ontegenzeggelijk een niet te stoppen marktontwikkeling (externe tendens) gaande waarbij private bedrijven (service providers) zich gaan bemoeien met tactische rijtaken (ADAS diensten zoals ACC, LDWS, etc.. en tactische informatiediensten zoals Jam Ahead Alert). Dergelijk tactische informatiediensten zullen van invloed zijn op de wijze waarop het verkeer zich afwikkelt. Met andere woorden, deze diensten zullen van invloed zijn op de wijze waarop de wegbeheerder haar taken op het gebied van verkeersmanagement uit kan voeren en hoeveel grip zij daar op heeft. De wettelijke taken voor de wegbeheerder met betrekking tot collectief verkeersmanagement en -veiligheid zullen vooralsnog blijven bestaan. Er is een drietal scenario’s mogelijk met betrekking tot de eisen die vanuit de wegbeheerder worden gesteld aan de informatie (het advies) die aan de weggebruiker wordt verstrekt. Welke eisen dit zijn is mede afhankelijk van de verantwoordelijkheden die de Service Providers krijgen. Ter illustratie: betreft het een private dienst onder verantwoordelijkheid van enkel de Service Provider zelf of is het een dienst die aan de wegbeheerder of namens de wegbeheerder wordt geleverd? De drie scenario’s zijn: i)

Autonomie Service Providers. Er worden vanuit de wegbeheerder geen eisen gesteld aan de informatie (het advies) dat aan de weggebruiker wordt verstrekt; ii) Centrale rol wegbeheerder. Adviezen moeten aan een groot aantal eisen voldoen waaronder de eis dat het advies eerst goedgekeurd moet worden of zelfs alleen afgegeven mag worden door de wegbeheerder zelf. Verwachting is dat goedkeuring in deze context betekent dat het advies niet mag conflicteren met andere adviezen. In de praktijk zou dit kunnen betekenen dat, als we de discussie even beperken tot adviessnelheden, de adviessnelheid van Service Provider A gelijk moet zijn aan die van Service Provider B. iii) Certificering. Een tussenvorm tussen i en ii is certificering van de Service Provider op basis van het aspect kwaliteit (van het advies). In deze tussenvorm kan en mag Service Provider A autonoom haar eigen advies verzenden en kan dit advies verschillen van het advies van andere Service Providers. Aanname is wel dat er door de certificering een bepaalde mate van harmonisering van de adviezen ontstaat. De EC heeft een kader opgesteld met de eerste implementaties van de ITS Richtlijn13. In dit kader zijn alle nationale (dus ook alle Nederlandse) operatoren en service providers van ITS diensten en/of producten onder een nationale toezichthouder geplaatst. De toezichthouder moet toetsen of de private partijen voldoen aan de EU ITS specificaties. Dit suggereert certificering, maar of dit in de praktijk onder invloed van de genoemde marktontwikkeling ook zo uitpakt is nog maar afwachten. 5.4.2 Onderscheid tussen testfase en commerciële fase, en het belang van innovatie Het harmoniseren en uniformiseren van adviezen is alleen mogelijk wanneer er overeenstemming is tussen de partijen over wanneer een advies goed is. Innovatie en voortschrijdend inzicht spelen hierbij een belangrijke rol. Om dit proces te versnellen/stimuleren is het wenselijk (of zelfs 13

richtlijn 2010/40/eu van het europees parlement en de raad


blz 30

noodzakelijk) om competitie op en differentiatie van adviezen mogelijk te maken. Het is hierbij verstandig om onderscheid te maken tussen de PCP testfase en de product/commerciële fase. In de testfase kunnen de Service Providers namelijk ieders een eigen advies aanbieden aan een selectie van deelnemers ('hun klanten') en de productiefase of commerciële fase is dit wellicht niet meer mogelijk (zie ook de drie scenario's hierboven). Het verkeerskundige effect (effectiviteit) van de differentiatie van adviezen is op dit moment nog onbekend. Het lijkt er echter op dat dit effect kleiner is dan het effect van de verschillen in opvolggedrag of het verschil tussen deelnemers en niet-deelnemers. Aanname is dat ondanks de verschillen in opvolggedrag en de beperkte penetratiegraad het toch mogelijk is om spookfiles op een effectieve wijze te bestrijden. Deze aanname leidt automatisch ook tot de aanname dat het ondanks de gedifferentieerde adviezen mogelijk is om spookfiles op een effectieve wijze te bestrijden. Met andere woorden, ondanks het feit dat de penetratiegraad tijdens de testfase (en waarschijnlijk in de periode erna ook) nog niet heel hoog zal zijn en het daardoor sowieso nog niet mogelijk is voor weggebruikers om zich uniform en als collectief aan te passen aan het spookfileadvies, mag het gedurende de testfase zeker geen ‘make or break’ eis zijn dat er uniforme adviezen worden uitgebracht. Om dit in een perspectief te plaatsen: het veiligheidsrisico van verschillende adviezen door de spookfiledienst lijkt niet groter dan het veiligheidsrisico van het naast elkaar bestaan van een geadviseerde maximum snelheden op bijvoorbeeld een navigatiesysteem en de wettelijk toegestane maximum snelheid. Deze snelheden bestaan nu naast elkaar, zijn algemeen geaccepteerd en zijn in de praktijk lang niet altijd gelijk. Voorwaarde is wel dat voor iedereen duidelijk moet zijn dat de wettelijk toegestane maximum snelheid altijd prevaleert boven de adviessnelheid van de spookfiledienst. Hier dient rekening mee gehouden te worden in de communicatie richting de deelnemers. 5.4.3 Ruimtelijk of temporeel scheiden? Het is denkbaar om de A58 gedurende de testfase over de twee Service Providers te verdelen (in tijd en/of ruimte) om te voorkomen dat op één locatie twee verschillende adviezen worden verstrekt. Hierdoor bestaat echter de kans dat het aantal weggebruikers dat op een bepaalde locatie een advies krijgt wordt gehalveerd (interoperabiliteit waarbij klanten van Service Provider A het advies verzonden door Service Provider B kan ontvangen kan op basis van de perceelkoppelvlakken, zeker in de testfase, niet gegarandeerd worden). Tenslotte is het onwenselijk, vanuit een communicatie- en exploitatieoogpunt, om de gebruikers van een dienst de toegang tot deze dienst gedurende een bepaalde periode of op een bepaald deel van het traject te ontzeggen. 5.4.4 Invloed van het gebruik van het Control Channel mbt het Service Channel Mogelijke reden voor Service Providers om te kiezen voor het Control Channel voor het versturen van berichten is de naar verwachting betere ondersteuning vanuit de eerste generatie(s) coöperatieve ITS producten die uitgerold zullen worden (zie ook hoofdstuk 5.2). Of een advies van een Service Provider consistent moet worden gemaakt met andere adviezen (van een andere Service Provider en/of de wegbeheerder) is afhankelijk van de kanaal keuze van de Service Providers.


blz 31

Messages die over het CCH worden gecommuniceerd zullen door alle automobilisten ontvangen worden. Tevens is de geest van de ETSI/CEN standaard dat deze berichten informatie omvatten die niet specifiek nuttig is voor één toepassing, maar een meer generieke waarde heeft. Het is duidelijk dat een Spookfile-advies dat op een bepaalde locatie over het CCH wordt verstuurd door de éne Service Provider gelijk moet zijn aan het advies van een andere Service Provider op gelijke locatie. De Leveranciers in het Spookfile project hebben hierom besloten dat tijdens fase II zal worden uitgewerkt hoe deze consistentie zal worden bereikt. Uitgangspunt hierbij is dat: 1. het RIS één bericht (met één advies als payload betrekking hebben op een bepaalde locatie) zal uitsturen en dus niet voor verschillende Service Providers een eigen DENM of JAM bericht; 2. het RIS niet voor de consistentie zal zorgen, maar dat buiten het RIS om gezorgd wordt dat er alleen advies dat al consistent is aan de RIS wordt aangeboden voor verwerking en verzending. 5.4.5 Conclusies Op basis van het bovenstaande kan worden geconcludeerd dat de Service Providers gedurende de testfase zelf verantwoordelijk zijn het afleiden van een advies en dat dit advies operationeel beschikbaar wordt gemaakt voor het gehele traject (A58 tussen Tilburg en Eindhoven) Er vindt dus geen ruimtelijke of temporele scheiding plaats. De consequentie hiervan is dat er op één locatie meerdere Service Providers actief zullen zijn met elk hun eigen advies. Om te borgen dat er alleen consistente adviezen worden verzonden over het CCH is afgesproken dat iedere Service Provider die van plan is om berichten te versturen over de CCH actief zal participeren in een proces waarin wordt uitgewerkt op welke wijze consistentie bereikt kan worden. De berichten dienen niet alleen consistent te zijn met berichten van andere Service Providers, maar ook met die van de wegbeheerder. De Service Providers zijn verantwoordelijk voor de implementatie van de uitkomsten in fase III. Dit betekent dat het zowel procedureel als technisch mogelijk moet zijn om op één en dezelfde locatie een selectie van Spookfiledeelnemers het advies van één bepaalde Service Provider te presenteren terwijl een andere selectie van de deelnemers het advies van een andere Service Provider ontvangt. Daarnaast moeten alle deelnemers het consistent gemaakte advies kunnen ontvangen dat over het CCH wordt verstuurd. De Spookfile architectuur en de koppelvlakken dienen dit mogelijk te maken.14.

5.5 Coöperatief verkeersmanagement langs de weg en in het voertuig 5.5.1 Functioneel Het managen van verkeer kan op drie niveaus worden beschouwd. a. Operationeel niveau: Op dit niveau gaat het over het lokale voertuigen en hun bestuurders. Dit is het niveau waarop de bestuurder op basis van haar waarnemingen besluiten neemt en keuzes maakt voor zaken als snelheid, acceleratie en volgafstand. Op dit niveau worden besluiten genomen op basis van seconden en gaat het over afstanden tot enkele honderden meters. 14

Overigens is dit een procedurele/juridische kwestie die pro-forma is genoemd, die misschien geen invloed heeft op de architectuur en koppelvlakken; echter dat moet wel gevalideerd worden!


blz 32

b. Tactisch niveau: Op dit niveau liggen de bijbehorende tijd en ruimteschalen in de orde van grootte van tientallen seconden en honderden meters. Een typisch voorbeeld is het in of uitvoegen op een snelweg. c. Strategisch niveau: Dit niveau wordt gekenmerkt door een groot ruimtelijk bereik (>> 1 km) en bijbehorende tijdschalen (minuten). Dit is typisch het domein van routenavigatie en planning. Coöperatieve technologie biedt grote voordelen bij de ondersteuning van rijtaken op zowel operationeel als tactisch niveau. Deze voordelen ontstaan voornamelijk doordat berichten met coöperatieve technologie in een zeer kort tijdsbestek (typisch < 100ms) kunnen worden verstuurd (zowel V2V als I2V). Coöperatieve technologie kan hiermee een belangrijke bijdrage leveren op het gebied van verkeersveiligheid en verkeersmanagement op zowel operationeel als tactisch niveau. Daarnaast kan coöperatieve technologie ook ingezet worden op strategisch niveau. Hiervoor is voldoende geografische dekking echter een voorwaarde. Ander sterk punt van coöperatieve technologie is dat het mogelijk wordt om toepassingen of diensten decentraal uit te voeren op de locatie waar de informatie betrekking op heeft (lokaal, langs de kant van de weg). Hiermee kunnen oplossingen worden geïmplementeerd waarvan de intelligentie sterk gedistribueerd is en die toch schaalbaar zijn en autonoom kunnen werken15. 5.5.2 Het hosten van coöperatieve applicaties Een belangrijk aspect van coöperatieve wegkantinfrastructuur is de wijze waarop deze ontsloten wordt voor andere service providers. Om de coöperatieve weginfrastructuur zo optimaal mogelijk te ontsluiten is in het Spookfiles A58 project het concept ‘wegkant hosting’ geïntroduceerd. Dit houdt in dat de P3 leverancier de aangelegde coöperatieve infrastructuur beschikbaar maakt voor derden en hen hierdoor de mogelijkheid biedt om toepassingen, diensten en/of applicaties op de roadside ITS stations (RIS) te installeren. Deze applicaties kunnen vervolgens gebruik maken van de aangeboden coöperatieve communicatiemogelijkheden en van de lokale verwerkingscapaciteit ('executie omgeving') om ze uit te voeren. De technische invulling van hosting concept is in WG6 gespecificeerd (zie Annex: Werkgroep 6). De introductie van dit concept geeft Service Providers eenvoudig toegang tot de gedistribueerde coöperatieve infrastructuur bestaande uit haar eigen centrale ITS station en de roadside ITS stations (en natuurlijk de Vehicle ITS stations). Het is aan de Service Provider zelf om de afweging te maken waar ze welke algoritmen wil laten uitvoeren en hoe ze om willen gaan met de opslag en verwerking van data in het systeem. De architectuur biedt ruimte om gebruik te maken van lokale verwerkingscapaciteit (voertuig en wegkant) en snelle communicatie tussen voertuigen onderling en tussen voertuigen en de coöperatieve wegkantsystemen. 5.5.3 Visie op de lokale communicatie infrastructuur Essentieel onderdeel van een coöperatief wegkantsysteem is het lokale netwerk waarmee de stations aan het centrale systeem worden verbonden. De volgende overwegingen spelen hierbij een rol: - De coöperatieve wegkantsystemen moeten idealiter ook onderling kunnen communiceren; 15

zowel coöperatieve als connected diensten kunnen ondersteuning aan de bestuurder bieden op zowel operationeel als tactisch niveau.


blz 33

- Omwille van de beheersbaarheid is het wenselijk om in het hostingmodel de mogelijkheid te hebben om de applicatieomgeving centraal te virtualiseren. Hiervoor is een verbinding met zowel een zeer lage latency als een zeer hoge bandbreedte noodzakelijk (in theorie: tot max. 6Mb/s per channel); - Gezien het real-time karakter van coöperatieve toepassingen zijn in z’n algemeenheid een hoge beschikbaarheid (up time garanties bij congestie) en een lage latency (< 0,1 seconde) van bijzonder groot belang. Deze overwegingen leiden tot het inzicht dat voor een professionele uitvoering van coöperatieve diensten de wegkantsystemen via een vast netwerk moeten worden ontsloten.

5.6 "Roaming" & "Interoperabiliteit" Veronderstel een horizontale markt waarin een ecosysteem is ontstaan waar de Spookfiledienst onderdeel van uitmaakt. In deze markt is het nog steeds aan de leveranciers16 of zij de standaardisatie van koppelvlakken zo ver door willen trekken dat een gebruiker op één voertuigplatform en met maar één overeenkomst met een Service Provider overal naadloos17 van een Spookfiledienst gebruik kan maken of niet. Interoperabiliteit houdt dan in: -

Technische interoperabiliteit (=compatibiliteit); Procedurele interoperabiliteit; Contractuele interoperabiliteit.

De implementatie van de Spookfiles A58 koppelvlakken (zie de specificaties in de annexen) is dus onvoldoende om deze vorm van interoperabiliteit te garanderen. In aanvulling op de Spookfiles A58 koppelvlakken moeten de volgende 'koppelingen' worden afgesproken: -

-

-

De koppeling tussen de Spookfile applicatie op de VIS (zoals onder beheer van Service Provider a) en de Spookfile applicaties op de CIS en de RIS (zoals onder beheer van Service Provider b); Eventuele procedurele afstemming tussen Service Provider a en b om te kunnen garanderen dat alleen weggebruikers die betalende klant bij Service Provider a zijn door Service Provider b zullen worden bediend met het naadloze vervolg van de service daar waar dit niet door Service Provider a gedaan kan worden; Eventuele contractuele afspraken tussen Service Provider a en b om de vergoeding voor het leveren van deze service door Service Provider b af te spreken.

Risico's aan interoperabiliteit Het opleggen van interoperabiliteit aan de markt nog voordat de markt zich heeft kunnen 'convergeren' brengt verschillende risico's met zich mee. Het vereist namelijk dat de verschillende diensten in grote mate compatible met elkaar zijn, terwijl het ook heel goed mogelijk is, en misschien zelfs waarschijnlijk, dat er juist een markt ontstaat waarin de verschillende commercieel succesvolle 16

en eventueel via regulering van overheden over landsgrenzen heen of buiten het bereik van zijn eigen service provider de adviezen van een gastheer service provider kunnen gebruiken analoog aan roaming van mobiele telefoniediensten 17


blz 34

diensten juist andere, complementaire functionaliteiten bieden. Gebruikers kunnen in zo’n markt op basis van hun wensen en voorkeuren een provider kiezen. Mogelijke verschillen tussen providers kunnen bijvoorbeeld zitten in de mate waarin de verschillende diensten keuzevrijheid aan de gebruiker blijven geven, of het type advies dat gegeven wordt (om te plannen, of rijtaak ondersteunend). In het algemeen is een fase waarin diensten niet volledig compatibel met elkaar hoeven te zijn, gunstig voor de mate van innovatie en concurrentie. Met andere woorden: het vooraf opleggen van deze interoperabiliteit kan de marktontwikkeling nadelig beïnvloeden. Ten tweede zou het zo kunnen zijn dat de offboard en onboard componenten van een dienst op zodanige wijze nauw met elkaar verbonden zijn, dat het niet mogelijk is om de offboard component op een enigszins redelijke wijze te koppelen aan een onboard component van een andere service provider18. Wat kan interoperabiliteit borgen Interoperabiliteit is belangrijk in een situatie waarbij een Service Provider de gehele verticale zuil aanbiedt en dan nog met name indien het een 'captive' markt betreft (dus een markt die ontstaat door regelgeving en waar voor de gebruiker geen of beperkte keuze bestaat). De verticale verzuiling maakt het dan voor een gebruiker niet mogelijk om zomaar over te stappen van de ene Service Provider naar de andere waardoor de gebruiker ingesloten raakt bij een bepaalde Service Provider. In hoeverre speelt dit bij een Spookfiledienst? Bij een connected Spookfiledienst maakt de gebruiker gebruik van een applicatie van de Service Provider, die: -

Via het cellulaire netwerk (25G/3G/4G) in verbinding staat met de backoffice van de Service Provider Draait op:  De eigen smartphone of tablet computer. De gebruiker kan zelf de benodigde applicatie downloaden, (de)activeren en weer verwijderen en kan zo van de ene Service Provider overstappen op de andere (mits contractueel ongebonden)  Een PND (als extra functionaliteit). De gebruiker kan met de PND een Spookfiledienst afnemen. Door een andere PND aan te schaffen stapt de gebruiker impliciet over naar een andere Service Provider;  OEM invoertuig platform (als extra functionaliteit). De gebruiker kan met het voertuig een Spookfiledienst afnemen. Door een andere voertuig aan te schaffen stapt de gebruiker impliciet over naar een andere Service Provider.

De Spookfiledienst en de Spookfiles A58 koppelvlakken borgen dat de markt horizontaal is en niet verticaal geïntegreerd. Bij een 'connected' Spookfiledienst heeft de gebruiker daarom zelf de keuze voor een Service Provider en een Telecom Provider en is er geen sprake van gedwongen winkelnering, zoals dit bijvoorbeeld wel het geval is bij het elektronisch heffen van tol. 18

Een goede analogie hierbij is bijv. het type offboard-onboard navigatie dat Google Maps Navigation biedt: hierbij zit veel van de complexe rekenfunctionaliteit offboard en wordt deze via complexe datastructuren, toegespitst op de online component van Google Maps Navigation, naar het device gestuurd. Bij zulke oplossingen kan niet of nauwelijks sprake zijn van offboard informatie zodanig uniform maken dat “roaming” met andere onboard componenten cq andere diensten mogelijk is. Kortom, er kunnen zowel markt- als technische redenen zijn waardoor “roaming” niet praktisch of mogelijk is.


blz 35

Bij een coöperatieve Spookfiledienst maakt de gebruiker onder andere gebruik van een coöperatief voertuig component die of door de Service Provider wordt aangereikt of ingebouwd zit in het voertuig. De coöperatieve module voldoet aan de ETSI specificaties voor een voertuig ITS Station (VIS) en kan daarmee door heel Europa worden gebruikt, ook buiten het domein van de Service Provider. Wanneer de coöperatieve berichten door de Service Provider over het Control Channel (CCH) worden verstuurd is bovendien al een grote mate van interoperabiliteit geborgd en zijn aanvullende afspraken ten behoeve van procedurele of contractuele interoperabiliteit niet noodzakelijk. Ook bij een coöperatieve Spookfiledienst is er dus geen sprake van gedwongen winkelnering. Het potentieel tot opschaling van de RIS en de VIS is hiermee geborgd zonder volledige interoperabiliteit op te leggen. Conclusie PCP Spookfiles A58 interoperabiliteit Het is de verwachting dat succesvolle implementaties van de Spookfiledienst sterk opgeschaald zullen worden en in combinatie met tal van andere toepassingen zullen worden aangeboden aan de weggebruiker. In dit proces waarin de dienst wordt verbeterd en opgeschaald ligt er een natuurlijk motief bij de markt om de dienst zo onafhankelijk mogelijk te maken van het VIS- en RIS platform. De Service Provider kan de dienst hierdoor immers aan een zo groot mogelijke gebruikersgroep voor een zo laag mogelijke prijs aanbieden. De situatie waarin een weggebruiker zonder aanpassingen aan zijn voertuig of VIS gebruik kan maken van deze geëvolueerde versie van de Spookfiledienst, die op technisch en operationeel vlak volledig interoperabel is, ontstaat hiermee zonder regulering en is het gevolg van marktwerking. Ook is het borgen van interoperabiliteit in het geval van de Spookfiledienst niet cruciaal, omdat in een horizontale markt, de weggebruiker altijd voldoende keuze zal hebben. Gedurende het Spookfiles A58 project is het van belang dat implementatiekeuzes die nodig zijn om volledige interoperabiliteit te borgen, de innovatie niet in de weg zitten. Interoperabiliteit is daarom geen opgelegd uitgangspunt in dit project.


blz 36

6 Impact op gebruikers/stakeholders Coöperatieve systemen hebben de potentie om een rol te gaan vervullen op het vlak van verkeersmanagementmaatregelen. Vanuit deze optiek is het interessant om in dit document een korte beschouwing op te nemen van de huidige gebruikers en stakeholders van dergelijke maatregelen en om alvast vooruit te kijken naar wat coöperatieve systemen zouden kunnen betekenen voor de verdeling van rollen en verantwoordelijkheden binnen dit speelveld. Gebruikers van de huidige verkeersmanagementmaatregelen zijn: 



 



weggebruikers: - voertuigbestuurders (MTM en TDI); - wegwerkers (MTM); - hulp- en nooddiensten bij incidenten op de weg (MTM). wegbeheerders: - Rijkswaterstaat:  Motorway Traffic Management (MTM) systeem en daarmee AID en DynaMax:  Functionele beheerder: RWS Water, Verkeer en Leefomgeving.  Technisch beheerder: RWS Centrale Informatievoorziening .  Operatie: RWS Verkeer- en Watermanagement (verkeerscentrale).  Toeritdoseerinstallatie (TDI):  Functioneel beheerder: RWS.  Technisch beheerder: RWS.  Operatie: RWS Verkeer- en Watermanagement (verkeerscentrale). - provincie: n.v.t. - gemeente: n.v.t. RIS operatoren: - MTM (in alfabetische volgorde): Imtech, Siemens, Vialis. - TDI (in alfabetische volgorde): Imtech, Siemens, Vialis. Service Providers - focus op data (wegverkeersgegevens). - focus op informatie, waarbij afspraken bestaan met wegbeheerders dat veiligheidsgerelateerde informatie (en daarmee sterk verkeersmanagement gerelateerd) met prioriteit aan klanten van de Service Providers wordt doorgegeven. OEMs - Ingebouwde radio- en navigatiesystemen waarop data en informatie van Service Providers kan worden aangeboden aan weggebruikers. - Ingebouwde sensoren die informatie op statische verkeersborden (met maximum snelheidsaanduidingen, of einde snelweg aanduidingen) ook op het dashboard van de auto onder de aandacht van de bestuurder brengen.

Kijkend naar bovenstaande opsomming die de huidige situatie kenschetst, bieden coöperatieve (wegkant)systemen in potentie Service Providers de beschikking over veel gedetailleerdere en actuelere wegverkeersgegevens dan nu het geval is. Aanname hierbij is dat private partijen, ook buiten een PCP constructie, in een positie komen om coöperatieve wegkantsystemen te beheren en toe te kunnen passen voor dienstverlening richting de weggebruiker. De veel gedetailleerdere en actuelere gegevens bieden Service Providers de mogelijkheid om adviesdiensten te ontwikkelen die de weggebruiker niet alleen informeren (zoals nu het geval is), maar die rijtaakondersteunend


blz 37

adviseren. Waarbij de laatste vorm het effect van sturen van verkeer zou kunnen gaan aannemen. Rollen en verantwoordelijkheden van wegbeheerders, Service Providers en andere stakeholders zullen gegeven de technische mogelijkheden goed moeten worden afgestemd. Vragen als: “Wat kan en zal een wegbeheerder toelaten?” én “Wat kan verwacht worden van OEMs ten aanzien van het beschikbaar stellen van voertuiggerelateerde gegevens?” zijn enkele van de vele vragen die beantwoord moeten gaan worden.


blz 38

DEEL II: UITWERKING SOLUTION DESIGN EN AANDACHTSGEBIEDEN


blz 39

7 High Level Architectuur SP Back Office

G

A

H’

M&E

B

D2

BACK OFFICE

CIS

Dataverrijking

D1

H TrafficMgt Center

Dataverwerking

A*

CIS

F* 2.5G4G, DAB, …

host

Applicatie

F = D10

D10

D10

Facilities

D11 Network and Transport

D3 standaard

voertuig

VehicleIntegratie

Onderstation host

Facilities

host

C2C

H*

Data Applicatie

lus

Matrix VMS

ROAD SIDE

SP Applicatie

RIS

D5

M&E

I

Applicaties

API’s host


VIS

blz 40

VOERTUIG

M&E

7.1 Introductie De Centrale Architectuur Groep (CAG) heeft de taak op zich genomen om een High Level Architectuur (HLA) op te stellen. De HLA dient als uitgangspunt voor de te realiseren Spookfilediensten in zowel de fasen connected als de doorontwikkeling naar connected in combinatie met coöperatief. De HLA is in een aantal iteratieslagen tot stand gekomen en getoetst in verschillende bijeenkomsten. Belangrijk uitgangspunt van de HLA is dat de in fase 1 van het A58 Spookfile project gevormde visie ten aanzien van een horizontale markt en business ontwikkeling ondersteund dient te worden en mogelijk dient te zijn. Met deze gedachte is de HLA als referentie gebruikt voor de werkgroepen die in paragraaf 7.2 worden geïntroduceerd. Aan de hand van de HLA hebben de werkgroepen de componenten en interfaces uitgewerkt en gedocumenteerd. Ook hebben de werkgroepen de documenten opgesteld waarin de aan de werkgroep toebedeelde componenten zijn benoemd en de interfaces zover als mogelijk zijn gespecificeerd. De door deze werkgroepen opgeleverde specificaties zijn leidend voor de aan te bieden oplossingen in de fasen connected en de fase waarin de doorontwikkeling naar connected in combinatie met coöperatief wordt gerealiseerd. Naast het gebruik van de HLA door de werkgroepen voor het uitwerken van de specificaties voor de interfaces heeft de HLA ook als referentie gediend voor de werkgroepen die zich bezig hebben gehouden met de leidende afspraken voor het vervolgtraject ten aanzien van testen, monitoring en evaluatie, deelnemerswerving en communicatie. Met de nadrukkelijke verwijzing naar de documenten van de afzonderlijke werkgroepen voor de uitwerking van de leidend zijnde details van de HLA, wordt in §7.1.1 en§7.1.2 toch een korte toelichting op de HLA. Deze toelichting beperkt zich tot de hoofdlijnen. 7.1.1 Overzicht functionele omschrijving laag in de HLA In de HLA worden van boven naar beneden de lagen CIS, RIS en VIS genoemd (In de HLA ook wel aangeduid als back office, roadside en voertuig). In §7.1.1.1, §7.1.1.2 en §7.1.1.3 worden deze applicaties kort geïntroduceerd. 7.1.1.1 Functionaliteit SP Back Office (CIS) applicatie Dit is een applicatie van de spookfile-adviesdienst in een centraal systeem, ook wel Central ITS Station (CIS) genoemd. Deze applicatie kan data uit perceel 1 (P1) verwerken tot spookfile-adviezen die de applicatie in het Vehicle ITS Station (VIS) nodig heeft om een spookfile-advies te presenteren aan de gebruiker. Voorbeelden hiervan zijn snelheids- en rijstrookadviezen. Het CIS heeft informatie van voldoende kwaliteit nodig van P1 (KV A in de scope van WG1) en heeft een communicatiekanaal naar de voertuigen van de Service Provider nodig waarmee de benodigde gegevens aan het VIS geleverd kunnen worden. Deze communicatie verloopt via interface B of interfaces D1, D2, D3 en D5. 7.1.1.2 Functionaliteit voertuig applicaties (VIS/PIS) Dit is een applicatie van de spookfile-adviesdienst in het voertuig. Voorbeelden hiervan zijn een Personal ITS Station (PIS zoals een Smartphone of PND) of een VIS (voertuiggebonden Vehicle ITS


blz 41

Station). De applicatie geeft een spookfile-advies aan de gebruiker op basis van informatie uit het voertuig en/of van het RIS en/of CIS. De VIS/PIS moet generieke (Service Provider specifieke is ook toegestaan) informatie aan het RIS en het CIS terug kunnen leveren. Dit gaat via interface B of interfaces D5 en D2. Het PIS/VIS moet in de coöperatieve fase informatie kunnen delen met PIS/VIS systemen in andere voertuigen. Dit geldt zowel voor informatie van de eigen Service Provider als van de andere Service Providers. Deze communicatie dient geen gebruik te maken van het RIS of het CIS. 7.1.1.3 Coöperatieve communicatie wegkant RIS Een Roadside ITS Station (RIS) is verantwoordelijk voor de coöperatieve functionaliteit op een bepaald deel van een wegvak (bijvoorbeeld 500-1500m). Deze coöperatieve functionaliteit is tweeledig. Allereerst zorgt het RIS voor short-range communicatie met voertuigen (VIS of PIS). Daarnaast biedt het RIS de mogelijkheid om applicaties van Service Providers te hosten (data-inwinning op P1 en adviesdiensten op P2). Op het hoogste functionele niveau is de coöperatieve communicatie van de wegkant een doorgeefluik van berichten die tussen het VIS en CIS verstuurd worden. Dit kunnen zowel gestandaardiseerde als Service Provider specifieke berichttypen zijn, en zowel open als gesloten berichten zijn. Applicaties van P1- en P2-partijen kunnen gebruik maken van openbare data van voertuigen binnen het bereik van het RIS (die via interface D5 binnenkomt). Applicaties van P2-partijen kunnen data van P1-partijen betrekken (lokaal of vanuit de centrale), en daarnaast beschikken over eigen data van eigen voertuigen (die via interface D5 binnenkomt). 7.1.2 Overzicht van functionele omschrijving per koppelvlak Ter introductie op de koppelvlakken in de HLA is onderstaande tabel opgenomen. Koppelvlak

Functionele omschrijving

Specificatie

A/A*

Koppelvlak A omvat de levering van verschillende type gegevens gerelateerd aan verkeersstromen en afzonderlijke voertuigen (bijv. snelheden, intensiteiten, wegwerkzaamheden etc.) die afkomstig zijn uit verschillende databronnen. (bijv. lussen, matrixborden, FCD data leveranciers, exogene journalistieke dataleveranciers). De data geleverd via koppelvlak A moet voor verschillende diensten en doeleinden gebruikt kunnen worden. Zo moet het mogelijk zijn voor afnemers om data via koppelvlak A op verschillende ruimtelijke detail niveaus (macro/micro) te verkrijgen met verschillende respons tijden en frequenties. Deze kwaliteiten zullen sterk afhangen van het type toepassing waar deze data voor gebruikt wordt.

Werkgroep 1

Koppelvlak A ontzorgt de afnemer door de aangeboden data zodanig te ontsluiten dat het makkelijk wordt voor Service Providers om op basis


blz 42

van deze databronnen nieuwe en innovatieve diensten te ontwikkelen. Het is daarom van belang dat de data die door koppelvlak A ontsloten is werkt met open-standaarden en waarbij afnemers vrij zijn hun eigen kaartmateriaal of software systemen te gebruiken. Dit stelt hoge eisen aan de wijze waarop er aan tijd en ruimte wordt gerefereerd en de actualiteit en juistheid van configuratiegegevens. B

Koppelvlak B (voorheen B en C) zorgt voor:  

Werkgroep 2

de tijdige levering van centraal gegenereerde informatie en/of adviezen aan de voertuigsystemen. de tijdige levering van voertuiggegevens aan het centrale systeem van de Service Provider.

Stakeholders en hun specifieke behoeften zijn: 

D1

Service Providers: o Zo veel mogelijk relevante bestuurders bereiken.  Bestuurders: o Zo voordelig mogelijk tijdig bruikbare informatie ontvangen. Deze betaalt voor de communicatie afhankelijk van bandbreedte, heeft al dan niet een smartphone. o Privacy.  Wegbeheerder: o Mogelijkheid voor communicatie naar de bestuurder. Bijvoorbeeld gerichte informatie / adviezen of waarschuwingen bij bijzondere incidenten of omstandigheden. Koppelvlak D1 biedt Service Providers van P2 een transparant Werkgroep 2 communicatiekanaal van de centrale naar eigen VIS’s, via de wegkantstations. Praktisch gezien is D1 een koppelvlak tussen de software van de Service Provider in het CIS en een applicatie van P3 in het RIS. Het RIS zorgt vervolgens voor tijdige codering en uitzending van de aangeboden informatie naar alle VIS´s binnen bereik van het RIS. D1 is een éénrichtingskanaal van het CIS naar het VIS.

D2

Koppelvlak D2 biedt Service Providers van P2 een directe verbinding met hun eigen applicatie in het RIS. Dit stelt Service Providers in staat om hun lokale applicatie te voeden met informatie uit het centrale systeem en eigen informatie uit het RIS naar het CIS te halen. In tegenstelling tot D1 staat D2 dataverkeer in twee richtingen toe.

Werkgroep 2

D3

D3 is het koppelvlak voor alle communicatie van het RIS naar het VIS. Dit koppelvlak ondersteunt standaard G5 berichttypen maar stelt

Werkgroep 2


blz 43

Service Providers van P2 ook in staat vanuit het CIS en het RIS Service Provider specifieke informatie te sturen aan hun eigen VIS. D5

D5 is het koppelvlak voor alle communicatie van het VIS naar het RIS. Dit koppelvlak ondersteunt standaard G5 berichttypen maar stelt Service Providers van P2 ook in staat vanuit het VIS Service Provider specifieke informatie te sturen aan hun eigen applicatie in het RIS.

Werkgroep 2

D10

Koppelvlak D10 faciliteert datacommunicatie tussen de applicaties van de verschillende percelen binnen het RIS en kan functioneel als lokale equivalent van D1 beschouwd worden, waarbij ontvangen van berichten ook mogelijk is.

Werkgroep 2

D11

Koppelvlak D11 stelt applicaties op het RIS in staat zelf gecodeerde berichten aan te bieden ter uitzending aan het VIS of the ontvangen.

Werkgroep 2

F

F en F* omvatten op CAM en DENM gebaseerde informatie die resp. FCD-data en gebeurtenissen (incidenten, waarschuwingen e.d.) die vanuit de het VIS/RIS beschikbaar komen doorgeven aan datainwinning, vanuit welke ze vervolgens via A en A* weer doorgegeven kunnen worden aan Spookfilediensten.

Werkgroep 1

F*

F en F* omvatten op CAM en DENM gebaseerde informatie die resp. FCD-data en gebeurtenissen (incidenten, waarschuwingen e.d.) die vanuit het VIS/RIS beschikbaar komen doorgeven aan data-inwinning, vanuit welke ze vervolgens via A en A* weer doorgegeven kunnen worden aan Spookfilediensten.

Werkgroep 1

G

Verscheidene Spookfilediensten verkrijgen Floating Car Data (FCD) via de eigen, proprietary, ‘connected’ (3G e.d.) mobiele data-kanalen met hun deelnemers. Deze data vormt een mogelijk waardevolle toevoeging aan de andere data die de data-inwinningspartijen inwinnen. Koppelvlak G omvat de levering van deze data door Spookfilediensten aan data-inwinningspartijen Op zijn beurt kan deze data na verdere integratie en processing door die data-inwinningspartijen weer dienen als algemeen beschikbare input-data voor alle Spookfilediensten.

Werkgroep 1

H / H’

Via koppelvlak H en via het NDW wordt er ingewonnen data en informatie vanuit de verkeerscentrale en in ruwe / verrijkte / gefuseerde of semantische vorm aangeleverd aan de offboard functionaliteit. Via H’ is er een feedback naar de verkeerscentrale.

Werkgroep 1

I

Een Spookfiledienst kan op meerdere typen van front end devices landen. Daarbij is onderscheid gemaakt tussen reizigers en voertuig gebonden front ends. Beide zijn op hun beurt weer onderverdeeld in voor derden open en gesloten systemen. In principe kunnen deze devices ook gebruikt worden voor de front end van een coöperatieve

Werkgroep 3


blz 44

Spookfiledienst, mits er een coöperatieve module aan wordt toegevoegd. Tevens kan het reizigers gebonden front end device ook aanvullend op het voertuig gebonden front end device gebruikt worden, het zogenaamde second screen. Hiermee kunnen diensten ook gekoppeld worden aan gesloten voertuig gebonden front end devices. Uitgaande van de classificatie van front end devices kunnen we de koppelvlakken van het front end device definiëren. Dit zijn (Figuur 3): •

koppelvlak B=C, zoals gespecificeerd door Werkgroep 1;

•

koppelvlak D en D’, zoals gespecificeerd door Werkgroep 2;

•

de installatie in het voertuig;

•

de link tussen het Front end device en de dashboard HMI (de belangrijkste standaarden zijn: MirrorLink, Carplay (Apple), Automotive Link (OAA, Google));

•

hosting (service application provisioning op het OEM platform);

•

de koppeling om CAN data uit het voertuig te krijgen.

7.2 Introductie werkgroepen Het specificeren van koppelvlakken die het ontstaan van een horizontale markt faciliteren is een belangrijk uitgangspunt in het Spookfiles A58 project. In de visie van de marktpartijen betekent dit dat een Service Provider zich vooral moet kunnen onderscheiden in het afleiden van advies waarmee de spookfile wordt bestreden en waar de wegbeheerder of de weggebruiker de toegevoegde waarde van inziet. Het beschikken over goede en actuele verkeersdata is hiertoe cruciaal. Indien de Service Provider alle data die in aanvulling op openbare data (NDW) noodzakelijk is voor een goed advies zelf moet inwinnen, dan wordt de Spookfiledienst duurder dan wanneer hiertoe noodzakelijke data voor verschillende diensten kan worden gebruikt. Ook is de beschikbaarheid van noodzakelijke data in een goed werkende markt gunstig voor 'kleinere' Service Providers om te starten. Zij hoeven in dit geval namelijk niet te beschikken over een grote hoeveelheid FCD van eigen klanten. Er zijn meer redenen, maar bovenstaande analyse is in een notendop de basis voor het ontstaan van Werkgroep 1. In Werkgroep 1 zijn de data-uitwisselingskoppelvlakken tussen Service Providers, Data Leveranciers en Publieke Wegbeheerders gespecificeerd. Tevens betekent dit dat de Service Provider haar advies moet kunnen (laten) transporteren tot het in het voertuig aan de weggebruiker kan worden gepresenteerd zonder zich te hoeven bekommeren om de telecommunicatietechnologie. Hiertoe is het noodzakelijk dat de Spookfileleveranciers afspraken maken over de koppelingen op 'applicatie', 'facilities' en 'transport en netwerk' niveau tussen het CIS, het RIS en het VIS. Deze afspraken zijn gespecificeerd door Werkgroep 2.


blz 45

De gezochte horizontalisering betekent ook dat de Service Provider vrijelijk haar advies moet kunnen afleiden zowel in het CIS, als in het RIS en het VIS (vrije keuze van de verdeling van 'intelligentie' over de back office, het lokale wegkantstation en het voertuigplatform) zonder rekening te hoeven houden met de implementatie en architectuurkeuzen van de wegkantstations. Hiertoe heeft Werkgroep 6 specificaties opgeleverd om de 'hosting interface' te definiëren waarmee een Service Provider / dataleverancier lokaal, langs de wegkant, een applicatie kan draaien in een 'standaard' omgeving. Inzoomend op Perceel 2, betekent dit uitgangspunt ook dat de Service Provider wordt gevraagd om een applicatie te ontwikkelen die zoveel mogelijk onafhankelijk is van het VIS en van het type voertuig van de deelnemers. Hiertoe heeft Werkgroep 3 onderzocht welke mogelijkheden en aanbevelingen gedaan kunnen worden op het vlak van industriestandaarden voor 'integratie met/binnen het voertuig' en 'executie-omgeving voor VIS appicaties'. Werkgroep 3 heeft ook onderzocht welke randvoorwaarden en aanbevelingen gelden om de toepassing op een veilige en effectieve wijze te laten interacteren met de gebruiker (veelal de bestuurder van een auto). Naast het afleiden van specificaties die een belangrijke marktdoelstelling van het project borgen, hebben een aantal Werkgroepen afspraken gemaakt over de wijze waarop belangrijke toekomstige werkzaamheden in het project moeten worden georganiseerd: -

Werkgroep 4: monitoring en evaluatie; Werkgroep 4: deelnemerswerving en –communicatie; Werkgroep 4: teststrategie en –faciliteiten.

Werkgroep 5 heeft het uitgangspunt horizontalisering beetgenomen en middels een analyse van het business model en exploitatie/transitie aspecten vertaald naar randvoorwaarden voor de koppelvlakken en specificaties van niet-technische en operationele aspecten (het procedurele en contractuele niveau) van de Spookfiledienst. Samenvattend kunt u in de volgende hoofdstukken de resultaten van de volgende Werkgroepen terug vinden: -

19

WG1: data-uitwisseling B2B WG2: informatie uitwisseling tussen CIS, RIS en VIS, connected en coöperatief WG3: HMI, in-vehicle integratie, VIS 'executie-omgeving' WG4: aandachtsgebied Monitoring en Evaluatie WG4: aandachtsgebied Teststrategie en -faciliteiten WG4: aandachtsgebied deelnemerswerving en -communicatie WG5: procedureel & Business Model en exploitatie aspecten WG6: coöperatieve wegkantstations: lokale hosting (transport van informatie onderdeel WG2) Privacy, veiligheid: opgepakt op Werkgroepniveau19

doelstelling om dit tijdens fase 2 horizontaal uit te werken


blz 46

Annex I: gerefereerde documenten De onderstaande lijst geeft een overzicht van de geraadpleegde documenten en informatiebronnen om te komen tot dit document. Ref. [1.] [2.]

[3.]

Aanduiding gerefereerde documentatie Middelham, Frans, ……… Vonk Noordegraaf, Diana., Freek Faber, Damir Vukovic, Filegoven binnen no time in beeld – Excelleren in detecteren, bijdrage aan het Colloquium Vervoersplanologisch Speurwerk, 24 en 25 september 20111, Antwerpen http://www.ctrack.nl/nc/ctrack-netherlands/nieuwsnl/nieuwsberichten/archive/2010/14/april/article/filegolven -bestrijden/

[4.]

Ministerie van Infrastructuur en Milieu, voortgang actieprogramma Beter geïnformeerd op weg: aanbieding Routekaart en Routeprojecten (brief van de Minister aan 2de kamer), 4 november 2013

[5.]

Suijs L.C.W. (2013) Phantom jam suppression through in-car speed advice – Master Thesis – Universiteit Twente – Goudappel Coffeng.

[6.]

Provincie Noord Brabant, SRE, I&M pBB, Leidraad Spookfiles A58, 1 november 2013, www.tenderned.nl

Annex II: afkortingen Een overzicht van gebruikte afkortingen. Afkorting

Betekenis

2,5G 3G 4G

GPRS, General Packet Radio Switched 3de generatie van mobiele telefonie technologie LTE, Long Term Evolution

ADAS

Advanced driver assistance system

FCD GPRS GSM

Floating Car Data, het inwinnen in de back-office van data die in eerste instantie via sensoren of een navigatiesysteem in het voertuig is ingewonnen Standaard voor mobiele data uitwissing Standaard voor mobiele telefonie, Global System for Mobile

HLA HMI ITS MTM OCD PIS RIS TDI VIS

High Level Architecture Human Machine Interface Intelligent Transport System Motorway Traffic Management systeem Operational Concept Description Personal ITS Station Roadside ITS Station Toeritdoseerinstallatie Vehicle ITS Station

CCH

Control Channel

SCH CAM DENM JAM TSM P1, P2, P3

Service Channel Cooperative Awareness Message Decentralized Environmental Notification Message Jam Advice Message Transparent Service Message Perceel 1, Perceel 2, Perceel 3


blz 47

Annex: Werkgroep 1


blz 48

Annex: Werkgroep 2


blz 49

Annex: Werkgroep 3


blz 50

Annex: Werkgroep 4 M&E


blz 51

Annex: Werkgroep 4 Testen Plan van Aanpak


blz 52

Annex: Werkgroep 4 Deelnemerswerving en -communicatie


blz 53

Annex: Werkgroep 5


blz 54

Annex: Werkgroep 6


blz 55

Spookfiles A58. OCD en Solution Design. Het gemeenschappelijke eindrapport (deliverable) van de Haalbaarheidsfase WP1 in het Spookfiles A58 Project

Recommend Documents