Eindrapportage. Wijzer op Weg velddemonstratie. Voor akkoord, Rijkswaterstaat AGI. Geverifieerd door, Technolution B.V. M. Dukker Project Manager

Wijzer op Weg velddemonstratie

Eindrapportage

Geverifieerd door, Technolution B.V.

Voor akkoord, Rijkswaterstaat AGI

M. Dukker Project Manager

A. de Hoog Projectleider

Wijzer op Weg velddemonstratie Eindrapportage

Documentinformatie: Titel Klant Auteur(s) Versie Datum File Project Projectnummer

: : : : : : : :

Operational Concept Description Rijkswaterstaat AGI Winifred Roggekamp 1.0 29 november 2005 Eindrapportage Wijzer op weg v1.0.doc Wijzer op Weg velddemonstratie RTD04010

Documentversies: Versie 0.1 0.2 0.3

Datum 10/11/05 21/11/05 22/11/05

Auteur WRO WRO WRO

0.4 1.0

29/11/05 30/11/05

WRO WRO

Commentaar Initiële versie (inhoud definitie) Inhoudelijk initiële versie Verwerken opmerkingen AZO, WBO stylecheck en interne review Verwerken opmerkingen Aad de Hoog Definitief maken van document

Review

Stijl

MDU

SHA

SHA

Documentdistributie: Rijkswaterstaat Aad de Hoog Coen Raaphorst TTACT Intern Marika Hoedemaeker Allard Zoutendijk Willem van den Bosch Marcel Dukker Winifred Roggekamp

Dit rapport is gemaakt door: TTACT p.a. Technolution B.V. Zuidelijk Halfrond 1 P.O. Box 2013 2800 BD Gouda The Netherlands Tel. +31(0)182 59 40 00 Fax +31(0)182 53 97 36 www.technolution.nl © RWS AGI Informatie uit dit rapport mag zonder toestemming worden gedupliceerd en / of worden gebruikt mits er een bronvermelding (RWS-AGI) wordt opgenomen.

Technolution B.V. datum : 29 november 2005 versie : 1.0

pagina i


INHOUD 1.

INLEIDING ........................................................................ 1

1.1 1.2 1.3

Context ............................................................................................... 1 Leeswijzer .......................................................................................... 1 Gerefereerde documenten ................................................................. 2

2.

SAMENVATTING .............................................................. 3

3.

WIJZER OP WEG, HET PROJECT ................................... 5

3.1 3.2

Projectopzet ....................................................................................... 5 Ontwerp .............................................................................................. 6

3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7

3.3 3.4 3.5

4.

Brongegevens ......................................................................................... 6 Hardwarekeuzes...................................................................................... 7 Softwareontwerp...................................................................................... 9 Geboden diensten ................................................................................. 10 Interactie tussen de verschillende diensten............................................ 11 Testen van de software ......................................................................... 12 Softwareonderhoud ............................................................................... 13

Velddemonstraties ........................................................................... 13 Onderzoeken .................................................................................... 14 Afronding ......................................................................................... 14

VELDDEMONSTRATIE................................................... 15

4.1

Verloop ............................................................................................. 15

4.1.1 4.1.2 4.1.3

4.2

Technische zaken ............................................................................ 17

4.2.1 4.2.2 4.2.3 4.2.4

4.3 4.4

5.

In- en uitbouw van de systemen ............................................................ 15 Helpdesk ............................................................................................... 16 Gereden uren en afstand ....................................................................... 16 Gebruik van COST-hardware ................................................................. 18 Gebruik van GPS................................................................................... 18 Werklastbepaling ................................................................................... 18 Brongegevens ....................................................................................... 19

Operationele aspecten..................................................................... 19 Organisatorische aspecten ............................................................. 20

CONCLUSIE GEBRUIKERSONDERZOEK ..................... 21

5.1

Onderzoeksvragen met hun antwoorden ........................................ 21

5.1.1 5.1.2

5.2 5.3 5.4

6. 6.1

Antwoord op onderzoeksvraag 1............................................................ 21 Antwoord op onderzoeksvraag 2............................................................ 21

Aanbevelingen uit het gebruikersonderzoek .................................. 21 Algemene conclusie van de onderzoeker ....................................... 22 Verbeteringen voor het gebruikersonderzoek ................................ 23

CONCLUSIE BUSINESSCASE ....................................... 24 Onderzoeksvragen ........................................................................... 24

TTACT datum : 29 november 2005 versie : 1.0

pagina ii


6.2 6.3 6.4

Samenvatting ................................................................................... 24 Conclusies ....................................................................................... 25 Aanbevelingen ................................................................................. 26


pagina iii


1. INLEIDING 1.1 Context Begin 2004 heeft de Rijkswaterstaat een aanbesteding gedaan voor het uitvoeren van een velddemonstratie. Deze aanbesteding maakt onderdeel uit van de realisatiefase van de pilot, “Wijzer op Weg”. De uitvoering van de Wijzer op Weg velddemonstratie is gegund aan TTACT. TTACT staat voor “Technolution, TNO en ARS Car Technology” en is een bundeling van de krachten van Technolution B.V., ARS Traffic & Transport Technology en TNO. Door de inbreng van ieders eigen unieke expertise kwamen zij tot een krachtdadige samenwerking voor de uitvoering van de velddemonstratie van Wijzer op Weg. Als resultaat van deze velddemonstratie heeft TTACT de volgende documenten opgeleverd: • Businesscase, die ingaat op vraagstukken rondom het vermarkten van voertuiggebaseerde Dynamisch Verkeers Management (vDVM). • Het gebruikersonderzoek, dat de belevingsresultaten van de berijders in de uitgevoerde velddemonstratie beschrijft en daar conclusies uit trekt. • De eindrapportage, die terugkijkt op het project, gezien vanuit de opdrachtnemer en daar conclusies en aanbevelingen uit trekt. Het document dat voor u ligt, de eindrapportage, is de koppeling tussen de businesscase en het gebruikersonderzoek. In dit document zal kort worden ingegaan op zowel de businesscase als het gebruikersonderzoek. Detaillering hiervan is te vinden in de overeenkomstige documenten (zie resp. [Businesscase] en [Gebruikersonderzoek]). Tevens zal dit document een aantal aspecten belichten die niet bij het gebruikersonderzoek of de businesscase behoren. De eindrapportage geeft inzicht in de projectinrichting, –uitvoering en beschrijft technische aspecten vanuit de gehouden velddemonstraties.

1.2 Leeswijzer In hoofdstuk 2 is de samenvatting opgenomen die de algehele conclusie en aanbevelingen vanuit de velddemonstratie, het gebruikersonderzoek en de businesscase beschrijft. Hoofdstuk 3 zal in het kort de opbouw van het project beschrijven. In hoofdstuk 4 zal het verloop van de velddemonstratie worden beschreven. Hoofdstuk 5 zal een korte samenvatting geven van de bevindingen vanuit het gebruikersonderzoek. Ten slotte worden in hoofdstuk 6 de conclusies en aanbevelingen van de businesscase in het kort beschreven.

TTACT datum : 29 november 2005 versie : 1.0

pagina 1


1.3 Gerefereerde documenten [Gebruikersonderzoek]

[Businesscase]

[Bestek]

[SSDD]


Rapportage Velddemo wijzer op weg Versie 1.0, 23 november 2005 TTACT Wijzer op Weg Businesscase Versie 1.0, 23 november 2005. TTACT Wijzer op Weg, Een pilot met geïndividualiseerde verkeersbeheersingsmaatregelen in het voertuig. Publicatie: 2004/S 104-085204, RWS AGI SSDD Wijzer op Weg Versie 1.01, 29 november 2004 TTACT

pagina 2


