Incentive Zone Enschede - 2019.rejo.zenger.nl1 INLEIDING EN OVERZICHT 5 1.1 Probleemstelling 5 1.2...

Incentive Zone

Enschede

Projectplan

Startdatum: 1-9-2010

Einddatum: 31-10-2011

NOVAY 2

Colofon

DATUM 04-11-2010

VERSIE 1.9

VERANDERING

PROJECT REFERENTIE

NOVAY REFERENTIE

BEDRIJFSREFERENTIE

URL

TOEGANGSRECHTEN Vertrouwelijk

STATUS Definitieve versie

REDACTEUR Wouter Teeuw

BEDRIJF Novay

AUTEUR(S)

Synopsis Gemeente Enschede heeft een nieuw concept geïntrodu ceerd in de strijd

voor een betere bereikbaarheid: de incentive zone. Via verleiding –in plaats

van dwang– worden werknemers aangezet om buiten de spits te reizen of

om minder gebruik te maken van de auto. Na een eers te onderzoeksfase

waarin het concept nader gespecificeerd en getest w ordt, wordt een basis

(= ICT-platform en -diensten) gelegd die hier invul ling aan gaat geven. Ook

vinden praktijkproeven plaats. Dit document beschri jft de hiervoor

benodigde activiteiten.

3

Inhoudsopgave

1 INLEIDING EN OVERZICHT 5

1.1 Probleemstelling 5

1.2 Projectdoelen 5

1.3 Hoe het werkt 5

1.4 Mobiliteit data analyse 6

1.5 De diensten 7

1.6 ARCHITECTuUR 8

1.7 De pilot en het vervolg 9

1.8 Evaluatie 9

1.9 Partner 11

1.10 Relaties met andere projecten 11

1.11 State of the art 11

2 AANPAK EN RESULTATEN 12

2.1 Projectstructuur 12

2.2 Incrementele werkwijze 12

2.3 Overzicht van taken 13

2.4 Planning 16

2.5 Risico’s 17

3 WERKPAKKETTEN 18

3.1 WP0: management 18

3.2 WP1: Platform 19

3.3 WP2: Applicaties 22

3.4 WP3: Experimenten en evaluaties 25

3.5 WP4: Juridisch perspectief 26

3.6 WP5: disseminatie en exploitatie 28

3.7 Deliverables en tijdsplanning 29

4 PROJECT MANAGEMENT 31

4.1 Projectorganisatie en management 31

4.2 Kwaliteitscontrole 31

4.3 Risico’s en beheersmaatregelen 32

4.4 Partners en hun rollen 32

NOVAY 4

5 DISSEMINATIE EN EXPLOITATIE 33

5.1 PR activiteiten 33

5.2 Exploitatie 33

5.3 Demonstratie 33

5.4 Intellectual Property Rights (IPR) 33

5

1 Inleiding en overzicht 1.1 PROBLEEMSTELLING

Mobiliteit is één van de belangrijkste pijlers van een duurzame maatschappelijke en economische ontwikkeling. Hier

liggen ook voor Enschede uitdagingen rond het zorgen voor bereikbaarheid en het managen van verkeersstromen en

tegelijkertijd het creëren van een gezond leefklimaat: een duurzaam mobiliteitsbeleid. In het kader hiervan heeft de

gemeente Enschede een nieuw concept bedacht: de incentive zone (i-Zone). Met de i-Zone wil Enschede

bereikbaarheid van gebieden tijdens de spits verbeteren door het autoverkeer te reduceren, waarbij niet wordt

gewerkt met Verboden, maar met Verleiding. Door middel van gerichte informatie en bijvoorbeeld aanbiedingen van

bedrijven of spelelementen wordt een gedragsverandering gestimuleerd. Dit betekent dat personen door middel van

het aanbieden van informatie moeten worden verleid om: met een andere modaliteit te gaan reizen, of samen te

gaan reizen, of op een ander tijdstip te gaan reizen.

1.2 PROJECTDOELEN

Het doel van Incentive Zone Enschede is om de bereikbaarheid van Enschede-West tijdens de spitsperiode

(ochtendspits van 7:00 tot 9:00 en avondspits tussen 16:30 en 18:30) te vergroten. Meer in het bijzonder wordt hier

bedoeld het stimuleren van het gebruik van alternatieven voor de auto. Hieronder worden allerlei alternatieven van

solistisch autogebruik tijdens de spits verstaan, zoals carpoolen, deels of volledig gebruik van openbaar vervoer,

thuiswerken, telewerk, fietsen, etc. Het uiteindelijke doel is het aantal verplaatsingen in de spits met 5% te reduceren.

1.3 HOE HET WERKT

Om de incentive zone te realiseren zullen een aantal stappen moeten worden gezet (zie ook de aanbevelingen uit de

conceptdefinitie van i-zone1). Figuur 1 geeft aan hoe het geven van positieve prikkels aan burgers in de praktijk

werkt:

GebruikDatabronnen DienstenDatabases en

analyses

Info diensten

ruwesensor data

VRI’s,

Camera’s, etc.

Inzicht

verkeerssituatie

Overige waarde

toevoegingen

Voorspellingen

Persoonlijke

analyses Vervoers-

diensten

Community

diensten

3rd party

applicaties

Gaming

basis diensten

diensten

Gemeente

Consument

Werkgever

Werknemer

Context data

uit mobieltjes

Historische

gegevens

Ongevallen,

weer, etc.

Effect

beïnvloedinggedrag

Andere

modaliteit

Samen

reizen

Ander

tijdstip

?

Figuur 1. De werking van de Incentive Zone Enschede .

• Het begint met de beschikbaarheid van databronnen. Er zijn gegevens nodig die inzicht geven in de actuele of te

verwachten (verkeers)situatie. Hiervoor zijn sensoren in het verkeersnetwerk nodig. We maken hierbij zoveel

1 Teeuw, W.B. (Red.), Incentive Zone: Uitwerking concept en kerndiensten. Enschede: Novay, Versie 1.0, 29 april 2010.

NOVAY 6

mogelijk gebruik van wat er al is. Denk hierbij aan bijvoorbeeld infrastructuurgeboden inwinsystemen als

inductielussen om intensiteiten en /of snelheden te meten, of camera’s waarmee kenmerken van de

verkeerstroom of reistijden op trajecten kunnen worden gemeten. Ook willen we gebruik maken van de sensoren

die mensen zelf al bij zich hebben, namelijk op hun mobieltje.

• Deze data moet worden verzameld in databases, worden verrijkt via analyses, en op een bruikbare manier

worden ontsloten. Hier is een raamwerk (architectuur) voor nodig die het mogelijk maakt dat databronnen zich

aanmelden of diensten gebruik maken van (cq. zich abonneren op informatie uit) deze databronnen. Dit

raamwerk en/of bijbehorende databases moet zo open mogelijk zijn: iedereen kan het gebruiken.

• Vervolgens zijn er diensten nodig die op basis van deze gegevens en/of een analyse of inzichtelijke presentatie

hiervan en/of incentives een voor de gebruiker (werknemer) zinnige functionaliteit verzorgen (dienst).

• En aan de gebruiker moet een portal worden geboden die hem in staat stelt deze diensten te gebruiken, en/of

zijn eigen ervaringen, kennis of data te delen via sociale media.

• Via het gebruik van de diensten wordt het gedrag van burgers beïnvloed: het effect van de Incentive Zone

Enschede. Dit is weer van invloed op de actuele verkeersituatie (cq. de databronnen), en zo is de cirkel rond.

1.4 MOBILITEIT DATA ANALYSE

Het i-Zone systeem maakt gebruik van verkeers- en mobiliteitdata die wordt verzameld uit de verkeersinfrastructuur

(VRIs, camera’s, etc.). Met behulp van deze data en modellen voor verkeersstromen en mobiliteit, wordt nieuwe

informatie afgeleid die door de applicaties binnen i-Zone kan worden gebruikt. Dit data analyse proces is een

kernaspect van het i-Zone systeem. Het idee is dat er een databasis wordt gecreëerd waarbij zo veel als mogelijk is

gebruik wordt gemaakt van beschikbare bronnen. Deze databasis wordt aangevuld/gecomplementeerd met

gegevens die vanuit het i-Zone systeem zelf worden ingewonnen via de mobiele telefoons van i-Zone deelnemers. In

principe wordt binnen i-Zone een zo rijk mogelijke set aan databronnen gebruikt voor het uitvoeren van de analyse,

en worden al deze bronnen met elkaar gecombineerd. De verrijkte data geeft, bijvoorbeeld per dagsoort en per

tijdsinterval voor elk wegvak informatie over reistijd en intensiteit en voor elk kruispunt informatie over vertraging en

wachtrijlengte. Deze informatie is daarnaast beschikbaar voor verschillende weersomstandigheden, en voor niet-

reguliere maar wel voorspelbare situaties, zoals evenementen of feestdagen.