2. SAMENVATTING Begin 2004 heeft de afdeling “Wegen naar de toekomst” van Rijkswaterstaat een aanbesteding gedaan voor het uitvoeren van een velddemonstratie. Deze aanbesteding maakt onderdeel uit van de realisatiefase van de pilot, “Wijzer op Weg”. Het doel van deze pilot was: • Het demonstreren dat het presenteren van geïndividualiseerde, op maat gesneden, verkeersmanagementinformatie in het voertuig op een veilige manier mogelijk is. • Het demonstreren dat de interactie tussen verkeersmanagementtoepassingen en Infotainmentdiensten in de auto, dusdanig kan worden geïmplementeerd dat verkeersveiligheid niet in het geding komt. • Het inzichtelijk krijgen van hetgeen op termijn nodig zou zijn om tot implementatie van deze toepassingen en diensten te kunnen overgaan. Met verkeersveilig wordt hier bedoeld dat het gebruik van het systeem niet mag leiden tot gevaarlijke situaties. Bij de uitvoering van het project is daarnaast onderzocht hoe automobilisten omgaan met de verandering in de wijze van geïnformeerd worden. Het Wow-systeem is door TTACT ontworpen en daarna gebouwd. Als eerste is het Wijzer op Weg systeem getest in een rijsimulator. Hierin is de veiligheid van het systeem aangetoond. Hierna is het systeem gedurende twee velddemonstraties van ieder 6 weken ingebouwd geweest in, in totaal 2x20 voertuigen. De velddemonstratie heeft plaatsgevonden in het geografische gebied Amsterdam – Amersfoort – Gorichem – Rotterdam. Tijdens de velddemonstraties zijn gegevens gelogd in het Wow-systeem zodat naderhand het gedrag van het systeem en van de berijders onderzocht kon worden. Deze informatie heeft de basis gevormd voor het gebruikersonderzoek. De projectresultaten zijn opgenomen in een drietal documenten: • Businesscase (zie [Businesscase]), die ingaat op vraagstukken rondom het vermarkten van voertuiggebaseerde Dynamisch Verkeers Management (vDVM). • Het gebruikersonderzoek (zie [Gebruikersonderzoek]), die de belevingsresultaten van de berijders in de uitgevoerde velddemonstratie beschrijft en daar conclusies uit trekt. • De eindrapportage, die terugkijkt op de het project, gezien vanuit de opdrachtnemer en daar conclusies en aanbevelingen uit trekt. In onderstaande alinea’s is een korte samenvatting gegeven onderzoeksresultaten van bovengenoemde drie documenten.

van

de

Uit het gebruikersonderzoek blijkt zeer duidelijk dat het geven van gerichte en juiste informatie aan bestuurders van voertuigen, zal leiden tot een rustiger rijgedrag van de bestuurder en het beter gaan benutten van de weg.


pagina 3


Bestuurders van voertuigen met het Wijzer op Weg systeem geïnstalleerd, gaan rustiger rijden en maken bewustere keuzes bij het plannen van de route. Uit de businesscase blijkt dat het introduceren van een voertuiggebonden dynamisch verkeersmanagement zoals het Wijzer op Weg systeem, haalbaar is. Hiermee sluiten de resultaten van beide onderzoeken goed op elkaar aan. De businesscase stelt echter wel dat het door RWS zelf op de markt zetten van een systeem met weginformatie geen haalbare zaak is. Er dienen vanuit EU-verband standaarden opgezet te worden waarbij de overheid de markt stimuleert tot ontwikkelingen in het kader van vDVM. Het aan de weggebruiker tonen van de informatie moet geschieden via systemen van marktpartijen die voor dit soort informatie een infrastructuur hebben liggen of gaan aanleggen. Dit in nauwe samenwerking met de overheid. Te denken valt hier aan producenten van navigatiesystemen of aan leveranciers van voertuigen met daarin geavanceerde boardcomputers. In de toekomst moet dit leiden tot een kale weg zonder bijvoorbeeld borden en matrixsignaalgevers. Op dat moment is het financieel interessanter ten opzichte van een weggebondenverkeersmanagementsysteem met bv. matrixsignaalgevers. De gehouden velddemonstratie, met het daaruit volgende gebruikersonderzoek en de businesscase, heeft veel bruikbare informatie opgeleverd. Eventuele vervolgtrajecten zouden bijvoorbeeld meer kunnen inzoomen op het meten van de mate van beïnvloeding van de weggebruiker ten gevolge van de getoonde informatie. Cruciaal is echter de beschikbaarheid én de kwaliteit van de benodigde data en meetgegevens. Dit is een technisch aspect dat in nieuwe projecten zeker moet worden geadresseerd.


pagina 4


3. WIJZER OP WEG, HET PROJECT 3.1 Projectopzet De velddemonstratie met het Wijzer op Weg systeem is uitgevoerd door een consortium van drie bedrijven: Technolution, TNO en ARS T&TT. De voor het project noodzakelijke activiteiten waren in tien verschillende werkpakketten ondergebracht. Aan de verschillende werkpakketten werd door één of meerdere partners gewerkt. Voor elk werkpakket was echter één partner verantwoordelijk. Het project was verdeeld in de volgende werkpakketen: 1. projectmanagement, PR en disseminatie (Technolution); 2. ontwerp (ARS T&TT); 3. bouw walkantinfrastructuur (Technolution); 4. bouw diensten (Technolution); 5. bouw in-car infrastructuur (Technolution); 6. productie en inbouw (ARS T&TT); 7. velddemonstratie (ARS T&TT); 8. kwaliteitsborging (TNO); 9. gebruiksonderzoek (TNO); 10. businesscase (ARS T&TT).


pagina 5


De indeling van de verschillende werkpakketten (WP) en de fasering van het project worden in de navolgende figuur schematisch weergegeven waarin de relaties tussen de werkzaamheden en werkpakketten zijn uitgezet in de tijd. Systeemontwerp (WP2)

testplan

Bouw Infra (WP3)

Bouw Diensten (WP4)

Bouw In-car (WP5)

Prototype In-car systeem & diensten Rijsimulator Tests (WP8)

TIJD

In-car systeem, diensten en infrastructuur Businesscase (WP10)

Gebruikersonderzoek (WP9)

rework

Acceptatietest (WP8)

Productie, inbouw & integratie (WP6)

Velddemonstratie (WP7)

Conclusies en disseminatie (WP1)

Figuur 1: stroomschema Wijzer op Weg

3.2 Ontwerp Bij aanvang zijn de aan het Wow-systeem te stellen eisen verder uitgewerkt en gedetailleerd. Het eisenpakket is vervolgens vertaald in een systeemontwerp. Het ontwerp van de software en de requirements worden uitgebreid besproken in het door TTACT opgestelde ontwerp (zie [SSDD]).

3.2.1 Brongegevens Bij het project is een aantal informatiebronnen gebruikt. Hierbij is in een aantal gevallen afgeweken van de voorgestelde werkwijze van het bestek. De belangrijkste verandering als gevolg hiervan zijn opgenomen in onderstaande alinea’s: MTM-informatie Het doel van de proef is mede om te kijken of we de wegbenutting kunnen verhogen. Daarvoor zijn actuele rijtijden nodig. In het bestek staat een aantal scenario’s beschreven waarin bijvoorbeeld de afstand tot de staart van de file bekend moet zijn. Hiervoor zijn wel nauwkeurige data nodig die op tijd beschikbaar zijn. Deze informatie wordt in Nederland geleverd door de verkeerscentrale Nederland. Het was al tijdens het maken van het softwareontwerp duidelijk dat de informatie vanuit de lussen (Monica), een


pagina 6


vertraging van 1 tot 3 minuten heeft voordat het beschikbaar komt. Deze tijdsvertraging is te lang om de staart van de file te kunnen detecteren. Een voertuig met een snelheid van 120 km/h legt in deze tijd namelijk 6 kilometer af! Door deze tijdsvertraging zijn er andere type applicaties ontwikkeld. Het detecteren van de staart van de file, met de daar aangekoppelde werklast voor de bestuurder, is niet geïmplementeerd. Hiervoor in de plaats is een dienst ontwikkeld die op de voorliggende route aangeeft wat de standen van de matrixsignaalgevers zijn. Hierdoor heeft de bestuurder toch inzicht in de verkeerssituatie. Verkeersborden Voor de ontwikkeling van het Wijzer op Weg systeem zijn nog meer databronnen gebruikt. Eén van de diensten toont de verkeersborden. De overheden hebben echter nauwelijks (digitale) bestanden waarin alle geplaatste borden staan. Van een aantal plekken was er data beschikbaar, maar dit was zeer weinig ten opzichte van het totaal aantal borden langs de weg. De beschikbare borden zijn getoond, maar voor de deelnemers is het effect van het tonen van een deel van de verkeersborden verwarrend. Voor een dienst als deze dient er voldoende informatie beschikbaar te zijn. DRIP-informatie Eén van de diensten was het tonen van DRIP (Dynamische route informatie paneel) informatie. Het is tijdens het ontwikkelen van de software lange tijd onduidelijk geweest of deze informatie beschikbaar zou komen. Uiteindelijk is de applicatie wel ontwikkeld, maar kon de verkeerscentrale Nederland op het moment van de velddemonstratie deze informatie nog niet leveren.