Daarnaast is er het persoonlijk mobiliteitsprofiel van een deelnemer aan i-Zone. De deelnemer heeft een bepaald

verplaatsingspatroon, met herkomst en bestemmingen en tijdstippen van reizen. Daaruit volgt een informatiebehoefte

waarop i-Zone inspeelt door relevante informatie uit de database te halen en aangevuld met voorspellingen en

informatie over reisalternatieven (andere vervoerwijze, ander tijdstip, andere route) beschikbaar te stellen aan de

deelnemer. Voor persoonlijke mobiliteit levert de data-analyse tevens inzicht in bijvoorbeeld vaak bezochte plekken

en veel gebruikte routes door de stad. Merk op dat het monitoren van persoonlijke mobiliteit ook inzicht geeft in de

verkeersstromen op plekken in de stad waar geen data uit de verkeersinfrastructuur zelf beschikbaar is. Naar

verwachting kan deze informatie tevens worden gebruikt.

Een overzicht van stappen van dit proces van verrijking van data is weergegeven in Figuur 2.

7

filter + datafusion

datasource 1

database

statistical analyses

individual mobilitystatus

model m datasource nindividual 1

individual mobilitypatterns

currentnetworkstatus

networkand mobility

patterns

individual mobility

footprints

futurenetworkstatus

model 1 individual N

iyouit

filter + datafusion

datasource 1

database

statistical analyses

individual mobilitystatus

model mmodel m datasource nindividual 1

individual mobilitypatterns

currentnetworkstatus

networkand mobility

patterns

individual mobility

footprints

futurenetworkstatus

model 1 individual N

iyouit

Figuur 2: Verrijking van i-Zone data in verschillen de stappen

1.5 DE DIENSTEN

Een belangrijke factor in onze aanpak is dat we ons niet richten op voertuigen, maar op de personen (werknemers)

en hun verplaatsingen. Zij moeten worden verleid tot ander gedrag. In overeenstemming met marketing principes (zie

Figuur 3) willen we diensten aanbieden waarmee individuen één of meerdere zo persoonlijk mogelijke incentives

krijgen, die hen voordeel biedt. Daarvoor is kennis over de betrokkenen nodig. Tegelijkertijd willen we gebruik maken

van sociale media: werknemers die elkaar helpen door bijvoorbeeld elkaar te informeren. Uiteraard staat bij alles de

privacy centraal. Zogenaamde privacy enhancing technologies zullen worden gebruikt om vooral de gebruiker zelf

controle te geven op wie welke data mag zien.

Kennis over de klant

Klantbereik

Hoog

Middel

Laag

Massa Segment Individu

Hoogst

Community

Massa m

arketing

Direct Marketing

Personalisatie

SocialNetw

ork

Marketing

Kennis over de klant

Klantbereik

Hoog

Middel

Laag

Massa Segment Individu

Hoogst

Community

Massa m

arketing

Direct Marketing

Personalisatie

SocialNetw

ork

Marketing

Figuur 3. Klantkennis en klantbereik bij marketing.

De aanpak van dit project is om een proces op gang te brengen (prijsvraag) om de ontwikkeling en ontsluiting van

i-Zone diensten te stimuleren. Om risico’s af te dekken worden wel een beperkt aantal diensten zelf ontwikkeld (en

moet een minimale basis zijn om i-Zone een succes te maken). Het geheel wordt incrementeel ontwikkeld. Er is

ruimte voor experimenten (pilots), er komen steeds diensten bij, en het aantal gebruikers neemt stapsgewijs toe.

personal mobility

monitoring

NOVAY 8

1.6 ARCHITECTUUR

De i-Zone wordt gerealiseerd als een systeem met verschillende componenten. De architectuur van dit systeem geeft

de onderlinge samenhang van de componenten aan, en kan worden opgedeeld in twee lagen: een laag met

platformservices en een laag met applicaties. Deze opdeling is weergegeven in Figuur 4. Een i-Zone applicatie kan

een binnen het project ontwikkelde platformapplicatie zijn die standaard onderdeel is van de i-Zone service, en die

een (zeer) sterke koppeling heeft met de onderliggende platformservices. Een i-Zone applicatie kan ook een ‘3rd

party’ applicatie zijn die door een andere partij wordt ontwikkeld, zoals beoogd tijdens de prijsvraag. De interface

tussen platformservices en applicaties – de i-Zone Application Programming Interface (API) – is een cruciaal element

van de architectuur en bepaalt in sterke mate de functionaliteit waarover applicaties kunnen beschikken. Daarnaast

zorgt de i-Zone API voor selectieve toegang tot informatie waarbij toepassingen alleen persoonlijke gegevens kunnen

gebruiken als de gebruiker daar toestemming voor heeft gegeven. Op die manier houdt de gebruiker controle over

zijn of haar eigen privacy. In principe is toegang tot de platformservices gelijk voor platformapplicaties en 3rd party

applicaties, dat wil zeggen is voor beiden gebaseerd op gebruik van de i-Zone API.

Figuur 4: de i-Zone architectuur bestaat uit platfo rmapplicaties en ‘3rd party’ applicaties die

gebruik maken van platformservices. De functionalit eit van de platformservices wordt ontsloten

via een interface: de i-Zone Application Programmin g Interface (API).

De i-Zone architectuur bestaat, naast de i-Zone API, uit databases, processingelementen, en presentatie-elementen.

Deze databases en processingelementen komen terug in de platformservices laag en binnen applicaties. Daarnaast

hebben applicaties presentatie-elementen voor interactie met de gebruiker. Aan de onderkant stroomt data het

platform in (niet weergegeven in Figuur 4) over de status van de verkeersinfrastructuur en over de persoonlijke

mobiliteit van de gebruiker. Deze wordt in de platformservices laag verder verwerkt tot meer generieke informatie die

van belang is voor een brede set van toepassingen. Binnen applicaties kan data nog verder verwerkt worden op een

manier die specifiek is voor die applicatie. Een discussiepunt tijdens de uitvoer van dit project zal zijn welke

functionaliteit behoort tot de (generieke) platformservices laag en welke functionaliteit wordt toegevoegd door

9

applicaties die gebruik maken van het platform (vergelijk Google maps: een routeplanner is hier onderdeel van, maar

een aparte routeplanner zou ook gebruik kunnen maken van de door Google beschikbaar gestelde data).

1.7 DE PILOT EN HET VERVOLG

Het concept van de i-Zone is nieuw. Daarom is het gewenst te experimenteren met dit concept in een beperkt gebied

en gericht op een beperkte doelgroep. Hiervoor is de keuze gevallen op woon-werkverkeer in Enschede-West omdat

dit over het algemeen een redelijk eenduidige doelgroep betreft; omdat woon-werkverkeer daarnaast leidt tot de

meeste problemen c.q. dagelijkse pieken; en omdat dit een relatief autonoom gebied is. Doelstelling is het concept te

testen/valideren via een pilot in Enschede-West. Woon-werkverkeer beperkt zich echter niet tot verplaatsingen

binnen Enschede alleen. Daarom zal voor deze validatie het concept in bredere zin worden ontwikkeld en

geïmplementeerd, waarbij enkel in het pilot gebied zal worden gevalideerd of het ‘werkt’. Dit betekent ook dat later op

relatief eenvoudige wijze het project kan worden verbreed richting heel Enschede en richting meerdere doelgroepen

(bijvoorbeeld winkelbezoek). Ook kan het concept worden uitgebreid naar bijvoorbeeld de Innovatiedriehoek. Daarom

wordt nu een duidelijke basis gelegd en wordt het systeem zo ontwikkeld dat uitbreiding relatief eenvoudig kan

plaatsvinden.

Figuur 5: Pilot gebied voor i-zone.

1.8 EVALUATIE

Een belangrijke activiteit is het evalueren van het effect van het project als geheel. Op kwalitatief niveau spelen hier

vragen of er inderdaad een community ontstaat zoals beoogd en gewenst. Kwantitatief spelen vragen of er een effect

is op het verminderen van de files. De bereikbaarheid van Enschede, met als indicator het aantal ritten in de spits, is

immers de reden dat er een Incentive Zone Enschede project in het leven is geroepen. Of deze doelen worden

gehaald, vereist het vastleggen van een methode, prestatie-indicatoren en het doen van metingen (nulmeting,

éénmeting).

Meest eenvoudige manier van evaluatie zou zijn om een telling op belangrijke wegvakken uit te voeren, voor de

proef, en na afloop van de proef, en de uikomsten te vergelijken. Deze methode heeft een belangrijk bezwaar,

NOVAY 10

namelijk dat we op deze manier geen inzicht krijgen in de effecten van de verschillende incentives, voor verschillende

groepen. Dus de vraag wat werkt wel en wat niet en bij wie kan niet worden beantwoord. Daarnaast voorzien we dat

het aantal deelnemers aan de pilot mogelijk te gering is om een effect te kunnen meten ‘op straat’.

De aanpak is om gedrag en gedragsverandering als gevolg van incentives te meten, en deze veranderingen

vervolgens op te schalen naar netwerkniveau, zodat een te verwachten effect op netwerkniveau kan worden

berekend. Daarnaast worden de incentives zelf geëvalueerd op kwaliteit.

We beginnen met een pre-evaluatie om zo een verzameling potentieel succesvolle incentives te ontwikkelen. Dit

gebeurt middels een stated-preference en stated-choice onderzoek.

Om gedrag te kunnen meten worden drie methoden gebruikt, Eerste methode (methode A) is een rittenboekje waar

deelnemers hun mobiliteitsgedrag van de afgelopen 2 dagen noteren, tezamen met een aantal

achtergrondkenmerken als leeftijd, geslacht, inkomen, autobezit, etc. Tweede methode (methode B) is gebruik

maken van een applicatie op een mobiele telefoon waarmee onder meer het verplaatsingsgedrag kan worden

afgeleid. Derde methode (methode C) is een experience sampling applicatie op een mobiele telefoon, waarmee meer

achtergrondinformatie over gebruik en bevindingen van de incentives kunnen worden gemeten. We gaan uit van ten

minste 500 deelnemers aan de pilot. Deelnemers worden geworven bij werknemers van de koplopers van de

mobiliteitsmanagement proef in Enschede maar ook aangevuld met deelnemers van andere bedrijven in het gebied.

Getracht wordt een evenwichtige verdeling naar aard en omvang van de bedrijven te krijgen.

.

De evaluatie van gedragswijzigingen als gevolg van de incentives wordt uitgevoerd door gebruik te maken van een 0-

meting voor aanvang van de pilot en 1-meting aan het eind. Echter, het gehele mobiliteitsgedrag wordt gedurende de

gehele pilot gemeten middels een persoonlijke mobiliteit monitoring toepassing. Per individu wordt bijgehouden wat

het mobiliteitsgedrag is, en ook welke specifieke incentives zijn ontvangen. Zo kunnen naast de voor en nameting

ook tussentijdse evaluaties plaatsvinden, die specifiek aan ontvangen incentives kunnen worden gekoppeld. Wij

zullen dit 2 keer gedurende de pilot uitvoeren. Zo wordt de gedragswijziging als gevolg van de incentives bepaald.

Tevens wordt inzicht verkregen in de impact van specifieke incentives.

De twee onderzoeksmomenten worden aangegrepen om ook de incentives qua vorm en inhoud tussentijds te

evalueren. Hiervoor wordt methode B toegepast, zoals gezegd gedurende twee keer tijdens de pilot. Overigens wordt

aan het eerste meetmoment ook methode C toegepast om een verzameling met potentieel succesvolle incentives te

kunnen afleiden.

De groep deelnemers is in dit stadium naar verwachting te klein om als gevolg van de incentives ‘op straat’

statistisch significante wijzigingen waar te nemen. Daarom wordt een aantal scenario’s met daarin incentives voor

specifieke doelgroepen opgesteld. Door gebruik te maken van effecten van de incentives voor verschillende groepen

en verschillende omstandigheden kunnen de effecten worden opgeschaald naar netwerkniveau. Dit gebeurt door

gebruik te maken van eerder genoemde verkeersmodellen. Uitkomst van de opschaling is een verzameling nieuwe

intensiteiten en snelheden, waarmee externe effecten als uitstoot van CO2, luchtkwaliteit en veiligheid worden

11

bepaald.

1.9 PARTNER

Het initiatief van het project i-Zone ligt bij de Gemeente Enschede. Vanuit hier is een projectteam opgezet samen met

de Stichting Novay en de Universiteit Twente. Het project i-Zone wordt uitgevoerd in samenwerking met Twente

Mobiel.

1.10 RELATIES MET ANDERE PROJECTEN

Het Incentive Zone Enschede project, waarin het i-Zone concept wordt gevalideerd, is feitelijk één element binnen

een hele verzameling van inspanningen om mobiliteit te beïnvloeden cq. slim reizen te organiseren. In het bijzonder

zijn er relaties met het volgende initiatieven:

• SUNSET project, een project dat gaat worden uitgevoerd in het zevende kaderprogramma (FP7) van de

Europese Unie (ICT call 6 – ICT for Mobility of the Future). SUNSET bouwt verder op de resultaten van

onderliggend Incentive Zone Enschede project. SUNSET begint waar de pilot Incentive Zone Enschede ophoudt

en is vooral gericht op kennisopbouw en verbreding. SUNSET en i-Zone zijn twee projecten die beide bijdragen

aan hetzelfde product (richting de burger).

• Vanuit het mobiliteitsplatform in de regio Twente lopen parallel aan dit project meerdere andere projecten.

Hiermee willen we zoveel mogelijk afstemmen, al blijft Incentive Zone Enschede een onafhankelijk project.

Meest concreet zijn de volgende afspraken gemaakt met Twente Mobiel:

o De doelgroepbenadering loopt mede via Twente Mobiel.

o Er wordt mede meegelift op de website (portal) van Twente Mobiel.

� Daartoe wordt ook afgestemd tussen i-Zone en Twente Mobiel over eisen aan de website

(architectuur overleg).

� Twente Mobiel biedt ook een (multi-modale) reistijdplanner aan, in dit kader wordt

afgestemd met de basisdienst reistijdvoorspelling van i-Zone.

� De projectcommunicatie gebeurt in afstemming en/of samenwerking met Twente Mobiel.

1.11 STATE OF THE ART

Het Incentive Zone Enschede project kan voortbouwen op een veelheid van bestaande concepten of producten die al

bestaan. Hiervoor verwijzen we naar de i-Zone conceptdefinitie waar dit project op voortbouwt (voetnoot 1).

NOVAY 12

2 Aanpak en resultaten 2.1 PROJECTSTRUCTUUR

Het werk binnen het project is opgedeeld in werkpakketten, waarbij elk werkpakket een deelaspect van de i-Zone

bestrijkt. De i-Zone architectuur voorziet in een scheiding tussen generieke functionaliteit (de platformservices) en

toepassingen die gebruik maken van deze functionaliteit. Deze natuurlijke scheiding komt terug in de organisatie van

de werkpakketten: WP1 omvat de taken en deliverables die betrekking hebben op de generieke

platformfunctionaliteit, terwijl WP2 gaat over het realiseren van applicaties bovenop dit platform. Naast deze twee

‘onderzoek- en ontwikkel’ werkpakketten is er een werkpakket (WP3) voor het uitvoeren van experimenten en

evaluaties, een werkpakket (WP4) voor het organiseren van de aanbesteding van delen van WP1 en WP2, en een

werkpakket (WP5) voor communicatie en disseminatie (zie Tabel 1).

Tabel 1: overzicht van i-Zone werkpakketten

WP Titel Korte omschrijving

WP0 Management Projectmanagement activiteiten

WP1 Platform Onderzoek naar en ontwikkeling van generiek platform functionaliteit

WP2 Applicaties Onderzoek naar en ontwikkeling van applicaties bovenop het platform

WP3 Experimenten en evaluaties Validatie en evaluatie van het i-Zone systeem; gebruikersexperimenten

WP4 Juridisch perspectief IPR, privacy en organisatie aanbesteding delen van WP1 en WP2

WP5 Communicatie en disseminatie i-Zone communicatie naar algemeen publiek en specifieke doelgroepen

Een belangrijk aspect van dit project is het uitproberen en valideren van i-Zone in het veld, waarbij i-Zone applicaties

beschikbaar worden gesteld aan eindgebruikers. Alle activiteiten die gebruikersexperimenten en systeem evaluaties

omvatten zijn gebundeld in WP3. Daarnaast is er voor gekozen om een substantieel deel van het werk binnen het

project aan te besteden; het aanbesteden is echter aan allerlei voorwaarden en procedures gebonden die

grotendeels losstaan van de inhoud. Dit is de reden om een apart werkpakket te hebben waarin deze procedurele

activiteiten geconcentreerd zijn (WP4) en waar ook overige activiteiten van juridische aard worden uitgevoerd. Het

daadwerkelijk realiseren door derden van systeemcomponenten blijft onderdeel van WP1 en WP2 en is als stelpost

in deze ‘onderzoek- en ontwikkeling’ werkpakketten opgenomen. Voor het verkrijgen van extra i-Zone applicaties

wordt binnen WP2 een prijsvraag georganiseerd; deze prijsvraag geeft tevens een indicatie van de geschiktheid van

het platform voor het ondersteunen van een brede set van toepassingen. Vele van bovenstaande activiteiten maken

communicatie met het algemeen publiek dan wel specifieke doelgroepen noodzakelijk – WP5 voorziet in deze

communicatie.

2.2 INCREMENTELE WERKWIJZE