3.2.2 Hardwarekeuzes Er is besloten om het geheel op te bouwen met vrij verkrijgbare hardware. Aangezien het om slechts 20 functionele systemen gaat, is het in dit geval kostentechnisch gezien niet efficiënt om eigen hardware te ontwikkelen. Vooral de grootte van het scherm en de flexibiliteit van een “gewoon” pc-systeem heeft geleid tot de keuze voor een embedded pc-platform. Op het systeem is voor Windows XP Embedded als operating system gekozen. Hierdoor wordt het ontwikkelen en met name testen van applicaties vereenvoudigd.

Figuur 2: in-car pc

Het systeem is door middel van een speciale omvormer aangesloten op de boordspanning van de auto. De omvormer is nodig voor de volgende zaken: • continue spanningsvoorziening, ook bij starten motor; Technolution B.V. datum : 29 november 2005 versie : 1.0

pagina 7

Wijzer op Weg velddemonstratie Eindrapportage • •

in- en uitschakelen van de Wijzer op Weg pc; inschakel- en uitschakelvertraging, om onnodig opstarten en afsluiten van de pc te voorkomen.

Voor de positiebepaling is gekozen voor een moderne general purpose GPSontvanger van het merk Navilock. In ons geval hebben we deze door middel van USB op de Wijzer op Weg hardware aangesloten. Deze GPS-ontvangers geven snel de positie van het voertuig doordat ze de laatste positie in hun interne geheugen houden. Tevens maken ze gebruik van de moderne detectietechnieken. Om een dataverbinding met de server te maken, is gekozen voor GPRS. Een belangrijke reden is daarbij de dekkingsgraad, de verkrijgbaarheid van componenten en de kosten. GPRS is een point to point communicatie medium. Dit betekent dat informatie die normaal middels een broadcast verstuurd kan worden, nu specifiek naar iedere auto moet worden gestuurd. Het GPRSmodem dat is gebruikt is van Siemens. Dit modem heeft zijn sporen al ruim verdiend in andere projecten. In het modem is een SIM-kaart gestoken met een standaard GPRS-databundel. Gezien de beperkte bandbreedte moest in het ontwerp rekening worden gehouden met een gelimiteerde hoeveelheid dataverkeer. Er is gekozen voor een standaard serveroplossing voor de invulling van het walkantsysteem. De belasting voor de server blijft laag door het beperkte aantal deelnemers in de proef. Wel moet rekening gehouden worden met een beschikbaarheidvraag om te garanderen dat het systeem correct en stabiel functioneert gedurende de velddemonstraties. Aangezien de duur van het project beperkt is en de standaard serveroplossingen betrouwbaar genoeg zijn, hoeft hier geen speciale state-of-the-art server te worden gebruikt. Omdat hergebruik van software binnen dit project belangrijk is, hebben we besloten om twee servers aan te schaffen. Eén speciaal voor de specifieke Wijzer op Weg website en communicatie en de andere als verkeersinformatieserver. Deze tweede is een 100% kopie van een reeds bestaande verkeersinformatieserver.


pagina 8


3.2.3 Softwareontwerp De software voor het Wijzer op Weg systeem bestaat uit twee delen: in-car en server. Wijzer op Weg applicaties kunnen draaien op het in-car systeem of op de server. Bij sommige applicaties (of diensten) draait een deel van de functionaliteit op de server en een deel op het in-car systeem. Een voorbeeld hiervan is de dienst die de verkeerssignalering boven de weg visualiseert op het Wijzer op Weg systeem. Deze dienst draait in-car en zal daar bepalen waar de auto zich bevindt en welke route er gekozen is en op de server een aanvraag doen van de toestand van de verkeerssignalering op deze route. Het gedeelte op de server kan dan aan de hand van de gegeven route de juiste data uit de serverdatabase halen en deze informatie naar het in-car systeem versturen.

In-Car platform

GPRS

On Shore platform

De communicatie tussen het in-car systeem en de server wordt verzorgd door een communicatiesysteem (CS). Dit systeem zorgt Application 1 (in-car) Application N (in-car) voor communicatie tussen de verschillende in-car diensten en tussen de in-car dienst en de App-CS App-CS serverdienst. Het communicatiesysteem kent een z.g. publish – subscribe mechanisme. Een voorbeeld waar dit wordt gebruikt is bij de GPSCommunication System (in-car) driver. Deze driver publiceert iedere seconde de huidige positie en snelheid. Andere diensten zoals CS-CS interface de navigator, werklastschatter enz. abonneren zich dan op deze data en krijgen hierna automatisch de Communication System (On Shore) GPS-informatie naar hun toe gezonden. Op deze manier worden de verschillende diensten van App-CS App-CS elkaar los getrokken en kunnen eenvoudig meerdere diensten tegelijkertijd ontwikkeld en Application 1 (Shore) Application N (Shore) separaat getest worden. Voor news dienst was het uitspreken van nieuwsheadlines nodig. Voor het uitspreken van teksten is speciale text-to-speech software nodig. Deze software is dusdanig specifiek dat besloten is om de software in te kopen. Hierbij moet wel rekening worden gehouden met de benodigde kwaliteit. Zeker op het gebied van text-to-speech wordt zeer uiteenlopende kwaliteit van software aangeboden. Voor het Wijzer op Weg systeem is het meest kwalitatieve softwarepakket aangeschaft en gebruikt. Voor de navigator geldt dat de basis van een goede navigator goed kaartmateriaal is. TTACT heeft gekozen voor TeleAtlas-kaartmateriaal omdat zij daar goede ervaringen mee heeft. Voor de deelnemers aan de Wijzer op Weg velddemonstratie is er een website gemaakt waar o.a. een agenda kan worden bijgehouden en gegevens van de ritten kunnen worden opgevraagd. Door middel van het communicatiesysteem kan iedere auto contact maken met de server om daar zijn informatie op te slaan of van af te halen. Er is voor gekozen om de diensten op de server en in de auto naadloos op elkaar te laten aansluiten. Zo komt er, indien een deelnemer in zijn Technolution B.V. datum : 29 november 2005 versie : 1.0

pagina 9


auto stapt en een route wil selecteren, automatisch een extra bestemmingsselectiemogelijkheid bij indien de deelnemer vooraf een afspraak in zijn agenda heeft gemaakt. Hierdoor heeft de deelnemer beschikking over relevante agenda-informatie tijdens het instellen van de bestemming. Ook dynamische data zoals de actuele rijtijden of standen van de matrixsignaalgevers worden via de server en het communicatiesysteem doorgegeven aan de auto’s. Door deze laatste datastroom is het mogelijk om de bestuurder continue de snelste route te bieden, rekening houdend met actuele rijsnelheden. Bovenstaande is slechts een samenvatting van het Wow-ontwerp. Het volledige ontwerp van de software wordt uitgebreid besproken in het door TTACT opgestelde [SSDD].

3.2.4 Geboden diensten Binnen het project is een aantal diensten ontwikkeld waar de bestuurder gebruik van kan maken. Het betreft hier de volgende diensten: In • • • • • • • • • •

de auto: Routenavigatie, basisuitvoering van een routenavigator; Verkeersinformatie, informatie met betrekking tot files; Verkeersbordeninformatie, tonen van verkeersborden afhankelijk van de positie van het voertuig; Bewegwijzering, tonen bij volgen van geplande routes; Points of interrest: deze dienst laat interessante plaatsen op de kaart zien; Scherpe bochtwaarschuwing; DRIP-informatie: deze dienst laat de informatie van de dynamische routepanelen boven de weg zien; Matrixsignaleringsinformatie: deze dienst laat op de aankomende vijf kilometer van de route de toestand van de matrixsignaalgevers zien; Maximumsnelheid: deze dienst laat de huidige maximumsnelheid zien. Bij een maximumsnelheidsoverschrijding zal er een audiosignaal worden gegeven; Nieuwsheadlines: deze dienst leest actuele nieuwsheadlines voor, van configureerbare thema’s.