Het project raakt aan een veelheid van factoren: verkeersmodellen, gedragspatronen, sensordata, de rol van

werkgevers, experimenten in het veld, etc. Dit maakt de uitvoering van het project complex en heeft als risico dat het

13

gewenste systeem niet (volledig) gerealiseerd wordt. Dit pleit voor een sterk cyclische aanpak, en een vroege

confrontatie van concepten met de praktijk. Voor het project als geheel geldt daarom dat componenten, diensten en

toepassingen incrementeel worden ontwikkeld:

1. Incrementeel in de zin dat wordt gestart met een pilot in Enschede-West, maar de resultaten (diensten) zullen in

een breder gebied bruikbaar en/of toepasbaar zullen. Enschede-West is alleen het testgebied waarin we het

gebruik van de diensten in deze pilot zullen monitoren.

2. Incrementeel in de zin dat het i-Zone platform in fasen beschikbaar komt en dat er steeds nieuwe diensten

kunnen en zullen worden toegevoegd. Een reference-implementatie die tijdens de onderzoeksfase wordt

ontwikkeld, zorgt voor een snelle beschikbaarheid van het platform, waarna het productieplatform kan worden

aanbesteed. Na het ontwikkelen van een set van validatie applicaties wordt het aantal applicaties uitgebreid met

diensten door derden via het stimuleren van de ontwikkeling hiervan (aanbesteding en prijsvraag). Gedurende ¾

tijd van het project is een live platform beschikbaar waarmee getest kan worden en waar

experimenten/evaluaties mee gedaan kunnen worden.

3. Incrementeel in de zin dat een specifieke dienst eerst via een experiment kan worden gevalideerd (pilot) voordat

hij definitief wordt uitgerold. Dit doen we door diensten bijvoorbeeld eerst binnen een bepaalde groep te testen

(geselecteerde gebruikers die we monitoren) en daarna breder uit te zetten.

Deze gefaseerde, incrementele aanpak komt terug in de planning van veel van de activiteiten binnen het project. Een

duidelijke fasering garandeert dat basis functionaliteit wordt opgeleverd en dat er daarnaast ruimte is voor onderzoek

en try-out voor die aspecten die het meest innovatief zijn. Ook zorgt het faseren van activiteiten ervoor dat het project

in elkaar wordt geschoven, waardoor de doorlooptijd verkort wordt.

Naast een aanpak van incrementeel werken wordt een adviesgroep in het leven geroepen (zie hoofdstuk 4) voor

reflectie en feedback tijdens de uitvoering van het project. Uitnodiging vindt plaats op persoonlijke titel.

2.3 OVERZICHT VAN TAKEN

Voor elk werkpakket zijn activiteiten (taken) gedefinieerd. Voordat we in hoofdstuk 3 deze taken nader beschrijven is

het goed om iets nader in te gaan op de belangrijkste technische taken en hoe deze samenhangen. In Figuur 6

(feitelijk een nadere detaillering van Figuur 4) is de relatie tussen enkele taken ook grafisch weergegeven.

WP1 gaat over het i-Zone platform en de diensten (services) daarbinnen. Binnen WP1 is de verantwoordelijkheid om

het platform te ontwerpen: de architectuur en interfaces van het platform worden gedefinieerd (taak T1.1). Parallel

hieraan wordt ook een referentie-implementatie van het platform gebouwd (taak T1.2). Hierdoor is er een snelle

terugkoppeling tussen architectuur (ontwerp) en praktijk (implementatie), in overeenstemming met onze incrementele

aanpak. De referentie-implementatie heeft twee doelen. Ten eerste zorgt deze ervoor dat er in een vroeg stadium

binnen het project een versie van het platform operationeel is (taak T1.3). Ten tweede dient de referentie-

implementatie (architectuur- en interfacedefinitie) als vraagspecificatie bij de aanbesteding van het uiteindelijke

productieplatform. Dit production platform wordt gebouwd door derden aan wie deze opdracht wordt gegund (taak

T1.4) en vervolgens operationeel gemaakt (taak T1.5).

NOVAY 14

1

i-Zoneapplication layer

i-Zone platform services

i-Zoneapplication layer

i-Zone platform services

1

raw real-time data

VRI data feed

(traffic lightstatus)

PRIS data feed

(parking status)

road flowdata feed(camera carregistration)

public transport data feed(Sabimos)

mobile sensors data feed



VRI data collector

PRIS data collector

RF data collector

PT data collector

MS data collector

road segments flow (historical

paterns)

flow modeling and calculationstatic data

(maps, …)

analysis (prediction) of traffic times

Enschede traffic flow visualisation and web application

personal mobility patterns

personal mobility pattern detection

match datamobility match calculation

carpool matchmaker web application

T1.6 T1.7

Om

niT

rans

functions

networkmodel

T2.2T2.1

Figuur 6: Gedetailleerde systeemarchitectuur i-Zone project.

Zoals beschreven in paragraaf 1.4 is het vullen en bouwen van een databasis onderdeel van het platform. Hier richt

taak T1.6 zich op. Verificatie van de data speelt daarbij een belangrijke rol. Bekend is dat meetfouten alom aanwezig

zijn en soms ook niet onaanzienlijk zijn qua omvang. Voor de databasis wordt de datastructuur van een bestaand

model (Omnitrans) gebruikt om daar de beschikbare meetgegevens aan te koppelen. Dit is ook weergegeven in

Figuur 6. Ander onderdeel van het platform is de persoonlijke monitoring, zoals ook al beschreven in paragraaf 1.4.

Hier richt taak T1.7 zich op.

WP2 richt zich op de applicaties. Er is nog geen definitieve keuze gemaakt in de te ontwikkelen applicaties. We gaan

in het vervolg van dit document uit van drie voorbeeldapplicaties die zich richten op persoonlijk advies, de status van

het verkeersnetwerk, respectievelijk een spelelement / ‘game’ (taak T2.3, T2.4, T2.5). Behalve deze meer

geavanceerde applicaties die zullen worden aanbesteed worden ook nog twee validatie-applicaties gebouwd. Deze

richten zich meer op deelaspecten: een reisplanner die voortbouwt op de databasis (in taak T2.1) en applicaties voor

persoonlijke mobiliteitspatronen die voortbouwt op de persoonlijke monitoring (in taak T2.2). Deze applicaties worden

gebouwd vanuit onderzoeksdoeleinden en dienen ervoor om ten eerste snel een set van basis applicaties

beschikbaar te kunnen stellen aan de eerste (test) gebruikers; ten tweede een aantal testapplicaties beschikbaar te

hebben voor de referentie-implementatie van het platform; en ten derde om een aantal beschikbaar te hebben voor

acceptatietesten van het productieplatform. Tenslotte levert de prijsvraag ook nog extra applicaties op (taak T2.6).

Bij de aanbesteding is input en hulp nodig vanuit juridisch perspectief (aanbestedingsdeskundige). De juridische kant

15

en het hele proces van aanbesteden vindt plaats in WP4 (taak T4.1). Hier is een aanbestedingsperiode gereserveerd

van 3 maanden voor specificatie (vorm), uitvraag en gunning. Na oplevering van het resultaat volgt een

acceptatietest die onderdeel is van deze procesmatige aanbestedingstaak. De technische ondersteuning van deze

acceptatietesten vindt echter weer plaats vanuit WP1 en WP2 (via testapplicaties die deze WP’s leveren) en/of is

onderdeel van de aanbestede opdracht. Deze zelfde werkwijze rond aanbesteding wordt ook gevolgd voor de andere

aan te besteden taken, namelijk de drie applicaties in WP2. Tabel 2 geeft een overzicht van alle taken.

Tabel 2: lijst met taken per werkpakket

WP Taak Titel Korte omschrijving

T1.1 Architectuur en interfaces Architectuur van i-Zone systeem, definitie van de i-Zone API

T1.2 Reference platform design en implementatie

Snelle ontwikkeling van de platformservices, parallel aan het architectuur werk. Een eerste versie hiervan wordt vroeg opgeleverd in het project.

T1.3 Reference platform deployment Inzetten van het reference platform in een alfa en beta fase

T1.4 Production platform design en implementatie

Ontwikkeling van het production platform, welke ook na het project beschikbaar blijft. AANBESTEDING

T1.5 Production platform deployment Inzetten van het production platform (laatste fase v. project)

T1.6 Databasis Ontwikkeling van databasis in twee fasen; onderdeel van het reference platform. Vroege eerste versie..

WP1

T1.7 Persoonlijke mobiliteit monitoring

iPhone en Android sensor software; mobiliteit patroonherkenning in twee fasen. Vroege eerste versie.

T2.1 Validatie applicatie reisplanner Basis reisplanner, gebouwd op reference platform.

T2.2 Validatie applicaties persoonlijke mobiliteit

Persoonlijke, inter-persoonlijke, en experience sampling applicaties, gebouwd op reference platform.

T2.3 Persoonlijke multi-modale reisadviseur

Geavanceerde multi-modale reisadviseur, gebouwd op reference platform, ingezet op production platform. AANBESTEDING

T2.4 Mobiliteit matchmaker Matchmaker applicatie die deelnemers met passende mobiliteit patronen met elkaar in contact brengt. Gebouwd op ref. platform, ingezet op prod. platform. AANBESTEDING

T2.5 Mobiliteit game i-Zone game, ontwikkeld op reference platform en ingezet op production platform. AANBESTEDING

WP2

T2.6 Applicaties uit prijsvraag Prijsvraagapplicaties, ontwikkeld op reference platform en ingezet op production platform.

T3.1 Validatie-experiment Experiment ter validatie van het i-Zone systeem

T3.2 Gebruikersexperimenten Gebruikersexperimenten gedurende verschillende fasen

WP3

T3.3 Projectevaluatie Projectevaluatie op verschillende momenten tijdens project

T4.1 Aanbesteding production platform

Organisatie van aanbestedingsprocedure voor production platform (specificatie, gunning, acceptatietest)

T4.2 Aanbesteding applicaties Organisatie van aanbestedingsprocedure voor applicaties (specificatie, gunning, acceptatietest)

T4.3 Juridisch algemeen Alle activiteiten die te maken hebben met contracten en intellectuele eigendomsrechten (IPR)

WP4

T4.4 Privacy Alle expliciete activiteiten rond privacyaspecten aanvullend aan de technische kant hiervan binnen WP1

NOVAY 16

WP Taak Titel Korte omschrijving

T5.1 Algemene projectcommunicatie Projectcommunicatie en disseminatie van resultaten (publicaties)

T5.2 Productcommunicatie / marketing

Marketing en communicatie richting gebruikers, ontwikkelaars (inclusief communicatie t.b.v. de prijsvraag) en business partners

WP5

T5.3 Business model Exploitatie/aantrekken van investerende partijen

2.4 PLANNING

In de periode van 1 september 2010 tot 1 november 2010 is een initiële architectuur opgeleverd (zie Figuur 6) welke

de basis is voor verdere planning. Onderstaande Figuur 7 toont de verdere planning vanaf 1 november 2010 (de

datum van deze huidige versie van het projectplan).

Task Name

WP1: platform

T1.1: architectuur en interfaces

T1.2a: reference plat. design/impl. (initiele versie)

T1.2b: reference plat. design/impl. (update)

T1.3a: reference plat. deployment (alfa)

T1.3b: reference plat. deployment (beta)

T1.4a: production plat. design/impl. (initiele versie)

T1.4b: production plat. design/impl. (update)

T1.5: production platform deployment

T1.6a: databasis (initiele versie)

T1.6b: databasis (uitbreiding)

T1.7a: pers. mobiliteit monitoring (initiele versie)

T1.7b: pers. mobiliteit monitoring (uitbreiding)

WP2: applicaties

T2.1: validatie applicatie reisplanner

T2.2: validatie applicaties persoonlijke mobiliteit

T2.3: persoonlijke multi-modale reisadviseur

T2.4: mobiliteit matchmaker

T2.5: mobiliteit game

T2.6a: prijsvraag voorbereiding

T2.6b: prijsvraag applicatie ontwikkeling

T2.6c: prijsvraag applicatie deployment

WP3: experimenten en evaluaties

T3.1: validatie-experiment

T3.2: gebruikers experiment

T3.3: projectevaluatie

WP4: juridisch perspectief

T4.1: aanb. production platform

T4.2: aanbesteding applicaties

T4.3: juridisch algemeen

T4.4: privacy

WP5: disseminatie en exploitatie

T5.1: algemene projectcommunicatie

T5.2: productcommunicatie / marketing

T5.3: business model

Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov DecQtr 4, 2010 Qtr 1, 2011 Qtr 2, 2011 Qtr 3, 2011 Qtr 4, 2011

Figuur 7: overzicht van de planning

In grote lijnen is het project, met een totale duur van 1 jaar, opgedeeld in periodes van 3 maanden. Deze

periodisering houdt gelijke tred met de incrementen in het project: ontwikkel, aanbesteding, deployment en

17

experiment fases zijn telkens 3 maanden.

Belangrijke mijlpalen zijn daarmee:

• 1 februari:

- oplevering referentie-implementatie van het platform (T1.3) en

- oplevering functionaliteit voor dataverzameling rond persoonlijke mobiliteit (T1,6; T1.7)

• 1 mei:

- oplevering validatie applicaties (T2.1, T2.2),

- gunning van de overige applicaties / aanbesteed werk (T4.1, T4.2))

• 1 augustus:

- oplevering production platform (T1.4),

- oplevering alle (aanbestede) applicaties (T2.3, T2.4, T2.5),

- alles klaar voor de start van een grotere proef (T3.1)

• 1 november:

- eindevaluatie (T3.3)

2.5 RISICO’S

De planning geeft een minimaal tijdspad aan, waarbij er sprake is van onderlinge afhankelijkheden tussen taken: bij

uitloop van een taak op het kritieke pad is er kans dat het hele project gaat uitlopen.

NOVAY 18

3 Werkpakketten

3.1 WP0: MANAGEMENT

WP0: Projectmanagement

Startdatum M1 Einddatum M12

Partners Enschede Novay Adviesgroep Totaal

Leider Gemeente Enschede

Omschrijving

(doel, aanpak)

Het doel van WP0 is het project te besturen zodanig dat de resultaten op tijd beschikbaar

zijn. Hoe het management en de kwaliteitscontrole concreet vorm wordt gegeven via

managementteam en adviescommissie staat nader uitgewerkt in hoofdstuk 4. De kosten voor

management zijn maximaal 7% van het totale projectbudget (exclusief extern advies).

Het project weet zich ingekaderd in de activiteiten van het mobiliteitsplatform Twente en heeft

relaties met diverse andere regionale projecten, of zou deze kunnen ontwikkelen. Het

afstemmen met andere projecten en/of het rapporteren aan de regionale stuurgroep (welke

bestaat uit alle bestuurders van de kopgroep Twente Mobiel) is tevens de

verantwoordelijkheid van WP0.

D0.1 Projectplan (document) + operationalisering M0-M12 Resultaten

D0.2 Bundeling diverse management rapportages (document) M12

Risico’s Tijd, budget

19

3.2 WP1: PLATFORM

WP1: Platform


Partners Enschede Novay UT Derden Totaal

Leider Novay

Omschrijving

(doel, aanpak,

taken)

Dit werkpakket heeft als doel om de generieke i-Zone platform functionaliteit te ontwikkelen.

Deze generieke functionaliteit wordt gebruikt door de i-Zone applicaties in WP2.

De aanpak van dit werkpakket is sterk incrementeel: parallel aan de architectuur wordt

allereerst een referentie-implementatie van het platform ontwikkeld, welke dient om snel een

operationeel platform te hebben. Daarna volgt de ontwikkeling van het production platform,

waarbij de reference-implementatie (i.h.b. architectuur en interface-specificaties) als

vraagspecificatie (voor aanbesteding) dient.

T1.1 – Architectuur en interfaces (M1-M3)

Partners: Novay (leider), UT, Enschede

Binnen deze taak wordt de i-Zone architectuur opgesteld en wordt de interface richting de

applicaties (de i-Zone API) gedefinieerd (API naar boven), maar ook de eventuele interne

interfaces in het platform (API’s intern) en de interfaces tussen ruwe data en platform (API

’s naar beneden). De architectuur en API’s dienen als input voor de aanbesteding van het

production platform, en het bouwen van de applicaties. Een zeer belangrijk aspect binnen

deze taak is het specificeren van het privacy mechanisme dat gebruikt wordt binnen i-Zone.

T1.2 – Reference platform design en implementatie ( T1.2a: M1-M3, T1.2b: M4-M6)

Partners: Novay (leider)

Deze taak omvat het ontwikkelen van het reference platform, parallel aan het opstellen van

de i-Zone architectuur en API. Het reference platform wordt in twee fasen ontwikkeld: in de

eerste fase (T1.2a) wordt deze opgeleverd en in de tweede fase (T1.2b) wordt deze

aangepast o.b.v. de ervaringen met het uitrollen (zie T1.3a). Het reference platform

implementeert basisfunctionaliteit en is niet gericht op schaalbaarheid en onderhoudbaarheid.

Onderdelen van dit platform worden ontwikkeld in T1.6 (verkeersmodellen) en T1.7

(persoonlijke mobiliteit monitoring).

T1.3 – Reference platform deployment (T1.3a: M4-M6, T1.3b: M7-M9)


Deze taak zorgt voor het online brengen en houden van het reference platform, in twee

fasen. In de eerste fase wordt de initiële versie van het reference platform uitgerold (alfa

deployment) en in de tweede fase het aangepaste reference platform (beta deployment).