Op de server: • Webagenda, mogelijkheid om agenda elektronisch bekend te maken aan het Wow-systeem als basis voor te plannen routes gedurende een dag; • SMS-dienst: dienst die een waarschuwing geeft als de berijder t.g.v. een file eerder moet vertrekken om op tijd op zijn afspraak te zijn (relatie met agenda); • Tonen van historische en actuele positiegegevens (tracinginformatie); • Zichtbaar maken van kilometerregistratiegegevens; • Zichtbaar maken van “floating car data”: bepalen van rijsnelheid op een bepaald stuk weg, dat vervolgens voor het routen van alle andere auto’s kan worden gebruikt.


pagina 10


3.2.5 Interactie tussen de verschillende diensten Het scherm van het systeem in de auto is verdeeld in drie delen: het linkergedeelte, het rechtergedeelte en de knoppenbalk die zich linksonder bevindt. Hiernaast beschikt het systeem ook over een audiokanaal. Deze verschillende informatiekanalen worden door de verschillende diensten gedeeld. Het Wijzer op Weg systeem heeft een ingebouwd mechanisme om ervoor te zorgen dat de geboden informatie, de bestuurder niet teveel afleidt dat dit de verkeersveiligheid negatief beïnvloedt. Om dit te doen maakt het Wijzer op Weg systeem een inschatting van de huidige werklast van de bestuurder. Hierbij is gebruik gemaakt van het product CoDrive (of Bibi) ontwikkeld door TNO TM. Bijvoorbeeld als een file wordt genaderd heeft de bestuurder alle aandacht nodig voor de weg en is de werklast dus hoog. Op dat moment is het niet verstandig om omgevingsinformatie op te vragen. Dit kan dan beter uitgesteld worden tot de auto daadwerkelijk in de file staat. Het Wijzer op Weg systeem regelt de toegang van de verschillende informatiebronnen (diensten). Informatie wordt alleen getoond indien dit voor de bestuurder niet een te hoge werklast oplevert. Daarnaast is het zo dat verschillende informatie ook een verschillende mate van belangrijkheid (prioriteit) heeft. Alleen de meest belangrijke informatie, die niet een te hoge werklast veroorzaakt, zal worden getoond. Sommige diensten kunnen afhankelijk van de werklast, verschillende schermen tonen. Door de hoeveelheid informatie te verminderen wordt de benodigde werklast verminderd. Het kan dus voor komen dat de dienst informatie wil tonen, maar hiervoor geen toestemming krijgt om dit te doen. Door nu een scherm met een lagere werklast aan te bieden, kan de dienst toch de gewenste informatie tonen. Een voorbeeld hiervan is de routenavigator die een scherm met een uitgebreide kaart en met een eenvoudige pijl heeft. Bij voorkeur laat de dienst de uitgebreide kaart zien, maar als de toegestane werklast af neemt, kan de navigator het scherm met de pijl tonen. Om te zorgen dat de werklast binnen een acceptabel niveau blijft kan het Wijzer op Weg systeem er ook voor zorgen dat sommige knoppen op het menu niet bediend kunnen worden. Het kan dus zo zijn dat een knop gedurende een bepaalde periode (bijvoorbeeld bij het naderen van een file) niet bediend kan worden. Nadat de hoge werklast weer is weggenomen (eenmaal in de file) kan de knop weer bediend worden. Een knop die niet bediend kan worden zal grijs worden. Een voorbeeld hiervan is de menuknop. Deze kan alleen bediend worden indien de bestuurder geen verkeershandelingen hoeft te doen en dus stil staat. Het Wijzer op Weg systeem voorkomt ook dat schermen te snel achter elkaar wisselen. Dit houdt in dat het soms enkele seconden kan duren voor een met de knop aangevraagde dienst daadwerkelijk verschijnt. Voor de gebruiker kan dit vreemd overkomen en dat dient dus uitgelegd te worden.


pagina 11


Ter ondersteuning aan het gebruikersonderzoek heeft het systeem een uitgebreide log gemaakt. Hierin staan voornamelijk de acties van de hier beschreven werklastarbiter. Deze geeft namelijk aan welke informatie de deelnemer heeft geconsumeerd en/of heeft opgevraagd.

3.2.6 Testen van de software Essentieel bij de ontwikkeling van een systeem als deze is het testen van: • de juist werking van de software • de veiligheid voor de gebruiker van het systeem Om de juiste werking van het gehele systeem te testen is het systeem in modules gemaakt. Reeds in het ontwerp is ervoor gezorgd dat de verschillende diensten en sub-systemen separaat te testen zijn. Aangezien de diensten door middel van het communicatiesysteem met elkaar communiceren, kan eenvoudig een z.g. stub worden gemaakt. Deze stub’s zorgen voor een simulatie van de buitenwereld van de te testen module (het overige systeem). Het vastleggen van de juiste interface is hierbij cruciaal geworden, maar maakt het tegelijkertijd ook mogelijk om de juistheid van een module aan te tonen. De verschillende diensten en sub-systemen zijn gefaseerd ontwikkeld en al in een vroeg staduim geïntegreerd. Hierdoor komen eventuele problemen vroeg aan het licht. Naast het simuleren van de buitenwereld van een module (in het systeem) is er ook een stub gebouwd die de buitenwereld van het systeem simuleert. Er zijn buiten het scherm, twee belangrijke connecties met de buitenwereld: GPRS en GPS. De verbinding naar de server, in het uiteindelijke systeem verzorgt door GPRS, hoeft niet gesimuleerd te worden. Hier kan OF de echte GPRSverbinding OF een standaard netwerkverbinding op basis van ethernet worden gebruikt. GPS (positionering) is echter wel van belang om te simuleren. Hiervoor is een GPS afspeeltool ontwikkeld. Deze tool kan niet alleen een opgenomen GPS-file afspelen, maar ook de snelheid van de gesimuleerde autoroute aanpassen. Hierdoor kunnen zaken als te hard rijden en werklastbepaling op basis van rijsnelheid eenvoudig getest worden. Tijdens de FAT-tests is deze simulatortool ook zeer nuttig gebleken. Door als het ware echte routes te rijden kan de werking van het systeem goed worden aangetoond. Na de interne FAT-tests is een aantal dagen in een demonstratievoertuig rondgereden (de SAT-tests) om het systeem in de praktijk te beproeven. Het testen van de veiligheid van het systeem kan maar gedeeltelijk door de ontwikkelde partijen worden gecontroleerd. Hiervoor is dan ook gebruik gemaakt van de kennis en apparatuur van TNO-menskunde. Zij bezitten een rijsimulator waar het Wijzer op Weg systeem in is getest. Een groep proefpersonen heeft in de rijsimulator met het systeem “rondgereden”. TNO heeft een rapport opgesteld waarin de veiligheid van het systeem is besproken. Uiteraard kan het systeem alleen in “echte” auto’s worden ingebouwd als het systeem veilig is.


pagina 12


3.2.7 Softwareonderhoud Ondanks alle tests is het reëel om aan te nemen dat er nog softwarefouten in het systeem zitten. De velddemonstratieperiode is slechts zes weken. Dit betekent dat een snelle reactie op storende fouten noodzakelijk is. Hiervoor moeten mensen en testsystemen beschikbaar zijn om de problemen op te sporen. Ook moet de eventuele aangepaste software eenvoudig in de verschillende systemen kunnen worden geplaatst. Voor dit laatste is een automatische updater ontwikkeld. Als een auto gaat rijden en het Wijzer op Weg systeem maakt verbinding met de server, wordt gecontroleerd of er nieuwe softwaremodules beschikbaar zijn. In dat geval worden ze automatisch, zonder dat de gebruiker daar last van heeft, op het in-car systeem gezet. Bij de volgende keer opstarten van het in-car systeem wordt de nieuwe softwaremodule geactiveerd.