Onderdeel van deze activiteit is het toegang verschaffen tot het platform aan applicaties en

NOVAY 20

gebruikers. Meerdere andere activiteiten maken gebruik van deze deployment: voor alle

applicatie ontwikkeling en voor gebruikersexperimenten (zie T3.1, T3.2).

T1.4 – Production platform design en implementatie (T1.4a: M7-M9, T1.4b: M10-M12)

Partners: Uitvoerder aanbesteding

Binnen deze taak wordt het production platform gebouwd, als aanbesteed werk. Dit platform

vormt de basis voor de inzet van het i-Zone systeem na het afronden van dit project. In de

eerste fase (T1.4b) wordt het platform opgeleverd en in de tweede fase (T1.4b) wordt het

platform aangepast o.b.v. inzichten opgedaan en fouten geconstateerd tijdens de deployment

(zie T1.5). De aanpassingen in de tweede fase vloeien zo snel als mogelijk terug in de

uitgerolde versie van het production platform, om ervoor te zorgen dat deze voor het einde

van het project al effect hebben. Het aanbestedingsproces valt onder T4.1.

T1.5 – Production platform deployment (M10-M12)

Partners: Enschede (leider)

Deze taak rolt in de laatste fase van het project het production platform uit en houdt dit

platform beschikbaar. Tijdens de deployment zal het platform updates krijgen (uit T1.4b).

Meerdere andere activiteiten maken gebruik van deze deployment: alle applicaties (incl. die

van de prijsvraag) zullen draaien in deze omgeving. Het meest uitgebreide

gebruikersexperiment (zie T3.2) zal worden gedaan o.b.v. deze deployment.

T1.6 – Databasis (T1.6a: M1-M3, T1.6b: M4-M6)

Partners: UT (leider)

Deze taak omvat het ontwikkelen van een databasis in twee fasen. Deze databasis is

onderdeel van het reference platform, en, waar opportuun, van het production platform.

Tijdens de eerste fase (T1.6a) wordt een basismodel gemaakt welke in staat is om de

validatie applicaties (zie T2.1, T2.2) te ondersteunen. In de tweede fase worden de databasis

uitgebreid zodat deze ook meer geavanceerde applicaties kunnen ondersteunen (zie T2.3,

T2.4 en T2.5).

T1.7 – Persoonlijke mobiliteit monitoring (T1.7a: M 1-M3, T1.7b: M4-M6)


Binnen deze taak wordt software gerealiseerd in twee fasen, voor het monitoren van

persoonlijke mobiliteit en het herkennen van patronen daarin. Deze software is onderdeel van

het reference platform, en, waar opportuun, onderdeel van het production platform. Tijdens

de eerste fase (T1.7a) wordt monitoring software voor iPhone en Android ontwikkeld en wordt

tevens een basis versie van de patroonherkenningmodule gemaakt. Tijdens de tweede fase

(T1.7b) wordt de patroonherkenning functionaliteit uitgebreid zodat ook meer geavanceerde

toepassingen (zoals de matchmaker applicatie in T2.4) hiermee kunnen worden gebouwd.

D1.1 Architectuur en interface specificaties M3

D1.2 Reference platform versie 1.0 M3


Resultaten

D1.4 Production platform versie 1.0 (aanbesteed) M9

21


D1.6 Basis verkeersmodel M3

D1.7 Geavanceerd verkeersmodel M6

D1.8 iPhone mobiliteit monitoring M3

D1.9 Android mobiliteit monitoring M3

D1.10 Basis persoonlijke mobiliteit herkenning M3

D1.11 Geavanceerde persoonlijke mobiliteit herkenning M6

Risico’s

NOVAY 22

3.3 WP2: APPLICATIES

WP2: Applicaties




Omschrijving

(doel, aanpak,

taken)

Dit werkpakket heeft als doel om specifieke i-Zone applicaties te ontwikkelen en om te

stimuleren dat derden dit doen als onderdeel van een prijsvraag. De applicaties valideren de

geschiktheid van het i-Zone platform (ontwikkeld in WP1) en maken de unieke kenmerken

van i-Zone inzichtelijk. Twee applicaties dienen ter validatie van het platform (zie T2.1 en

T2.2). Een drietal meer geavanceerde applicaties (T2.3, T2.4, T2.5) worden aanbesteed,

waarbij in de loop van het project invulling wordt gegeven aan de precieze specificaties van

deze applicaties. Deze specificaties worden mede gebaseerd op:

• Input vanuit WP3 die inzicht geven in de gebruikerservaringen en welke incentives goed

werken binnen i-Zone

• Input vanuit WP5 die inzicht geeft in welk imago i-Zone moet uitstralen richting

gebruikers en welke manier incentives moeten worden aangeboden

Daarnaast zal de prijsvraag (T2.6) de set van i-Zone applicaties verder uitbreiden.

Merk op dat over de onderstaand benoemde applicaties nog geen definitief besluit is

genomen: ze dienen als voorbeeld-applicaties!

T2.1 – Validatie applicatie reisplanner (M4-M6)

Partners: UT (leider)

Deze taak omvat het ontwikkelen van een basis reisplanner applicatie die kan draaien op de

eerste versie van het reference platform, en die dient ter validatie van platform principes en

interfaces. Tevens verrijkt deze applicatie de gebruikerservaring (maakt de set van

beschikbare toepassingen groter). De basis reisplanner moet geschikte routes kunnen

bepalen o.b.v. huidige verkeersomstandigheden, gebruik makende van het basis

verkeersmodel ontwikkeld in T1.6a. Tevens moet deze applicatie inzicht geven aan de

gebruiker in de huidige verkeerssituatie in Enschede.

T2.2 – Validatie applicaties persoonlijke mobilitei t (M4-M6)


In deze taak wordt een drietal toepassingen ontwikkeld die gebruik maken van de

persoonlijke mobiliteitinformatie beschikbaar in de eerste versie van het reference platform

(o.b.v. de resultaten van T1.7a). De eerste applicatie maakt persoonlijk mobiliteit inzichtelijk,

de tweede vergelijkt persoonlijke mobiliteitspatronen met elkaar, en de derde maakt het

23

mogelijk om vragen te stellen aan de gebruiker over zijn/haar mobiliteit (directe interactie).

Deze applicaties dienen ter validatie van platform principes en interfaces, en breidt de set van

beschikbare i-Zone applicaties uit.

T2.3 – Persoonlijke multi-modale reisadviseur (M7-M 9)

Partners: Enschede (leider), Novay, UT, Derde (P.M. )

Binnen deze taak wordt gewerkt aan een geavanceerde reisadviseur applicatie, welke

rekening houdt met persoonlijke mobiliteit, beschikbaarheid van vervoermiddelen, en huidige

en toekomstige verkeerssituatie. Deze toepassing levert advies die de ten goede komt aan

de gebruiker en tevens aan de doorstroming in de stad, en geeft bijvoorbeeld aan wat het

effect is van vroeger of later vertrekken. De toepassing maakt gebruik van de geavanceerde

verkeersmodellen uit T1.6b en de geavanceerde persoonlijke mobiliteit herkenning uit T1.7b.

Het aanbestedingsproces valt onder T4.2.

T2.4 – Mobiliteit matchmaker (M7-M9)


Deze taak levert een mobiliteit matchmaker applicatie op, welke op geavanceerde wijze

persoonlijke mobiliteitpatronen van i-Zone gebruikers aan elkaar koppelt. Een voorbeeld is

een carpool toepassing die suggesties doet aan een gebruiker welke andere personen

mogelijke carpool kandidaten zijn. In de loop van het project wordt precieze invulling gegeven

aan de specificaties van de applicatie. Het aanbestedingsproces valt onder T4.3.

T2.5 – Mobiliteit game (M7-M9)


Deze taak levert een mobiliteit game op die gebruikers moet overhalen om mee te doen met

i-Zone, en die de verkeersafhandeling binnen Enschede bevordert. Een voorbeeld is een

game waarbij groepen kunnen strijden om het meest duurzame mobiliteitsgedrag. In de loop

van het project wordt precieze invulling gegeven aan de specificatie van de applicatie. Het

aanbestedingsproces valt onder T4.4.

T2.6 – Prijsvraag (T2.6a, M4-M6, T2.6b: M7-M9, T2.6 c: M10-M12)

Partners: Enschede (leider), Novay, UT, Derden

Deze taak omvat het organiseren en uitvoeren van een prijsvraag ter bevordering van het

aantal i-Zone applicaties. Een mogelijke optie om een prijsvraag vorm te geven is dat

potentiële ondernemers (studenten, …) worden benaderd om een idee aan te leveren,

waarbij de beste ideeën een geldbedrag krijgen (voor het idee zelf of als bijdrage in de

realisatie ervan). Of: teams kunnen zich aanmelden voor een competitie, ontwikkelen daarin

tegen (gedeeltelijke) vergoeding ieder een applicatie, waarna het team met de beste