3.3 Velddemonstraties De uitvoering van de velddemonstratie houdt in dat er in twee groepen, minimaal 40 deelnemers met het Wijzer op Weg systeem gaan rijden en ervaringen op gaan doen. Samen met Rijkswaterstaat is een gebied bepaald waarin de proef wordt gehouden. Aangezien informatie van de systemen langs de weg (lussen en matrixsignaalgevers) voornamelijk in de randstad aanwezig zijn, is voor een gebied in de cirkel van Amsterdam, Amersfoort, Utrecht, Gorichem, Rotterdam gekozen. Uiteindelijk zijn er niet veel verkeersborden getoond. Dit komt voornamelijk doordat niet alle borden in eenvoudig toegankelijke bestanden zijn opgeslagen, er weinig verkeersborden lans de snelwegen staan en er een selectie is gemaakt uit de N-wegen waar de borden worden getoond. Ook zijn niet alle verkeersborden getoond. Alleen een van te voren geselecteerde groep van borden is getoond. De deelnemers aan de velddemonstratie zijn geselecteerd met behulp van een leasemaatschappij. Deze leasemaatschappij heeft toestemming gegeven om contact op te nemen met enkele van hun klanten, waar we vervolgens zijn gaan werven. Hierbij is het juist inbouwen van de apparatuur van groot belang. Hiervoor is een gespecialiseerd bedrijf gebruikt. Deze waren in staat om 22 Wijzer op Weg systemen in een tijd van 1 à 1½ week in te bouwen. Tussen de twee velddemonstraties in, is langere ombouwtijd nodig. Eerst moeten de systemen uit de auto’s van de eerste velddemonstratieperiode worden gebouwd. Hierna moeten de systemen door TTACT worden klaargemaakt voor de nieuwe periode (verkrijgen van logfiles, settings voor nieuwe deelnemers instellen), waarna de systemen weer ingebouwd kunnen worden. Hier is gedeeltelijk parallel gewerkt. Uitgebouwde systemen zijn in badges naar TTACT verstuurd en klaargemaakt, terwijl de laatste systemen nog uitgebouwd werden. Op deze manier kon alvast worden begonnen met het inbouwen van de reeds klaargemaakte systemen. Door deze aanpak was het mogelijk om binnen drie weken alle systemen vanuit de eerste groep deelnemers om te bouwen naar de tweede groep deelnemers.


pagina 13


Na de inbouw heeft het inbouwbedrijf een korte uitleg van het systeem gegeven. Op deze namier zijn de deelnemers alvast een beetje op weg gebracht met het systeem. Ook hebben de deelnemers na de inbouw de gebruikershandleiding en een “quick reference” kaart gekregen. De behoefte aan een “quick reference” kaart bleek vanuit de eerste velddemonstratieperiode. Om deze reden is deze gemaakt en bij de tweede velddemonstratieperiode uitgedeeld.

3.4 Onderzoeken In de uitvoering van het project zitten twee onderzoeken: het gebruikersonderzoek en de businesscase. Deze zullen in respectievelijk hoofdstuk 5 en hoofdstuk 6 worden behandeld.

3.5 Afronding Ter afronding van het project zijn de conclusies uit het gebruikersonderzoek en de businesscase samengevoegd tot één algehele conclusie. Dit gebeurt in deze eindrapportage. Ter afronding van het project zijn de drie documenten opgeleverd.


pagina 14


4. VELDDEMONSTRATIE Dit hoofdstuk beschrijft als eerste het verloop van de velddemonstratie. In de daaropvolgende paragrafen worden specifieke zaken van de velddemonstratie belicht en eventueel aangevuld met aanbevelingen voor volgende soortgelijke projecten.

4.1 Verloop 4.1.1 In- en uitbouw van de systemen Het inbouwen van de systemen moet goed en professioneel gebeuren. De moeilijkheid is dat: 1. er moet worden ingebouwd in bestaande voertuigen; 2. de deelnemers geen (zichtbare) schade aan hun auto willen hebben. Als aan punt 2 niet wordt voldaan, zal de deelnemer al voor het starten van de proef ontevreden zijn. Dit heeft zeker invloed op de resultaten van het gebruikersonderzoek. Daarnaast is het een proef die een beperkte doorlooptijd heeft en dus moet de auto na de proef weer in de oude staat worden teruggebracht. Het bevestigen van beugels d.m.v. schroeven aan het dashboard is dan ook geen optie. Bij het inbouwen in bestaande voertuigen kom je bij iedere auto weer andere problemen tegen. Bij de selectie van de proefpersonen is niet geselecteerd op automerk en -type en dus is te verwachten dat iedere inbouw anders is. Technisch blijkt het plaatsen van de twee antennes (voor GPS en voor GPRS) soms lastig. Tijdens de proef bleek dat een aantal deelnemers regelmatig ontvangstproblemen hadden. De moderne auto’s hebben gecoate ruiten waardoor niet alleen de zon, maar ook radiosignalen worden tegengehouden. De plaatsing van met name de GPS-ontvangstantenne is dus van groot belang. Voor sommige auto’s is zelfs besloten om andere, kwalitatief betere, GPSontvangers te installeren. De exacte oorzaak van deze problemen is niet achterhaald. Aangezien in de regel hardwarematige problemen zich minder snel laten herstellen dan softwarematige is dit als gevolg van een korte velddemonstratieduur al snel belastend voor het onderzoek en de beleving van de bestuurder. Om allerlei storingen en spanningsvariaties van de boordspanning van de auto op te vangen, is er een spanningsomvormer toegepast. Deze zorgt voor een stabiele uitgangsspanning voor de Wijzer op Weg apparatuur. De door TTACT toegepaste omvormer bleek storingen te veroorzaken. Dit uitte zich in een storing op het audiokanaal van het beeldscherm. Deze uiting kwam niet bij alle systemen voor en is tijdens de interne tests, waar een stabiele voeding is gebruikt, niet aan het licht gekomen. De planning van het in- en uitbouwen is cruciaal. De gebruikersgroep moet zo veel mogelijk achtereen worden ingebouwd om de deelnemersgroep niet te veel in tijd uit te smeren. Tussen de twee periodes in moet rekening gehouden Technolution B.V. datum : 29 november 2005 versie : 1.0

pagina 15


worden met niet alleen de uitbouw en weer inbouw van de systemen, maar ook met het verzamelen van het log en het herconfigureren van de systemen. In ons geval moesten daarvoor de systemen terug naar TTACT. Door deze procedure kostte het ombouwen drie weken.

4.1.2 Helpdesk Tijdens beide velddemonstraties is de helpdesk actief geweest. Door middel van de gebruikershandleiding is de gebruiker geïnformeerd over de werking van het systeem. Het bestaan van de helpdesk is tevens in de gebruikershandleiding gemeld. Het bleek tijdens de eerste periode dat er weinig gebruik gemaakt werd van de helpdesk. De verwachting was dat dit kwam doordat het telefoonnummer van de helpdesk niet in de auto aanwezig was. De gebruikershandleiding lag waarschijnlijk thuis. Voor de tweede periode is een “quick reference” geïntroduceerd. Hierop staat in het kort de werking van het systeem en tevens het telefoonnummer van de helpdesk. Het aantal telefoontjes vanuit de auto is hierdoor toegenomen. Van de totaal 74 meldingen die bij de helpdesk zijn binnengekomen, zijn er 24 gebruikersvragen geweest, 40 stuks waren technische vragen of storingsmeldingen. Hierbij moet worden opgemerkt dat in de eerste periode niet alle gebruikersvragen goed zijn gedocumenteerd in het helpdesksysteem, zodat het totaal aantal meldingen en gebruikersvragen in werkelijkheid groter is geweest.

4.1.3 Gereden uren en afstand Tijdens de velddemonstratie is door middel van kilometerregistratie bijgehouden hoeveel uren de bestuurders in het proefgebied hebben gereden. Het blijkt dat veel deelnemers ruim 50 uur rijden hebben gehaald. Het gemiddelde over alle deelnemers is dan ook ruim over de minimaal vereiste 50 uur. Om de privacy van de deelnemers te waarborgen zijn geen namen vermeld. Deelnemer 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13 1.14 1.15 1.16 1.17 Technolution B.V. datum : 29 november 2005 versie : 1.0

Totale reistijd 71:05:55 35:49:52 49:35:47 107:51:52 111:30:01 87:46:32 67:46:18 100:18:01 58:04:18 75:43:19 89:18:04 63:24:05 82:03:59 66:53:10 37:06:24 80:33:36 76:46:41

Totale afstand 5100,79 1623,57 2034,4 8398,16 8306,87 6421,88 3687,99 6900,29 3868,66 3398,83 5144,7 3753,46 4863,45 4391,28 1792,84 4930,22 4068,9 pagina 16


1.18 1.19 1.20 1.21 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.17 2.18 2.19 2.20 2.21 2.22

53:00:38 49:34:15 59:35:59 55:41:13 67:15:05 55:16:55 79:09:16 15:02:30 72:36:26 38:52:23 85:27:57 62:25:05 84:07:24 66:23:52 63:27:18 78:01:53 74:48:53 116:21:52 76:04:37 132:23:34 93:52:34 102:55:49 91:30:36 74:59:58 62:10:23

3057,71 2942,82 3660,47 7205,21 4522,32 3745,58 6802,46 1044,07 3799,02 2159,01 5708,96 4766,59 5940,04 4569,4 4206,09 6357,14 5825,31 8061,08 5480,97 9419,84 7482,4 7487,12 5580,02 5436,61 5560,63

Tabel 1: rijtijden deelnemers

Een aantal deelnemers heeft de 50 uur niet gehaald. Eén van de deelnemers heeft door ziekte van haar baas taken moeten overnemen waardoor ze niet zo veel meer op de weg zat. Een andere deelnemer is lange tijd ziek geweest en heeft daarom weinig gereden. Weer een andere deelnemer heeft opstartproblemen gehad die door het moeilijk kunnen maken van afspraken, pas laat zijn opgelost. Hij heeft echter in de laatste periode veel tijd goedgemaakt.

4.2 Technische zaken Het Wijzer op Weg project is duidelijk ingestoken als proef. Door middel van een velddemonstratie wil Rijkswaterstaat een aantal onderzoeksvragen beantwoord krijgen. Het is dus niet de bedoeling een mooi technisch systeem te maken, maar om een technisch systeem te maken waarmee de gestelde onderzoeksvragen beantwoord kunnen woorden. Het is echter moeilijk om de deelnemers aan de velddemonstratie hetzelfde inzicht te geven. Er is geselecteerd op kennis van navigatiesystemen. De bedoeling is om niet de proef te laten beïnvloeden door gebruiksproblemen. Het gevolg is echter wel dat de deelnemers een bepaald idee krijgen bij het geleverde systeem. Men verwacht minimaal een “state of the art” systeem, want, zo is de verwachting, “dit systeem kan meer dan mijn huidige navigator”.


pagina 17


Het Wow-systeem is echter anders ingestoken. Het Wow-systeem heeft een navigator omdat dit nodig is voor alle gewenste diensten en om de mensen te kunnen omleiden. De kwaliteit van deze navigator mag niet vergeleken worden met de huidige standaard van navigatiesystemen. Door deze misperceptie is een aantal deelnemers met een verkeerd beeld begonnen, wat uiteraard invloed heeft op hun individuele antwoorden op de onderzoeksvragen. Het zou beter zijn geweest om: of het nog duidelijker naar de deelnemers te communiceren, of om mee te liften met één van de navigatiesystemen die in de markt verkrijgbaar zijn. De mogelijkheden en kosten van deze tweede suggestie zijn niet door TTACT onderzocht.

4.2.1 Gebruik van COST-hardware Het gebruik van op de markt verkrijgbare hardware om het systeem op te laten draaien lijkt een snel gemaakte keuze. Ook hier geldt dat het in het licht van de proef een goede keus is. Het heeft echter wel gevolgen voor bijvoorbeeld de tijd die nodig is om het systeem op te starten. In het Wijzer op Weg systeem is gebruik gemaakt van een 1Ghz pc-systeem met Windows XP embedded als besturingssysteem. Het opstarten van dit systeem kost enige tijd. Huidige navigatiesystemen zijn binnen 5 seconden operationeel terwijl het Wow-systeem voor het opstarten van het besturingssysteem alleen al 30 tot 40 seconden nodig heeft. Ook hier geldt dat de deelnemers andere verwachtingen hebben en daarom dit als een probleem gaan zien.

4.2.2 Gebruik van GPS Voor de positiebepaling is gebruik gemaakt van GPS. De GPS-ontvanger meet ook de snelheid van het voertuig. Dit is één van de ingangsparameters van de werklastschatter. De snelheidsmeting door middel van GPS is echter niet nauwkeurig. Indien de ontvangst slecht is, zal de gemeten snelheid 0 worden. Voor de werklastschatter houdt dit in dat de bestuurder alles op het systeem mag doen want de auto staat stil. Het gebeurt echter ook dat dit voorkomt in tunnels en andere slechte GPS-ontvangstsituaties. Hierdoor kan de veiligheid van de berijder in gevaar komen. Uiteraard zal de bestuurder zelf moeten inschatten of hij, gezien de wegsituatie, tijd heeft om het Wijzer op Weg systeem te bedienen. Andersom geldt ook dat een GPS-ontvanger een bepaalde nauwkeurigheid heeft en dat daar rekening mee gehouden moet worden. Het bepalen of de auto stilstaat kan niet door naar een snelheid van 0 km/h te kijken. Het gebeurt nl. weleens dat, ondanks dat de auto stilstaat, de GPS-ontvanger even 1 km/h aangeeft. Om deze reden moet de grens van wel of niet rijden en daarmee het uitschakelen van diensten met een zeer hoge werklast, worden verlegd naar bijvoorbeeld 5 km/h.

4.2.3 Werklastbepaling Het gebruik van CoDrive (of Bibi) voor het inschatten van de werklast en het regelen van de toegang naar de informatiekanalen (scherm en audio) is goed bevallen. Meerdere diensten die allemaal hun informatie aan de gebruiker willen tonen, worden netjes en op de juiste tijd aan de beurt gelaten. Een prioriteitssysteem zorgt voor de juiste volgorde van tonen. Een werklastschatting


pagina 18


zorgt voor dat de bestuurder niet overladen wordt met informatie. Wel heeft zo’n systeem als nadeel dat sommige informatie niet getoond kan worden. Er is voor een dienst maar één plek op het scherm beschikbaar en meerdere diensten moeten hier gebruik van maken. Vooral informatie die maar een beperkte tijdsduur heeft, zoals het tonen van borden, kan hierdoor soms niet getoond worden. De optie om alle informatie tegelijkertijd te tonen strookt niet met het veilig brengen van informatie.

4.2.4 Brongegevens De actuele rijsnelheid van de voertuigen op een bepaald weggedeelte is in deze proef verkregen via de verkeerscentrale Nederland (VCNL). Zoals reeds in paragraaf 3.2.1 beschreven, zijn deze data wel nauwkeurig, maar niet direct beschikbaar. Hierdoor is het niet mogelijk geweest een aantal diensten te realiseren. Een detectie van de filestaart kan bijvoorbeeld niet nauwkeurig genoeg worden bepaald om daar de berijder voor te waarschuwen. Het op een andere manier verkrijgen van de informatie was in het kader van deze proef niet mogelijk. Toekomstige systemen zouden bijvoorbeeld wel informatie direct vanuit de systemen aan de kant van de weg kunnen verkrijgen. Indien de meetstations langs de kant van de weg hun meetgegevens middels een radiosignaal zouden uitzenden, kunnen auto’s wel direct ingelicht worden waardoor een betrouwbare waarschuwing en werklastschatting mogelijk zijn. Een andere mogelijkheid is het door een voertuig die de file inrijdt laten versturen van een waarschuwing. Deze kan dan worden opgevangen door het achteropkomend verkeer en zodoende een waarschuwing geven aan de bestuurder. Beide concepten gaan uit van voertuig-wal communicatie of voertuig-voertuig communicatie. Zoals is beschreven in de businesscase zijn dit aspecten waarop Europees niveau standaarden voor moeten worden ontwikkeld. Een aantal diensten maakt gebruik van kaartmateriaal voor routenavigatie of maximum snelheidsbepaling. Met name de laatste informatiebron bleek gedurende de proef niet altijd 100% betrouwbaar waardoor in een aantal gevallen de bestuurder, onterecht, een snelheidswaarschuwing heeft gekregen. Over het algemeen kan gezegd worden dat de kwaliteit van de aangeleverde informatie voor een vDVM essentieel is voor de acceptatie en daarmee opvolging van de door het systeem geboden diensten.

4.3 Operationele aspecten Het blijkt dat het goed en nauwkeurig selecteren van de deelnemers meer inhoud dan alleen naar de ervaring en de beschikbaarheid van de deelnemers te kijken. De deelnemers aan de velddemonstratie moeten zich bewust zijn van het feit dat het om een proef gaat en misschien zelfs wel weten wat er exact met deze proef wordt onderzocht. Hierdoor kunnen perceptieproblemen over wat men mag verwachten niet 100% uit de weg worden gegaan, maar misschien wel worden verkleind. Het probleem is meestal dat bepaalde aspecten van het systeem nog niet bekend zijn tijdens de werving van de deelnemers. Het werven