applicatie beloond wordt met een prijs (vooral de eer). Of: de meeste gebruikte applicatie

krijgt een prijs, bijvoorbeeld elke maand een geldbedrag op basis van gebruikers ‘ranking’.

Deze taak omvat 3 subtaken: het voorbereiden (T2.6a), het bouwen van de applicaties door

de deelnemers (T2.6b), en het uitrollen van de applicaties naar gebruikers (T2.6c). De

precieze vorm wordt in de loop van het project bepaald. Communicatie over de prijsvraag

NOVAY 24

wordt gedaan in T5.1.

D2.1 Basis reisplanner M6

D2.2 Persoonlijke mobiliteit status applicatie M6

D2.3 Inter-persoonlijke mobiliteit vergelijking M6

D2.4 Basis experience sampling applicatie M6

D2.5 Persoonlijke multi-modale reisadviseur (voorbeeld / aanbesteed) M9

D2.6 Mobiliteit matchmaker (voorbeeld / aanbesteed) M9

D2.7 Mobiliteit game (voorbeeld / aanbesteed) M9

D2.8 Uitschrijving prijsvraag M6

D2.9 Toelating prijsvraag applicaties M9

Resultaten

D2.10 Prijsvraag applicatie beoordeling M12

Risico’s Resultaten uit WP3 zouden input moeten leveren voor WP2. Tijdsafhankelijkheid is risico

25

3.4 WP3: EXPERIMENTEN EN EVALUATIES

WP3: Experimenten en evaluaties



Leider Universiteit Twente

Omschrijving

(doel, aanpak,

taken)

Doel van dit werkpakket is het i-Zone concept te operationaliseren in aantal experimenten

(pilots) over langere tijd (3 maanden per experiment). Dit gebeurt in nauwe samenwerking

met andere werkpakketten, en vereist beschikbaarheid van het i-Zone platform en (een set

van) i-Zone applicaties. Tevens is het doel van dit werkpakket om het gebruik van i-Zone te

evalueren o.b.v. de uitkomst van de experimenten.

T3.1 – Validatie-experiment (M3-M6)

Partner: Novay (leider) Enschede, UT

Deze taak omvat de eerste testen van het reference platform met echte gebruikers en met

het verzamelen van echte data (uit de infrastructuur en van mobiele telefoons). Deze eerste

gebruikerservaringen zijn relevant om in de loop van het project nog sturing te kunnen geven

aan de aangeboden functionaliteit en applicaties.

T3.2 – Gebruikersexperiment (M7-M12)

Partners: UT (leider), Enschede, Novay

Deze taak richt zich puur op het organiseren van de pilot om ontwikkelde diensten te gaan

testen met een gebruikersgroep. Dus het selecteren van een gebruikersgroep, het

meekrijgen van werkgevers, het geven van praktische ondersteuning. De diensten kunnen

daarbij eventueel nog worden aangepast. Niet alle diensten hoeven tegelijkertijd te worden

gelanceerd: in de aanloopfase (M7-M9) worden steeds meer toepassingen bij geschakeld.

Gedurende de laatste periode van het project (M10-M12), waarin ook het productieplatform

beschikbaar is (zie T1.5), kan dan met een compleet i-Zone systeem worden

geëxperimenteerd.

T3.3 – Projectevaluatie (M3-M12)

Partners: UT (leider), Enschede, Novay

In deze taak wordt de projectevaluatie uitgevoerd. Deze evaluatie bestaat uit een pre-

evaluatie, een evaluatie van gedrag van gebruikers en een evaluatie van het effect van i-

Zone als geheel. Zie ook sectie 1.8 voor een beschrijving van de evaluatie.

D3.1 Pre-evaluatie M3

D3.2 Evaluatie en gedrag van gebruikers M12

Resultaten

D3.3 Evaluatie van het effect van i-Zone als geheel M12

Risico’s

NOVAY 26

3.5 WP4: JURIDISCH PERSPECTIEF

WP4: Aanbesteding




Omschrijving

(doel, aanpak,

taken)

Verschillende componenten van het i-Zone systeem worden gedurende het project

gerealiseerd in de vorm van een aanbesteding. Het proces van aanbesteden is aan allerlei

voorwaarden en procedures gebonden die grotendeels losstaan van de inhoud. Dit

werkpakket is verantwoordelijk voor coördineren van de aanbestedingsprocedures. De aan te

besteden componenten zijn echter onderdeel van WP1 en WP2.

Voor alle taken binnen dit werkpakket geldt dat deze zijn opgedeeld in drie fases:

• een fase waarbinnen de specificatie van het aan te besteden werk wordt opgesteld. De

technische aspecten hiervan komen uit WP1 en WP2, de vorm valt onder deze taak

• een fase waarin geïnteresseerde tijd hebben om te reageren en waarin aan het eind het

werk gegund wordt

• een fase waarin, na implementatie van het werk, een acceptatietest wordt uitgevoerd.

Ook hiervoor geldt dat de technische aspecten vallen onder WP1 en WP2 (bijvoorbeeld

het voorzien in testapplicaties, voor zover ook dit niet onderdeel is van de aanbesteding)

Voor al het aan te besteden werk dient rekening gehouden te worden met mogelijke nazorg

in de periode na afloop van dit project (de periode waarin i-Zone nog operationeel zal zijn).

Daarnaast speelt er het intellectueel eigendom en de eventuele contracten die in dit kader

worden opgesteld. Hiervoor is in een een taak ‘juridisch algemeen’ voorzien. Ook is er een

taak voor de privacyaspecten.

T4.1 – Aanbesteding production platform


Deze taak omvat de procedures rondom het aanbesteden van het production platform (zie

T1.4).

T4.2 – Aanbesteding applicaties


Deze taak omvat de procedures rondom het aanbesteden van de applicaties (zie T2.3, T2.4

en T2.5)

T4.3 – Juridisch algemeen


Deze taak omvat alle activiteiten in het kader van het opstellen van contracten en het

27

omgaan met intellectuele eigendomsrechten (Intellectual Property Rights of IPR).

T4.4 – Privacy


Deze taak omvat alle (niet-technische) activiteiten rond privacy. We denken hierbij aan het

opstellen van privacy reglementen voor gebruikers, het afhandelen van vragen over privacy

en/of het voorzien in een privacy-proof kwalificatie voor het platform. De technische kant van

privacy (privacy enhancing technologies) valt onder WP1.

D4.1 Production platform uitvraag M3

D4.2 Production platform gunning M6

D4.3 Production platform acceptatie M9

D4.4 Persoonlijke multi-modale reisadviseur uitvraag M3

D4.5 Persoonlijke multi-modale reisadviseur gunning M6

D4.6 Persoonlijke multi-modale reisadviseur acceptatie M9

D4.7 Mobiliteit matchmaker uitvraag M3

D4.8 Mobiliteit matchmaker gunning M6

D4.9 Mobiliteit matchmaker acceptatie M9

D4.10 Mobiliteit game uitvraag M3

D4.11 Mobiliteit game gunning M6

D4.12 Mobiliteit game acceptatie M9

D4.13 IPR afspraken M3

Resultaten

D4.14 Privacy reglement M3

Risico’s

NOVAY 28

3.6 WP5: DISSEMINATIE EN EXPLOITATIE

WP5: Disseminatie en exploitatie



Leider Novay

Omschrijving

(doel, aanpak,

taken)

Dit werkpakket omvat disseminatie en exploitatie activiteiten. Zie hoofdstuk 5 voor een

uitwerking van deze activiteiten.

T5.1 – Algemene projectcommunicatie

Partners: Enschede (leider), Novay, UT, Onebigagenc y

Deze taak is verantwoordelijk voor algemene projectcommunicatie en disseminatie van

resultaten (in de vorm van bijvoorbeeld wetenschappelijke publicatie).

T5.2 – Productcommunicatie / marketing, Onebigagenc y

Partners: Enschede (leider), Novay, UT

Deze taak omvat de marketing van i-Zone. Ook zal binnen deze taak de communicatie voor

de prijsvraag (zie T2.6) plaatsvinden.

T5.3 – Businessmodel

Partners: Enschede (leider), Novay, UT, Onebigagenc y

Deze taak gaat na hoe de basisdiensten van het project na afloop kostenneutraal kunnen

worden geëxploiteerd.

D5.1 Business model voor i-Zone M8

D5.2 Communicatieplan + uitvoer M1-12

D5.3 Marketingplan + uitvoer M8-12

Resultaten

D5.4 Communicatieplan voor prijsvraag + uitvoer M3-6

Risico’s Budget voor communicatie en voor marketing is krap.

29

3.7 DELIVERABLES EN TIJDSPLANNING

Nr. Deliverable Planning

D0.1 Projectplan (document) + operationalisering M0-M12

D0.2 Bundeling diverse management rapportages (document) M12

D1.1 Architectuur en interface specificaties M3