pagina 19


van de deelnemers gebeurt op dezelfde tijd dat het systeem wordt ontwikkeld. Echte bottlenecks zijn dan nog niet boven water gekomen. Hoewel het in veel situaties niet mogelijk is, moet toch een ruime periode worden gekozen tussen het afronden van de ontwikkeling en het starten van de velddemonstratie. Deze zaken zijn nodig om uitloop op de ontwikkeling geen gevolg te laten hebben voor het uitvoeren van de proef. Het is zeer moeilijk om een aantal deelnemers die toe hebben gezegd mee te zullen doen te moeten uitleggen dat de proef in een andere periode wordt gehouden. In ons geval was een extra moeilijkheid dat de tweede proef tegen het begin van de vakanties afliep. Hierdoor kan een uitstel van één of twee weken betekenen dat de gehele velddemonstratieperiode na de vakantie moet worden gepland.

4.4 Organisatorische aspecten De uitvoering van de velddemonstratie lag bij één TTACT-partner. Deze stuurde het proces van deelnemerbegeleiding, in- en uitbouw, helpdesk en softwareonderhoud aan. Door slechts één aanspreekpunt te hebben kan de interactie tussen de verschillende acties die nodig zijn voor het goed verlopen van de velddemonstratie, soepel verlopen. In het geval van de Wijzer op Weg velddemonstratie kon dit omdat er slechts 23 deelnemers tegelijkertijd actief waren. Uiteraard zijn er momenten geweest waar de benodigde inspanning hoger was dan anders. Vooral de eerste weken en de in- en uitbouwperiodes zijn drukke periodes. Ondanks de periodes waarin het relatief rustig is, moet er rekening worden gehouden dat een incident ineens een piekbelasting in de organisatie kan veroorzaken. De velddemonstratieperiode duurt zes weken. In deze periode moeten de deelnemers 50 uur met het Wijzer op Weg systeem rijden. Indien zich echter een probleem voordoet met de apparatuur, kan het een paar dagen duren voordat er een afspraak met de berijder kan worden gemaakt. Aangezien het voor de berijder niet essentieel is (maar voor de proef wel) dat het systeem werkt, kan het maken van een afspraak soms enige tijd op zich laten wachten. Vooral met sommige deelnemers was het moeilijk om afspraken te maken en duurde het soms twee weken voordat de problemen konden worden opgelost. Deze reactietijd, ten opzichte van de duur van de velddemonstratieperiode van zes weken, is veel te lang. Eén week uitval betekent 17% van de tijd verloren. Het verloren gaan van deze tijd is deels gecompenseerd door hier bij het uitbouwen rekening mee te houden. Voor het uitbouwen begon is een lijst gemaakt van de gereden uren van de verschillende deelnemers. Bij het uitbouwen zijn de deelnemers met de meeste uren als eerste uitgebouwd. Hierdoor konden de deelnemers die vertraging hadden opgelopen dit weer enigszins inhalen.


pagina 20


5. CONCLUSIE GEBRUIKERSONDERZOEK Voor de leesbaarheid van het document zijn de belangrijkste delen van de conclusie in dit document overgenomen. De complete conclusie kan worden gelezen in het [Gebruikersonderzoek].

5.1 Onderzoeksvragen met hun antwoorden 5.1.1 Antwoord op onderzoeksvraag 1 Hoe gaan automobilisten om met de verandering in de wijze van geïnformeerd worden als gevolg van het Wijzer op Weg systeem? Men is bereid om informatie in het systeem te zetten en om de informatie van het systeem te gebruiken en op te vragen, maar alleen wanneer deze informatie accuraat is en up-to-date. Het systeem moet dus als ‘informatiever en beter’ worden ervaren dan de meer traditionele vormen van informatievoorziening (krant, radio, internet, teletekst, kaart, etc.).

5.1.2 Antwoord op onderzoeksvraag 2 Wat is de meest effectieve en verkeersveilige manier om informatie op maat aan te bieden aan de weggebruiker? Allereerst is gekeken naar de verkeersveilige manier van aanbieden. Wat direct opvalt is dat het principe van het berekenen van de toegestane werklast ook daadwerkelijk toegepast is in de proef. De werklast was in bepaalde gevallen zo hoog dat men moest ingrijpen door bepaalde informatie achter te houden, of op een andere wijze aan te bieden. In de meeste gevallen had een automobilist een dermate lage werklast dat de diensten konden worden getoond op die momenten dat het nodig was om deze te tonen. Het feit dat er in grofweg een derde van de tijd toch sprake was van werklastmanagement, geeft aan dat een dergelijk concept zinvol is, zeker naarmate de werklast van de bestuurder hoger wordt. Daarnaast is het een belangrijke functie geweest om zeer afleidende zaken, zoals het invoeren van een bestemming, alleen toe te staan bij zeer lage snelheden. Zoals al eerder aangegeven blijft het belangrijk om ervoor te zorgen dat de toegepaste criteria kloppen met de beleving van de bestuurder, dat wil zeggen dat bepaalde zaken niet onterecht onderdrukt worden of niet getoond worden terwijl de bestuurder daar wel behoefte aan heeft.

5.2 Aanbevelingen uit het gebruikersonderzoek Naar aanleiding van het onderzoek en in het licht van deze vragen is er een aantal aanbevelingen en verbeterpunten uit het onderzoek naar voren gekomen. Deze zijn in twee categorieën ingedeeld: Verkeersveiligheid gerelateerde aanbevelingen: • er moet auditieve route-instructie worden gegeven (men hoeft de ogen dan niet zo vaak van de weg te halen); • als er zich een nieuwe dienst aanbiedt met informatie die voor de bestuurder op dat moment van belang is, zou een auditief signaal moeten worden Technolution B.V. datum : 29 november 2005 versie : 1.0

pagina 21


•

•

•

gegeven. Dit voorkomt dat een bestuurder onnodig vaak op het scherm kijkt om te zien of er wellicht nieuwe informatie aangeboden wordt; de interface voor het aanduiden voor de route-informatie moet beter worden vormgegeven (geen gebruik van een donkergroene route op lichtgroene achtergrond, niet te kleine letters, geen snelheidsinformatie op het scherm, dit heeft men al op het dashboard, etc.); te allen tijde moet worden gegarandeerd dat de bewegwijzering alleen de te volgen route aanduidt. Indien dit niet het geval is, kan twijfelgedrag worden voorkomen (langzamer rijden, plotseling wisselen van rijstrook, remmen), wat weer negatieve gevolgen heeft voor de verkeersveiligheid; er altijd tijdens het rijden een indicatie moet zijn of diensten wel of niet oproepbaar zijn. Indien men denkt dat een dienst op te roepen is maar dit niet lukt, zal men meerdere pogingen ondernemen om de dienst op te vragen waardoor een hand van het stuur genomen wordt en men onnodig lang naar het scherm kijkt.

Informatie gerelateerde aanbevelingen: • de databases moeten meer informatie bevatten en meer up-to-date zijn (toegestane snelheid (aangepast bij werk-in-uitvoering), borden, POI’s, ed.); • het systeem moet de beschikking hebben over meer accurate en up-to-date file-informatie, het ‘mag’ slechts zeer sporadisch voor komen, en bij voorkeur helemaal niet, dat de bestuurder in een file komt die door het systeem niet was voorzien. Bij voorkeur zou er ook informatie over het onderliggend weggennet in moeten staan (in ieder geval over de grotere doorgaande wegen); • de geboden diensten moeten beter aansluiten op bestaande systemen (agenda, routenavigatiesysteem); • het navigatiesysteem moet een keuze bieden voor de snelste route, de kortste route of de route het langst over snelwegen; • het aanbieden van de file-informatie moet volgens een vooraf gemelde voorkeur worden ingesteld, zoals in kilometersfile of juist in minutenvertraging; • de interface voor het waarschuwen voor te hard rijden moet ‘gebruikersvriendelijker’ worden gemaakt. Men zal dan minder snel de neiging hebben het geluid uit te schakelen.

5.3 Algemene conclusie van de onderzoeker Indien deze aanpassingen worden gedaan, is TNO van mening dat het systeem zeker een kans van slagen heeft, zeker wanneer wordt aangesloten op reeds bestaande systemen of applicaties. Er zal met name hard gewerkt moeten worden aan de betrouwbaarheid van o.a. de informatievoorziening van het systeem, zodat de meerwaarde voor de weggebruiker direct duidelijk is. Alvorens een dergelijk systeem op de markt wordt gebracht, zou nog een technische en een Human Factors-evaluatie moeten worden gedaan. Hieruit zou moeten blijken of de betrouwbaarheid en bruikbaarheid van het systeem bij rijden in de praktijk, inderdaad voldoende is en of de workload-manager de juiste criteria hanteert.


pagina 22


5.4 Verbeteringen voor het gebruikersonderzoek Bij het uitwerken van de gegevens uit de log bleek dat er soms een wens was voor meer informatie. De nu aangemaakte log was voornamelijk gericht op gebruikersinteractie en getoonde informatie. In het gebruikersonderzoek kwam al snel de vraag als: de informatie is gegeven, maar wat was de reactie van de bestuurder? Wat is bijvoorbeeld de reactie van de bestuurder op het horen van de snelheidsoverschrijdingindicatie? Alleen naar de snelheid kijken geeft te weinig informatie omdat de toestand op de weg ook aanleiding kan zijn voor het zachter gaan rijden. Om dit soort dingen te meten zal er extra functionaliteit of zelfs extra hardware moeten worden aangebracht. Uiteraard moet dan eerst duidelijk zijn wat er precies gemeten wordt. Het eerst schrijven van het onderzoeksplan en vervolgens het ontwerp maken is een goede start. Hiervoor dient uiteraard wel eerst de planning aangepast te worden. Het parallel schrijven van het onderzoeksplan en het ontwikkelen van het systeem is dan niet mogelijk.


pagina 23


6. CONCLUSIE BUSINESSCASE Voor de leesbaarheid van het document zijn de belangrijkste delen van de conclusie in dit document overgenomen. De complete conclusie kan worden gelezen in de [Businesscase].

6.1 Onderzoeksvragen Het bestek heeft een aantal duidelijke onderzoeksvragen voor de businesscase geformuleerd. Het bleek echter al snel dat de gestelde vragen niet 100% aansloten bij de wensen van Rijkswaterstaat voor deze studie. In overleg is de onderzoeksvraag gewijzigd. Hieruit zijn de volgende vragen naar voren gekomen: • In hoeverre kan en zal de integratie van dynamisch verkeersmanagementsystemen (DVM) met voertuigsystemen autonoom door de markt worden opgepakt? • Wat is de gewenste rolverdeling tussen markt, wegbeheerder/overheid t.a.v. deze ontwikkeling? • Welk deel van de weggebruikers kan in de migratiefase met welke diensten bereikt worden? • Welke businessmodellen zijn denkbaar en haalbaar? • Wat zijn de mogelijke, reële implementatietrajecten en hoe kan opschaling gerealiseerd worden?

6.2 Samenvatting Een autonome marktontwikkeling van voertuiggebonden DVM is niet waarschijnlijk door de hoge commerciële risico’s die hieraan verbonden zijn. Door een gecoördineerd initiatief van Europese wegbeheerders kunnen deze risico’s op vitale onderwerpen onder controle worden gebracht. De markt bestaat uit de automobielindustrie en industriële partijen die optreden als toeleverancier voor wegbeheerders. Door een vraagarticulatie door de wegbeheerder die rekening houdt met marktomstandigheden (prijs, volume, standaardisatie, time-to-market) kan de markt inspelen op de geboden kansen en de wegbeheerder passende producten en diensten aanbieden. Het deel van de weggebruikers dat in de migratiefase van infrastructuurgebonden DVM naar voertuiggebonden DVM kan worden bereikt, wordt bepaald door: • de duur van de migratieperiode; • het samenwerkingsmodel tussen overheid en industrie bij de ontwikkeling van voertuiggebonden DVM; • het opnamemodel van nieuwe technologie door de markt; • de migratie start naar verwachting in 2008-2010 en zal in 2020 zijn voltooid.


pagina 24


De opname van succesvolle nieuwe technologie ontwikkelt zich doorgaans volgens een S-curve. Aannemende dat vDVM succesvol zal zijn, zou in 2014-2015 ongeveer 40-50% van de weggebruikers zijn uitgerust met een voertuiggebonden DVM en zal dit percentage in 2010 10%20% bedragen. Vanwege de dan nog lage penetratie van de diensten, zal de nadruk in de periode tot 2015 liggen op niet-kritische verkeersmanagementdiensten (bijvoorbeeld in-car DRIPS). In de denkbare businessmodellen worden de baten uit een toename van de verkeersveiligheid en/of de benutting verkregen. In het businessmodel dat is gebaseerd op een betere benutting, is het hoogst maatschappelijke rendement te halen. De baten uit een beperkte lokale inzet van DVM zijn laag (1%-3% meer benutting) en vormen geen goede basis voor het businessmodel. De baten uit een netwerkbrede toepassing van DVM zijn onvoldoende bekend, maar waarschijnlijk hoger dan van de lokale inzet van DVM (schattingen 1%-20% meer benutting). De benuttingvoordelen van een netwerkbrede DVM worden als onderdeel van de pilot Wijzer op Weg verder onderzocht in een modelstudie. Onderdelen van implementatietrajecten en opschalingmogelijkheden volgen uit de beantwoording van de vorige onderzoeksvragen. De wegbeheerders zullen een keuze moeten maken met welke combinatie van onderdelen en mogelijkheden wordt gestart. Meest kansrijk lijkt een snelle start waarbij de wegbeheerder op EU-schaal het initiatief neemt om voor de volledige industrie (automobiel en after-market) voorwaardenscheppende maatregelen te nemen waardoor commercieel aantrekkelijke en gestandaardiseerde voertuiggebonden DVM-functies als eerste kunnen worden geïntroduceerd door de markt.

6.3 Conclusies De volgende conclusies zijn bij de businesscase-studie getrokken: De life cycle costs voor dynamisch verkeersmanagement worden geraamd op €80 mln per jaar. De netto besparingen voor RWS bij volledige invoering van voertuiggebonden dynamisch verkeersmanagement worden geraamd op 30% van de kosten van infrastructuurgebonden dynamisch verkeersmanagement en uitgaande van een vervroegde afschrijving van infrastructuurgebonden dynamisch verkeersmanagement. Dit percentage gaat uit van de huidige investeringen. Zolang infrastructuurgebonden veiligheidsverhogende oplossingen noodzakelijk zijn doordat niet alle voertuigen zijn uitgerust met voertuiggebonden dynamisch verkeersmanagement, zullen de directe kosten voor de hieraan gebonden maatregelen niet dalen. Investeringen in voertuiggebonden dynamisch verkeersmanagement door RWS worden begroot op €25 mln in de periode 2005-2015 en hebben in deze periode geen besparing in infrastructuurgebonden dynamisch Technolution B.V. datum : 29 november 2005 versie : 1.0

pagina 25


verkeersmanagementoplossingen tot gevolg, tenzij deze systemen versneld worden afgeschreven. De life cycle kosten van voertuiggebonden dynamisch verkeersmanagement worden geraamd op €10 mln per jaar. De voertuiggebonden dynamisch verkeersmanagementontwikkelingen hebben een internationale schaal. De dynamisch verkeersmanagementontwikkelingen in Nederland zijn zeer specifiek voor Nederland. Het integreren van dynamisch verkeersmanagement en voertuiggebonden dynamisch verkeersmanagement vraagt een meer op Europa en de industrie gerichte instelling van RWS. De huidige organisatie van RWS is in staat om operationele voertuiggebonden dynamisch verkeersmanagementactiviteiten te integreren met dynamisch verkeersmanagementactiviteiten.

6.4 Aanbevelingen Bij de businesscasestudie is tevens een aantal aanbevelingen gedaan: Opstarten vraagarticulatie Europese wegbeheerders en de markt t.a.v. informatie over doelstellingen en ontwikkelingen die door wederzijdse consultatie (overheid en industrie en vice versa) snel kan worden verkregen. Breng de baten van verkeersveiligheid en de baten van benutting door voertuiggebonden dynamisch verkeersmanagement in kaart. Start bedrijfseconomische effectenstudie voor alle wegbeheerders en niet alleen RWS in Nederland.


pagina 26

Eindrapportage. Wijzer op Weg velddemonstratie. Voor akkoord, Rijkswaterstaat AGI. Geverifieerd door, Technolution B.V. M. Dukker Project Manager

Recommend Documents