D1.6 Basis verkeersmodel M3

D1.7 Geavanceerd verkeersmodel M6

D1.8 iPhone mobiliteit monitoring M3

D1.9 Android mobiliteit monitoring M3

D1.10 Basis persoonlijke mobiliteit herkenning M3

D1.11 Geavanceerde persoonlijke mobiliteit herkenning M6

D2.1 Basis reisplanner M6

D2.2 Persoonlijke mobiliteit status applicatie M6

D2.3 Inter-persoonlijke mobiliteit vergelijking M6

D2.4 Basis experience sampling applicatie M6

D2.5 Persoonlijke multi-modale reisadviseur (aanbesteed) M9

D2.6 Mobiliteit matchmaker (aanbesteed) M9

D2.7 Mobiliteit game (aanbesteed) M9

D2.8 Uitschrijving prijsvraag M6

D2.9 Toelating prijsvraag applicaties M9

D2.10 Prijsvraag applicatie beoordeling M12

D3.1 Pre-evaluatie M3

D3.2 Evaluatie en gedrag van gebruikers M12

D3.3 Evaluatie van het effect van i-Zone als geheel M12

D4.1 Production platform uitvraag M3

D4.2 Production platform gunning M6

D4.3 Production platform acceptatie M9

D4.4 Persoonlijke multi-modale reisadviseur uitvraag M3

D4.5 Persoonlijke multi-modale reisadviseur gunning M6

D4.6 Persoonlijke multi-modale reisadviseur acceptatie M9

D4.7 Mobiliteit matchmaker uitvraag M3

D4.8 Mobiliteit matchmaker gunning M6

D4.9 Mobiliteit matchmaker acceptatie M9

NOVAY 30

Nr. Deliverable Planning

D4.10 Mobiliteit game uitvraag M3

D4.11 Mobiliteit game gunning M6

D4.12 Mobiliteit game acceptatie M9

D4.13 IPR afspraken M3

D4.14 Privacy reglement M3

D5.1 Business model voor i-Zone M8

D5.2 Communicatieplan + uitvoer M1-12

D5.3 Marketingplan + uitvoer M8-12

D5.4 Communicatieplan voor prijsvraag + uitvoer M3-6

31

4 Project management 4.1 PROJECTORGANISATIE EN MANAGEMENT

Het werk in het Incentive Zone Enschede project wordt uitgevoerd in werkpakketten (zie hoofdstuk 2). Deze bestaan

ieder uit een logisch bij elkaar horende verzameling activiteiten die nodig zijn om het project als geheel succesvol uit

te voeren. Ieder werkpakket wordt geleidt door een werkpakketleider. Deze is verantwoordelijk voor het op tijd

opleveren van de resultaten van dat werkpakket en voor de kwaliteit van de resultaten. Dit betekent natuurlijk niet dat

hij/zij ook al het werk uitvoert. Qua management is een werkpakketleider verantwoordelijk voor het bewaken van de

voortgang in zijn/haar werkpakket, het tijdig signaleren en rapporteren van problemen en het actief deelnemen aan

overleggen van het project management team (zie hieronder).

De projectmanager is verantwoordelijk voor het besturen van het hele project. Hij is ook de officiële link tussen het

project en de opdrachtgever (Gemeente Enschede). De projectmanager leidt het project management team (PMT),

wat in dit project bestaat uit de leiders van de werkpakketten en/of vertegenwoordigers van partners. De PMT is

verantwoordelijk voor het bewaken van de voortgang van het hele project, voor het op tijd opleveren van uitstekende

resultaten en voor dagelijks management.

Tabel 3 toont de personele invulling voor de PMT en de vertegenwoordigers van de partners. De werkpakketten

staan beschreven in hoofdstuk 2.

Tabel 3: Samenstelling van het projectmanagementtea m.

Rol Persoon Partner

Algemeen projectleider (WP0) Marcel Meeuwissen Enschede

Projectsecretaris Benjamin Groenewolt Enschede

WP1 leider (platform) Johan Koolwaaij Novay

WP2 leider (applicaties) Kees van der Neut Enschede

WP3 leider (evaluatie) Eric van Berkum UT

WP4/5 leider (juridisch, communicatie) Vera Dethmers Enschede

Projectleider Novay Wouter Teeuw Novay

De PMT komt in de regel tweewekelijks doch tenminste één maal per maand bij elkaar, fysiek. Naast PMT

besprekingen organiseren we ook projectbesprekingen met het hele project. Deze zullen plaatsvinden op natuurlijke

mijlpalen in de planning (typisch elke 3 maanden).

4.2 KWALITEITSCONTROLE

Het project heeft ter verhoging van de kwaliteit gekozen voor een adviesraad die als klankboord dient voor het

project. Binnen de adviesraad zijn wetenschap, ondernemerschap en regionale belangen vertegenwoordigd,

NOVAY 32

waarmee we een gedegen inbedding van het project in regionale roadmaps beogen. De adviesraad komt aan het

eind van elke fase bijeen, reviews de deliverables en geeft advies met het oog op bijsturing in de volgende fase.

Omdat er geen sprake moet zijn van belangenverstrengeling ten aanzien van bijvoorbeeld de aan te besteden

diensten, zal de adviesraad in de loop van het traject nader worden ingevuld en/of worden gewijzigd.

4.3 RISICO’S EN BEHEERSMAATREGELEN

Het project kent een aantal taken die worden uitbesteed of waar offertes voor worden aangevraagd. Hier ligt een

risico’s of wel de goede partners worden gevonden, hoeveel doorlooptijd daarvoor nodig is, en of de budgetten

(stelposten) hiervoor staan toereikend zijn. Dit zal continue gemanaged moeten worden.

Ook de beschikbaarheid van bronnen en de eventuele kosten hiervan zijn een risicofactor (zie WP1). Daarnaast zit

het hele project onder een aanzienlijke tijdsklem en is de aard van het project dusdanig dat op voor hand geen

garantie op succes kan worden geboden.

Daarom zal in ieder geval een zekere basis worden ontwikkeld die in ieder geval bestaat uit:

- een mobiele mobiliteitsmonitor (voor android, i-phone) die gebruikt kan worden voor het gemeentebreed

monitoren van de mobiliteitssituatie.

- een website met hierop de verkeerssituatie in Enschede

Deze onderdelen hebben in ieder geval hun nut, ook als de overige aspecten van de i-Zone pas in een later stadium

tot volle wasdom komen.

4.4 PARTNERS EN HUN ROLLEN

De rollen van de partners staan beschreven bij de verschillende werkpakketten.

33

5 Disseminatie en exploitatie 5.1 PR ACTIVITEITEN

De resultaten van het project worden zo breed mogelijk verspreid, waarbij we denken aan fora als onder andere

Eurocities, Civitas. Dit is mede in het kader van het eerder genoemde project SUNSET ook geëist door de Europese

Commissie. Ook kan het project resulteren in wetenschappelijke publicaties.

5.2 EXPLOITATIE

Hoe na afloop van het project verder dient te worden gegaan met betrekking tot de exploitatie van resultaten is

onderdeel van het project zelf (WP5). Hier is overleg voor nodig met commerciële partners (d.w.z. de

dienstenaanbieders), en ook kan de adviesgroep een rol spelen.

5.3 DEMONSTRATIE

Het project resulteert in concrete diensten. Via prototypes kan in eerdere fases een demonstratie applicatie worden

gerealiseerd. Deze is dan vooral bedoeld om initiële feedback te krijgen van gebruikers.

5.4 INTELLECTUAL PROPERTY RIGHTS (IPR)

Bestaand intellectueel eigendom (‘background IPR’) dat door partners wordt ingebracht blijft hun eigendom. Voor

afspraken over het in het project ontwikkelde intellectueel eigendom (‘foreground IPR’), het ontwikkelde basisplatform

en de te ontwikkelen applicaties zullen nadere afspraken worden gemaakt tussen opdrachtgever (Gemeente

Enschede) en de opdrachtnemers. De insteek is in ieder geval dat de basisdiensten, dat wil zeggen het platform dat

voorziet in de basale informatie over bijvoorbeeld de verkeerssituatie, zo open mogelijk is.

Bij de diensten zelf speelt vooral het business model en wie hier de exploitatiekosten voor zijn rekening neemt. De

voorkeur ligt daarin dat de ontwikkelaars van de diensten deze zelf exploiteren en eventueel eraan verdienen. Dit

maakt hen gedreven diensten te ontwikkelen. Dit veronderstelt echter ook dat ze zelf investeren.

Incentive Zone Enschede - 2019.rejo.zenger.nl1 INLEIDING EN OVERZICHT 5 1.1 Probleemstelling 5 1.2...

Documents

Transcript of Incentive Zone Enschede - 2019.rejo.zenger.nl1 INLEIDING EN OVERZICHT 5 1.1 Probleemstelling 5 1.2...