FLEXSYT-II- November 2001

Syllabus FLASH/FLEXSYT-II-

November 2001

Colofon Ministerie van Verkeer en Waterstaat Directoraat-Generaal Rijkswaterstaat Adviesdienst Verkeer en Vervoer Postbus 1031 3000 BA Rotterdam Auteurs: ir. F. Middelham ir. H. Taale ing. T.C. Wang (Goudappel Coffeng) Datum: 13 november 2001 Oplage 5: 50 exemplaren

Inhoudsopgave .............................................................................................


1 1.1 1.2

Simulatie Algemeen Simulatie in de verkeerskunde

5 5 5

2 2.1 2.2 2.3

FLEXSYT-IIAchtergronden Structuur Veranderingen en uitbreidingen

7 7 7 8

3 3.1 3.2 3.3

Opbouw netwerk Inleiding Segmenten Internode segment

11 11 12 13

4 4.1 4.2

Simulatie parameters Subruns Tijdsperioden

15 15 15

5 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11

Voertuigmodellen Voertuigtypes Voertuigkenmerken Voertuigaankomsten Mergeconflict Ongeregeld conflict Halteren Inhalen Routekeuze Detectie Verkeerssignalering Congestie

17 17 17 18 18 18 18 19 19 19 20 20

6 6.1 6.2 6.3

Uitvoer Inleiding Beschrijvingen Ontwikkelingen

21 21 21 22

7 7.1 7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.3 7.4 7.5 7.5.1 7.5.2

Programmatische aspecten Programmeertaal Fortran Windows95/98/ME/2000/NT Multitasking Intern geheugen File associaties / Filetype Bestandsbeheer Event-by-event simulatie Visualisatie Optimalisatie Optimalisaties buiten FLEXSYT Optimalisatie binnen FLEXSYT

23 23 23 23 24 24 25 25 27 28 28 29

3


8 8.1 8.2 8.3 8.4 8.5 8.6

FLASH Inleiding Doel FLASH Relatie FLASH, FLEXSYT-II- en regelaars Regelaars ASCII-Editor Windows omgeving

31 31 31 32 33 34 34

9 9.1 9.2 9.3

Andere aspecten Validatie Foutmeldingen Omgevingsvariabelen

37 37 37 37

10 10.1 10.2

Ontwikkelingen Koppeling met industriële regelaars Visualisatie

39 39 39

11 11.1 11.2

Beschikbaarheid en bruikbaarheid Beschikbaarheid Bruikbaarheid

41 41 41

12

Referenties

43

4

1 Simulatie .............................................................................................

1.1 Algemeen

Simulatie is het nabootsen van de werkelijkheid met behulp van modellen, om inzicht in die werkelijkheid te krijgen, voorspellingen over die werkelijkheid te kunnen doen en daarmee deze te kunnen beheersen. Simulatie is een algemeen erkend middel om uitspraken te kunnen doen over het gedrag en de effecten van bepaalde processen en systemen. Dat geldt voor bijna alle onderzoeksgebieden van de zogenoemde 'exacte wetenschappen', zoals biologie, natuurkunde, meteorologie, lucht- en ruimtevaart, etc., maar ook voor andere onderzoeksgebieden, zoals bijvoorbeeld de sociologie. De voordelen van simulatie zijn: · het is mogelijk processen te bestuderen waarmee geen praktijkproeven gedaan kunnen worden; · het is meestal goedkoper dan praktijkproeven; · het is mogelijk snel en eenvoudig varianten te bestuderen. Het nadeel van simulatie is dat altijd met een model, een interpretatie van de werkelijkheid gewerkt wordt. De werkelijkheid is nooit in zijn geheel te modelleren en wijkt daarom altijd af van het model, zeker wanneer de menselijke factor meespeelt. Verder is de kwaliteit van de uitvoer van een model sterk afhankelijk van de kwaliteit van de invoer, hetgeen de simulatieresultaten relativeert.

1.2 Simulatie in de verkeerskunde

Op het gebied van verkeersbeheersing wordt simulatie veel toegepast om de effecten van bepaalde maatregelen te berekenen. Daarbij is het goed onderscheid aan te brengen voor wat betreft: de (tijd)schaal, de modelleringstechniek en de toepassingsmogelijkheden. Met de (tijd)schaal wordt de grootte van het te simuleren netwerk bedoeld. Zeer grote netwerken, zoals bijvoorbeeld Nederland of de Randstad, kunnen worden doorgerekend met het Landelijk Model Systeem (LMS) of het Nieuw Regionaal Model (NRM). Daarbij gaat het om de effecten op langere termijn en op grote schaal van bijvoorbeeld nieuwe wegen, demografische en planologische veranderingen of van beleidsmaatregelen. Daarnaast zijn er modellen die geschikt zijn om bijvoorbeeld één kruispunt of een netwerk van kruispunten en/of wegen te simuleren, zoals bijvoorbeeld FLEXSYT-II- en FOSIM. Daartussen ligt een hele range van modellen waarmee netwerken in de orde van grootte van een stad of stadsdeel gesimuleerd kunnen worden. Voorbeelden zijn CONTRAM, SATURN en INTEGRATION. Gesteld kan worden dat met het toenemen van de grootte van het netwerk het toedelen van het verkeer aan dat netwerk steeds belangrijker wordt. Bij toedeling wordt een onderscheid gemaakt tussen statische en dynamische toedeling. Het verschil is dat bij een dynamische toedeling rekening gehouden wordt met het tijdsaspect en bij statische toedelingen niet. Het LMS en NRM, maar ook SATURN gebruiken een statische toedeling, terwijl CONTRAM en


5

INTEGRATION voorbeelden zijn van modellen die werken met een dynamische toedeling. ................................... Figuur 1:

ruimte

Indeling modellen naar ruimte en tijd

LMS

landelijk netwerk

AIMSUN2 regionaal netwerk

Integration

routekeuze stedelijk netwerk

FLEXSYT streng

Dyndart CONTRAM

METANET

geen routekeuze

FREQ

NRM

3DAS

Saturn dynamisch statisch

Paramics

FOSIM

wegvak

MIXIC tienden van seconden

seconden

kwartieren

uren

minuten

.

spitsperiodes

kwartieren dagen

uren

dagen jaren

tijdstap

voorspellingshorizon

Een mogelijke indeling van de modellen naar ruimte en tijd1 is gegeven in figuur 1. Twee onderverdelingen zijn daarbij met gebogen lijnen aangegeven: het reeds genoemde onderscheid tussen dynamische en statische modellen en het onderscheid tussen modellen met en zonder routekeuze. Een andere indeling is er mogelijk ten aanzien van de modelleringstechniek. Er zijn, globaal, twee soorten simulatiemodellen: macroscopische en microscopische. De macroscopische modellen gaan uit van algemene formules voor de beschrijving van verkeersstromen (meestal gebaseerd op de vloeistofmechanica), terwijl de microscopische modellen de beweging van afzonderlijke voertuigen of groepjes van voertuigen simuleren. Daartussenin zijn er ook nog mesoscopische modellen. Deze simuleren voertuigen of groepjes voertuigen op basis van macroscopische beschrijvingen. In deze cursus wordt het simulatiemodel FLEXSYT-II- behandeld. FLEXSYT-II- is een microscopisch simulatiemodel voor kleinschalige netwerken, dat gebruikt kan worden voor korte termijn voorspellingen voor een groot aantal toepassingen, met name op het gebied van de regeltechniek.

1


Met dank aan Stef Smulders en Frans Middelham

6

2 FLEXSYT-II.............................................................................................

2.1 Achtergronden

Het ontwerpen van een verkeerslichtenregeling en het bestuderen van de effecten van verkeersbeheersingsmaatregelen op autosnelwegen is, vooral in een stedelijke omgeving, voor de verkeerskundige een ingewikkeld proces, door de grote complexiteit en onvoorspelbaarheid van het verkeersaanbod. Juist in zulke situaties is simulatie het ideale middel om inzicht te krijgen in de kwaliteiten en effecten van regelingen en maatregelen. Het programmapakket FLEXSYT is al lange tijd erkend als een uniek programma dat de gewenste mogelijkheden tot simulatie biedt. Het is geschikt voor allerlei studies op het gebied van verkeersbeheersing, doordat het programma het verkeer simuleert op een microscopische schaal, dat wil zeggen dat afzonderlijke voertuigen door middel van een stochastisch proces door het netwerk worden bewogen. Het is daardoor mogelijk, met behulp van FLEXSYT, onderzoek te doen naar de effecten op de verkeersafwikkeling van de structuur van het netwerk, zoals de geometrie van de kruispunten, de lengte van de opstelstroken, het aantal rijstroken, vrije busbanen, enz. Verder kent FLEXSYT een uniek mogelijkheid om regelingen te simuleren. Om de gebruiker geen ingebouwde regelfilosofie op te leggen, is daarvoor een eigen formuletaal ontwikkeld (FLEXCOL-76-) en heeft FLEXSYT een speciale opbouw. FLEXCOL-76- is een programmeertaal, gebaseerd op toestandsveranderingen (events). Deze taal is dus event georiënteerd en volgt de regels van de Boolean algebra. De opbouw van FLEXSYT bestaat daarin dat er een beheerdersdeel en een gebruikersdeel gespecificeerd moeten worden. In het beheerdersdeel wordt een algemene regelstrategie gegeven. Dit deel is daardoor niet probleemgebonden en kan voor allerlei gelijksoortige problemen gebruikt worden. Het probleemgebonden gedeelte van de regeling wordt gespecificeerd in het gebruikersdeel. Verder is er een strikte scheiding tussen het verkeerssimulatie deel en het regeldeel. Door het gebruik van FLEXCOL-76- en door de opbouw is het mogelijk elke denkbare regeling in FLEXSYT te implementeren en te evalueren. Voorbeelden daarvan zijn de starre, de voertuigafhankelijke en de verkeersafhankelijke regeling, maar ook regelingen die gebruikt worden voor prioriteitsregelingen voor openbaar vervoer, rotondes, toeritdosering, hoofdrijbaandosering, tolpleinen, SDG-stroken, spitsstroken, FUZZY-logic, enz. [1].

2.2 Structuur

Het FLEXSYT-II- programma bestaat uit een aantal deelprogramma's, waarvan de samenhang is weergegeven in figuur 2.


7

................................... Figuur 2:

Structuur van FLEXSYT-II-

mandat

condat

netdat

FLXMAN

FLXCON

FLXNET

simdat

FLXSIM

trcfil

FLXREG

FLXRES

regfil

resfil

FLXDMP

dmpfil

Er zijn vier datasets met invoergegevens nodig: · in de MANDAT-dataset staan de namen van de elementen en verzamelingen van een regeling. Ook de niet probleemgebonden afhandelingsvoorwaarden worden hier geformuleerd; · in de CONDAT-dataset staan de invoergegevens van de te onderzoeken regelvariant van het te onderzoeken probleem; · in de NETDAT-dataset staan de invoergegevens zoals de verkeersintensiteiten, een beschrijving van de civieltechnische structuur en de ligging van stopstrepen, detectoren, bushaltes en no-queueing zones van de te onderzoeken netwerkvariant; · in de SIMDAT-dataset staan de simulatie-parameters. Voordat de simulatie start, worden de ingevoerde gegevens gecontroleerd op consistentie en syntax met behulp van de deelprogramma's FLXMAN, FLXCON en FLXNET. Tijdens starten van de simulatie worden de gegevens van de SIMDAT-dataset gecontroleerd en tevens de consistentie van het netwerk en de regeling samen. Het draaien van FLXMAN kan natuurlijk achterwege blijven als al een gecompileerde MANDAT-dataset (MANFIL-dataset) beschikbaar is. Indien de invoer correct is, kan de simulatie worden gestart met FLXSIM. Bij congestie in het onderzochte netwerk produceert FLXSIM een dataset met gegevens over de toestand van het netwerk. Met behulp van FLXDMP kan dit in een leesbaar formaat worden gezet (DMPFIL). Daarnaast is het mogelijk om fouten in de regeling op te sporen met behulp van "event tracing" waarvan de resultaten worden geschreven in de TRCFILdataset. Gedurende de testfase van een verkeersregelprogramma kan, met behulp van het deelprogramma FLXREG, voor iedere seconde, een "toestandtrace" worden verkregen van de verkeersregeling. Deze wordt weggeschreven in de REGFIL-dataset. Dit is een onmisbaar hulpmiddel bij het testen en ontwikkelen van regelprogramma's. Na een succesvolle simulatierun kunnen, met behulp van het deelprogramma FLXRES, diverse simulatieresultaten in tabelvorm worden uitgeprint in de RESFIL-dataset. Deze tabellen zijn dus bruikbaar in de evaluatiefase.

2.3 Veranderingen en uitbreidingen

Het regelgedeelte van FLEXSYT-II- is ten opzichte van FLEXSYT-I- niet veranderd. Dat wil zeggen dat nog steeds gebruik wordt gemaakt van FLEXCOL-76-. De invoer datasets MANDAT en CONDAT zijn ongewijzigd. Wel veranderd is het simulatiedeel en met de name de gebruikte voertuigmodellen.


8

Een belangrijke verbetering is dat voertuigen in FLEXSYT-II- optrekken en afremmen. Verder zijn er nu, in plaats van twee, acht voertuigsoorten, te weten: personenauto's, lichte vrachtwagens, zware vrachtwagens, bussen, trams, fietsers, voetgangers en carpoolvoertuigen, elk met hun specifieke voertuigkenmerken voor wat betreft lengte, acceleratie en deceleratie. Het is tevens mogelijk voertuigen een bepaalde route te laten rijden, ongeregelde kruispunten met voorrangsregels en andere ongeregelde conflicten te simuleren. De uitvoer van FLEXSYT-II- is, voor wat betreft de resultaten, uitgebreider dan FLEXSYT-I-. Het grote verschil zit in het aantal voertuigsoorten, de meer kruispunt gebonden gegevens, de routevoertuig aspecten en de milieuaspecten.


9


10

3 Opbouw netwerk .............................................................................................

3.1 Inleiding

Voor de opbouw van het netwerk worden twee niveaus onderscheiden: netwerkniveau en kruispuntniveau. Onder netwerkniveau vallen aspecten die niet direct aan een kruispunt gekoppeld zijn of die de invloed van één kruispunt te boven gaan. Voorbeelden daarvan zijn: · generator: produceert voertuigen volgens een random proces waarmee wordt bepaald hoe voertuigen het netwerk binnenkomen; · mix-samenstelling: mogelijkheid om een groep (mix) van voertuigtypen op te geven; · route: mogelijkheid om de voertuigen uit een bepaalde generator een vooraf opgegeven route door het netwerk te laten volgen; · haltelijst voor routevoertuigen: mogelijkheid om voor voertuigen waarvoor een route is opgegeven, te bepalen welke haltes langs de route moeten worden aangedaan. Op kruispuntniveau wordt gewerkt met armnummers om met name routevoertuigen te kunnen geleiden door het netwerk, verder worden de volgende gegevens onderscheiden: · segmenten: de afzonderlijke (delen van) rijstroken, waaruit het kruispunt is opgebouwd; · internode segmenten: een wegvak met meerdere rijstroken; · verkeersstroomverdeling: verdeling van niet-routevoertuigen; · (bus)pocket: de fysieke locatie van een halte voor openbaar vervoer en/of overige verkeer; · ongeregelde conflicten: conflicten tussen voertuigen met een voorrangsregeling; · no-queueing zone: een deel van een segment dat door het voertuigen in een wachtrij wordt vrijgelaten (voor kruisend verkeer); · signaalgroep: een door een verkeerslantaarn geregelde stopstreep; · detector: plaats van een detector; · distributie: een opgelegde verdeling naar andere segmenten. In figuur 3 is een invoerframe voor de netwerkgegevens weergegeven. Binnen het bestek van deze syllabus gaat het te ver om elk record dat hier gegeven is nauwkeurig te beschrijven. Hiervoor wordt verwezen naar de handleiding. Wel zullen nog enkele opmerkingen worden gemaakt over de twee typen segmenten.


11

..................... Figuur 3:

Invoerframe NETDAT

//titelkaart

(verplicht)

/GEN generatorparameters

(verplicht)

;gennum gentos gentyp regul gint0 gint1 gint2 ... gint# ;

>---- ----- --- ----<

/MIX globale samenstelling verkeer

(niet verplicht)

;mixnum mixcnt1 mixcnt2 mixcnt3 mixcnt4 mixcnt5 ;

>------ ------- ------- ------- ------<

/RTE routes van routevoertuigen

(niet verplicht)

;rtenum renarm route1 route2

...

route# rexarm

;

---

-----<

>----- ------

/HLT haltes van openbaar vervoer

(niet verplicht)

;hltnum hltstp1 hltchn1 hlttim1 hltdev1

.....

hltstp# hltchn# hlttim# hltdev#

;

>---<

>------ ------- ------- ------<

>------ ------- ------- ------<

//### kruispunt- of nodenummer

(verplicht)

/INS internode segmenten

(niet verplicht, mits segment opgegeven)

;insnum insarm inslen inssat instyp insspd insdev inslan insovr instos1 ... instos6 ;

>----- -----< >----- -----< >------ --- ------<

/SEG segmenten

(niet verplicht, mits internodesegmenten opgegeven)

;segnum segarm seglen segsat segtyp segspd segdev segtos1 ... segtos6 ;

>----- -----< >------ --- ------<

/BSP halteplaatsen

(niet verplicht)

;bspnum bspend bspbeg bsppck bspmil bsptim bspdev ;

>----- -----<

>----- ------ -----<

/CRS ongeregelde conflicten

(niet verplicht)

;crsnum crspos kyksgm1 kykpos1 kykgap1 kykdev1

.....

kyksgm# kykpos# kykgap# kykdev#

;

>---<

>------ ------- ------- ------<

>------ ------- ------- ------<

/NOQ noqueueing zones

(niet verplicht)

;noqnum noqend1 noqbeg1

.....

noqend# noqbeg#

;

>---<

>------ ------<

>------ ------<

/FLW intensiteitsverdeling over kruispunt ;flwtyp fentry fexit1

...

fexit9

;

---

-----<

>-----

(verplicht)

/TSG stopstrepen en signaalgroepen

(niet verplicht)

;tsgcon tsgsgl tsgnum1 tsgpos1

.....

tsgnum# tsgpos#

;

>---<

>------ ------<

>------ ------<

/DET detectoren

(niet verplicht)

;detcon detsgl detvrs dettyp detnum1 detend1 detbeg1

.....

detnum# detend# detbeg#

;

>---<

>------ ------- ------<

>------ ------- ------<

/DIS intensiteitsverdeling over segmenten ;disnum distyp distos1 discnt1

.....

distos# discnt#

;

>---<

>------ ------<

>------ ------<

//END

(niet verplicht)

(verplicht)

3.2 Segmenten

Segmenten vormen de kern van FLEXSYT-II-. Een segment is een (deel van een) rijstrook. Bij het segment moet een aantal kenmerken worden opgegeven die de situatie van die rijstrook weergeven. De begrenzing en ligging van segmenten wordt bepaald door een aantal factoren: begin netwerk, einde netwerk, invloedsgebied, samenkomst van rijstroken (merging), verbreding naar meer rijstroken. De eerste twee factoren spreken voor zich: het te onderzoeken netwerk begint ergens en houdt ergens op. Omdat de gegevens voor de overzichtelijkheid gegroepeerd zijn naar het invloedsgebied van een kruispunt, zullen grenzen tussen kruispunten gelegd moeten worden. De laatste twee factoren liggen ook voor de hand: omdat een segment een enkele rijstrook is,


12

moeten bij verbreding (bijvoorbeeld bij aankomen bij opstelvakken) meerdere segmenten worden opgegeven. Bij het verlaten van het kruispunt zal vaak verkeer dat over verschillende rijstroken gaat via gemeenschappelijke rijstroken het kruispunt verlaten. In figuur 4 is een voorbeeld van een segment gegeven. ................................... Figuur 4:

Voorbeeld van een segment divergentie punt

positie lange lus positie korte lus positie stopstreep

convergentie punt

Bij segmenten worden de volgende attributen opgegeven: segment nummer, kruispunt armnummer waarop segment gelegen is, lengte, verzadigingsintensiteit (capaciteit), wenssnelheid, verdeling van wenssnelheden en nummers van benedenstrooms gelegen segmenten. De samenhang van het netwerk wordt dus bepaald door voor elk segment aan te geven waar het verkeer, wanneer het aan het einde van dat segment is aangekomen, naar toe kan gaan.

3.3 Internode segment

Het netwerk kent een bijzonder type segment: het internode segment. Dit segment geeft in principe een stuk wegvak weer dat buiten de directe invloedssfeer van elk kruispunt valt. Het voertuiggedrag is hierbij minder van belang zodat in het programma op dit soort segmenten een vereenvoudigd model wordt gehanteerd, waardoor winst in rekentijd wordt geboekt. Het internode segment wordt vooral toegepast als voedend segment voor een kruispunt. Het internode segment is dan aangesloten op een generator of op de exit-segment(en). Er wordt dan rekening gehouden met het feit dat verkeer een kruispunt op een bepaalde manier verlaat (pelotonvorming).


13


14

4 Simulatie parameters .............................................................................................

4.1 Subruns

In FLEXSYT-II- is één volledige simulatie een subrun. Dit kan bijvoorbeeld worden opgevat als de simulatie van één volledige ochtendspits. Om statistische zekerheid te krijgen is het nodig om meer dan één subrun uit te voeren. Een aantal gegevens, bijvoorbeeld verliestijden, gemiddelde snelheid, etc. wordt bepaald per subrun. Deze per subrun verkregen waarden worden geïnterpreteerd als afzonderlijke metingen waarop statistische bewerkingen worden uitgevoerd. Het is duidelijk dat voor statistische betrouwbaarheid een voldoende aantal subruns nodig is. FLEXSYT-II- kent een mechanisme waarmee de gebruiker van tevoren de gewenste betrouwbaarheid kan opgeven. De simulatie zal dan automatisch zoveel subruns draaien als voor die betrouwbaarheid nodig is.

4.2 Tijdsperioden

Vaak zal in een te onderzoeken situatie niet alleen de tijdsperiode waarin de verkeersintensiteit maximaal is, worden onderzocht maar ook de voorafgaande opbouw en navolgende afbouw. Bijvoorbeeld omdat de effecten van congestie ook in de afbouwfase kunnen doorwerken. Om toch een reëel beeld te kunnen geven met betrekking tot de verkeersintensiteiten gedurende de verschillende fasen van de subrun worden tijdsperioden (timeslices) gehanteerd. Dit zou ook opgevat kunnen worden als sub-subruns. De verkeersintensiteiten gedurende deze tijdsperioden en de tijdsduur moeten worden opgegeven. Aan het einde van iedere voltooide subrun wordt de bereikte significantie van de tot dan verzamelde gegevens van de simulatie afgedrukt. .................... Figuur 5:

Invoerframe SIMDAT

//title record

(verplicht)

/SIM

(verplicht)

;nsbrun autsig1 .. autsig8 resume regpar respar rndstr giper sclfac1 .. sclfac8 strtrc ;

>------ -- ------<

>----- -----<

>------ -- ------<

/TIM

(verplicht)

;vortim btween timper1 timper2 ..... timper# ;

>------ ------- ----- ------<

/VEH

(niet verplicht)

;vehtyp vehlen vehacc vehdec vehspd ;

>----- -----<

/ENV

(niet verplicht)

;vehtyp vehmas fueltyp1 fueltyp2 fueltyp3 fueltyp4 fueltyp5 percvan ;

>------- -------- -------- -------- -------<

/MTM

(niet verplicht)

;mtmdel //END


(verplicht)

15

In afbeelding 5 is een invoerframe van de simulatie parameters gegeven. Binnen het bestek van deze syllabus gaat het te ver deze verder uitgebreid te beschrijven. Hiervoor verwijzen we naar de handleiding van FLEXSYT-II-. Nog wel kan worden opgemerkt dat de voertuigkenmerken kunnen worden veranderd. Ook de verhouding tussen de verschillende soorten gebruikte brandstoffen in een wagenpark kan worden aangepast indien deze in de toekomst wijzigt.


16

5 Voertuigmodellen .............................................................................................

5.1 Voertuigtypes

In FLEXSYT-II- wordt een vereenvoudigd model voor voertuigen gehanteerd, hetgeen een compromis vormt tussen een vrij realistische weergave van de werkelijkheid en een beperkte hoeveelheid rekenwerk om de simulatie uit te voeren. FLEXSYT-II- kent 8 typen voertuigen: personenauto's, lichte vrachtwagens, zware vrachtwagens, bussen, trams, fietsers, voetgangers en carpoolvoertuigen.

5.2 Voertuigkenmerken

Langzaam verkeer en snelverkeer dat zich geheel op een internode segment bevindt, heeft een zeer eenvoudig stop/go gedrag. Een stop/go gedrag houdt in dat voertuigen wanneer zij kunnen rijden, direct op volle snelheid rijden en wanneer zij moeten stoppen direct stilstaan. Er is dus geen sprake van acceleratie of deceleratie. Voertuigen die zich niet in hun volle lengte op een internode segmenten bevinden, vertonen een parabolisch acceleratie- en deceleratiegedrag. Hiervoor zijn voor de verschillende typen voertuigen de default waarden voor acceleratie en deceleratie geschat. Dit is gedaan aan de hand van de ontwerpvoertuigen van Rijkswaterstaat (met uitzondering van voertuigtype tram). Per voertuig zit er een kleine (bestuurdersafhankelijke) variatie in de waarden, maar elk voertuig zal altijd met zijn acceleratie- en deceleratiewaarde optrekken en afremmen. Voor snelverkeer zijn ook de default lengtematen vastgesteld aan de hand van de ontwerpvoertuigen van Rijkswaterstaat (wederom met uitzondering van voertuigtype tram). Langzaam verkeerstypes (fietser en voetganger) zijn lengteloos verondersteld, zodat deze typen een oneindige opstelcapaciteit hebben. De default voertuiggegevens, getabelleerd in tabel 1, kunnen naar eigen inzicht gewijzigd worden. ................................... Tabel 1:

Default voertuigkenmerken

Voertuigtype

Acceleratie (m/s2)

Deceleratie (m/s2)

Lengte (m)

................

...............

...............

.........

personenauto

2,00

3,00

kleine vrachtwagen

0,60

2,00

9,0

grote vrachtwagen

0,40

2,00

16,0

bus

9,60

2,00

11,0

tram

1,25

2,00

26,0

fietser

-

-

-

voetganger

-

-

-

carpoolvoertuig

2,00

3,00

4,6

4,6

Elk voertuig krijgt bij generatie een bestuurdersparameter mee, deze parameter geeft aan hoe beheerst dan wel assertief de bestuurder reageert op het verkeersbeeld. De invloed van de bestuurdersparameter uit zich in de volgende aspecten bij assertief gedrag:


17

· · · ·

acceleratie- en deceleratiewaarden: abrupter optrekken en afremmen; volgtijd: op segment overgangen een kortere volgtijd; snelheidsdeviatie: de afwijking van het gemiddelde, harder rijden; ongeregeld conflict: eerder beslissen een hiaat te accepteren.

5.3 Voertuigaankomsten

Aan de rand van het te onderzoeken netwerk komen voertuigen het netwerk binnen. In FLEXSYT wordt dit gesimuleerd door daar generatoren te plaatsen die met de opgegeven intensiteit voertuigen het netwerk insturen. Door de gebruiker kunnen die intensiteiten worden gespecificeerd, deze waarden gelden als gemiddelde intensiteiten. Om de werkelijkheid goed weer te geven, wordt een negatief exponentiële verdeling aangehouden. Dit leidt tot de vaak gebruikte Poisson-verdeling. In tegenstelling tot bovenstaande komen voertuigen van het openbaar vervoer wel met een zekere regelmaat aan bij de rand van het netwerk. De gemiddelde aankomsttijden worden bepaald uit de door de gebruiker opgegeven (gemiddelde) intensiteit. In de praktijk blijkt op deze tijd ook enige afwijking te zitten. De gebruiker kan de grootte van de afwijking opgeven door middel van een "regelmatigheidsfactor".

5.4 Mergeconflict

Het mergeconflict speelt zich af waar voertuigen uit verschillende bronnen (vrijwel) tegelijkertijd naar een zelfde segment willen. Dit komt voor bij voertuigen uit generatoren of uit segmenten. In deze situatie kan slechts één van voertuig doorrijden en moet(en) de andere(n) voorrang verlenen. De keuze valt uit in het voordeel van het voertuig dat het eerste aankwam. Indien mogelijk wordt een mergeconflict vermeden. Dit kan indien er voor het segment waar elkaar hinderende voertuigen naar toe willen gaan, een goed alternatief is. Het voertuig dat anders ten gevolge van het conflict had moeten wachten rijdt nu direct door naar het gelijkwaardige segment.

5.5 Ongeregeld conflict

Het ongeregelde conflict, of secundaire conflict, is een normaal voorrangsconflict tussen twee voertuigen. In deze situatie is er één segment waarop het verkeer voorrang moet geven aan het verkeer op één of meer andere segmenten. Een voertuig geeft voorrang zolang zich in de stroom voertuigen waaraan het voorrang moet geven, geen voldoende grote hiaattijd tussen twee voertuigen voordoet.

5.6 Halteren

Het halteren is een onderdeel van het routekeuze mechanisme. Indien wordt vastgesteld dat een voertuig moet halteren krijgt het als een attribuut de tijd mee gedurende welke het moet halteren. Met halteren kan ook een blokkade (catastrophic event) worden gesimuleerd: een brug die een bepaalde tijd wordt geopend. Dit effect wordt verkregen door gebruik te maken van de halteringsparameters die bij de pocket zelf worden opgegeven en door de pocket zodanig te positioneren dat een halterend voertuig de doorgang voor andere voertuigen blokkeert.


18

5.7 Inhalen

Alleen op internode-segmenten kunnen voertuigen elkaar inhalen. De gebruiker geeft op welk snelheidsverschil er tussen de voertuigen moet bestaan om inhalen mogelijk te maken. Bovendien is voor daadwerkelijk inhalen ook nog vereist dat de actuele situatie op het internode-segment zodanig is dat het voertuig dat wil inhalen, deze manoeuvre volledig kan voltooien op het internode-segment zelf. Op gewone segmenten kan niet ingehaald worden, omdat segmenten rijstroken representeren. Wisselen van rijstrook kan daarom alleen bij overgangen tussen segmenten. Het mechanisme voor de keuze van rijstroken wordt hieronder besproken.

5.8 Routekeuze

Het routekeuze-mechanisme zorgt er voortdurend voor dat een voertuig, aangekomen bij het einde van een segment of bij het verlaten van een generator, het juiste opvolgende segment kiest. Hierbij spelen een aantal aspecten een rol (in volgorde van prioriteit): · toegestane voertuigtypen op segmenten, zoals door de gebruiker opgegeven; · exit-armen waar segmenten doorgang toe bieden; · mechanisme ter voorkomen van rondrijden; · halteren op een pocket; · gedwongen distributie verdeling; · mergeconflict; · bezettingsgraad segment; · standaard keuze. De eerste twee aspecten vormen een voorselectie, waarbij een aantal segmenten sowieso moet afvallen, omdat het voertuigtype niet is toegestaan of omdat de beoogde uitgang van het kruispunt niet via dat segment kan worden bereikt. Met de overblijvende segmenten worden de volgende aspecten gewaardeerd. Een volgende afweging in de rij wordt gemaakt indien op grond van voorgaande afwegingen geen segment kan worden gekozen. Indien een voertuig bij het verlaten van een segment de keuze heeft uit meerdere volgende segmenten, bijvoorbeeld omdat er voor een stopstreep meerder opstelvakken zijn, dan kiest het voor het segment met de kleinste bezettingsgraad, berekend uit segmentlengte en de gesommeerde lengte van de aanwezige voertuigen. Dit mechanisme werkt niet als er een gedwongen distributie is opgegeven. De standaardkeuze bestaat uit een loting.

5.9 Detectie

De informatie ten behoeve van het regelprogramma omtrent de aanwezigheid van voertuigen in het netwerk, wordt verkregen uit detectorinformatie. De detectoren hebben hiertoe een actuele waarde welke, als deze verandert, aan de regelaar wordt doorgegeven. De wijze waarop de waarde van de detector verandert, is afhankelijk van het geheel van voertuigmodellen. Er worden vijf typen detectoren onderscheiden: selectief voor voertuigtype 4 en 5, snelheid, aanwezigheid op lange lus, analoge bezettingsgraad lange lus en aanwezigheid op korte lus.


19

5.10 Verkeerssignalering

Bij het werken in de praktijk met het programma, is gebleken dat er behoefte bestaat aan het introduceren van bepaalde aspecten van autosnelwegsignalering (MTM). Deze aspecten zijn ingebouwd en betreffen: · het (tijdelijk) 'afkruisen' van een rijstrook. Dit betekent dat het voertuigen verboden wordt een bepaald segment, gedurende zekere tijd, niet te gebruiken; · het tonen van snelheidslimieten. Dit betekent dat voertuigen zich niet meer zullen houden aan de opgegeven snelheid van een segment, maar de getoonde (lagere) snelheid. Verder zijn nog een tweetal faciliteiten ingebouwd, te weten: · inhaalverbod vrachtverkeer. Dit houdt in dat bepaalde segmenten (dynamisch) afgesloten kunnen worden voor de voertuigtypen 2 en 3. · busstrook. Met deze optie kunnen segmenten alleen voor voertuigtype 4 bestemd worden en dit kan ook weer dynamisch. De signalering wordt gestuurd met behulp van FLEXCOL-76-. Op dezelfde manier als gewone verkeerslichten kunnen matrixsignaalgevers aangestuurd worden. De beeldstand wordt bepaald door de index van de signaalgroep. Het onderstaande geeft een voorbeeld: S_GROEN_011 .= S(_INIT_TIMER_=10000) S_GROEN_027 .= S_PROC_.(INTENSITEIT_02 > 4000).(SNELHEID_02 < 70) In de eerste regel wordt op seconde 10000 een kruis geplaatst op signaalgever 01 en indien de intensiteit boven de 4000 vrt/uur komt en de snelheid onder de 70 km/uur dan wordt op signaalgever 02 de maximumsnelheid 70 km/uur getoond. Uiteraard zijn dit maar voorbeelden.

5.11 Congestie

Congestie kan op twee manieren optreden tijdens de simulatie: · doordat een wachtrij zover groeit, dat op een bepaald moment een generator geen verkeer meer kwijt kan op het segment dat erop is aangesloten; · doordat de capaciteit van de generator (tijdelijk) zo hoog is, dat de interne buffering deze overcapaciteit niet kan opvangen. In het eerste geval zal er vaak sprake zijn van congestie ten gevolge van een fout in de regeling of een fout in de specificatie van het netwerk. In het laatste geval is het mogelijk dat segmenten niet goed zijn aangesloten waardoor stroomafwaarts de capaciteit van het netwerk te klein is, zodat een bottleneck ontstaat, of dat de intensiteit van een generator niet goed is afgestemd ten opzichte van de capaciteit van het aangesloten segment.


20

6 Uitvoer .............................................................................................

6.1 Inleiding

Gezien de voorgeschiedenis van FLEXSYT-I- en FLEXSYT-II-, is de uitvoer nog sterk tabel georiënteerd. Extreme waarden kunnen inzicht geven in eventuele fouten in de regeling of beperkingen in het civieltechnische ontwerp. De tabellen worden per timeslice en voor de totale simulatie aangemaakt.

6.2 Beschrijvingen

Signaalgroepentabel In de signaalgroepentabel worden de resultaten afgedrukt van de opgetreden duur van de 'niet-groen-', de groen- en de cyclustijden gedurende de simulatie. Tevens wordt de frequentie per tijdsduurklasse berekend en afgedrukt. Deze tabel geeft inzicht in de gerealiseerde regeling. Rijstrokentabel In de rijstrokentabel worden de resultaten van de reistijdverliezen gegeven die de voertuigen per rijstrook gemiddeld ondervonden hadden op het moment dat de stopstreep gepasseerd werd. De verliezen van de voertuigen worden gesommeerd vanaf het moment dat het voertuig gegenereerd wordt tot het moment dat de stopstreep gepasseerd wordt en bijgehouden per subrun. Na passage van een stopstreep wordt opnieuw begonnen met het meten van de verliestijd. Segmententabel De segmententabel geeft informatie over de intensiteit, vertraging en de lengte van de maximale wachtrij voor elk segment, gemiddeld over de subruns en gemiddeld over de timeslices. Wachtrijtabel Indien de duur van een subrun of tijdsperiode te lang is om wachtrijen grondig te analyseren, kan met deze tabel de wachtrij per cyclus bestudeerd worden. Voor de cyclus is gekozen de cyclustijd van de eerste signaalgroep van het eerste kruispunt gespecificeerd in de NETDAT-dataset. Stopstrepentabel In de stopstrepentabel worden de resultaten van de verliezen gegeven per voertuigtype die de voertuigen ondervonden hebben op het moment dat ze de stopstreep passeren. De verliezen van de voertuigen worden gesommeerd vanaf het moment dat het voertuig gegenereerd wordt tot het moment dat de stopstreep gepasseerd wordt. Hierna wordt opnieuw begonnen zodat bij de passage van meerdere stopstrepen alleen de tussengelegen verliezen vermeld worden. Kruispuntentabel In de kruispuntentabel worden de resultaten gegeven van de verliezen per voertuigtype die de voertuigen voor de verschillende verkeersstromen hadden


21

op het moment dat het kruispunt via een exit-segment werd verlaten. De verliezen van de voertuigen worden gesommeerd vanaf het moment dat de 'head' van een voertuig op een entry-segment van het kruispunt binnenkomt tot het moment dat de 'head' van een voertuig van een exit-segment vertrekt en wordt bijgehouden per subrun. Na passage van een kruispuntgrens wordt opnieuw begonnen met het meten van de verliestijd. Voertuigtotalentabel Een aantal gegevens (totaal afgelegde afstand, totale doorgebrachte tijd, totale vertraging, totaal aantal stops, gemiddelde snelheid) wordt per subrun voor alle voertuigen van een type gesommeerd. Bij bestudering van de verschillen tussen onderzochte regelingen zullen deze gegevens al een eerste indruk geven van de mate waarin de ene variant beter of slechter is dan de andere variant. Milieueffectentabel voor kruispunt In deze tabel worden per kruispuntrelatie (entry-arm naar exit-arm) de milieueffecten gegeven, gemiddeld over de voertuigen. Hierbij wordt gerekend met het brandstofverbruik en de uitstoot van CO, HC, NOx, vaste deeltjes, CO2 en SO2. Deze modellen zijn vergelijkbaar met het FACTS- en het ATTACK-model van het NEI en gebaseerd op het VERSIT- en CORINAIR-model van TNO-IW. Voor voertuigtype 5 (trams) hebben 'deskundigen' de milieueffecten geschat. Milieueffectentabel voor netwerk In deze tabel worden per voertuigtype per subrun de milieueffecten gegeven. Het gaat daarbij om totalen voor het netwerk.

6.3 Ontwikkelingen

In de huidige versie van FLEXSYT-II- is de uitvoer sterk uitgebreid. In de oude uitvoer waren voor bepaalde tabellen alleen waarden beschikbaar voor de gehele simulatie, bijvoorbeeld de groentijden tabel of de tabellen met reistijden. Deze gaven gemiddelde waarden over de hele simulatie weer. Het is echter soms handig om ook deze waarden voor elke timeslice beschikbaar te hebben. In de huidige versie is dat beschikbaar. Uitgangspunt voor al deze tabellen is dat het vertrek van het voertuig bepaalt bij welke timeslice deze hoort.


22

7 Programmatische aspecten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . .

7.1 Programmeertaal Fortran

De programma’s van FLEXSYT-II- zijn geschreven in de programmeertaal Fortran, een afkorting van Formula Translator. De eerste versie van deze programmeertaal is ontwikkeld in de jaren ‘50. Voor de ontwikkeling van FLEXSYT-II- is de versie toegepast waarvan de standaard in 1977 is vastgesteld, deze versie wordt aangeduid als "Fortran-77". Fortran wordt voornamelijk gebruikt voor rekenkundige processen voor technisch/wetenschappelijke toepassingen en is daarvoor geoptimaliseerd. Dit komt tot uiting in de rekensnelheid van computerprogramma’s die in deze programmeertaal zijn ontwikkeld. Dit ten koste van enkele technieken die voor de ontwikkeling van FLEXSYT-II- van belang zijn: · object georienteerdheid, · datastructuren, · dynamisch geheugenbeheer. Deze tekortkomingen zijn opgelost door de manier waarop FLEXSYT-II- is geprogrammeerd. Echter, het ontbreken van dynamisch geheugenbeheer heeft voor de gebruiker merkbare gevolgen. Door de beheerder wordt bij het samenstellen van een pakket voor een gebruiker de omvang van de simulatiegegevens ingesteld. Deze omvang van de simulatiegegevens is vrij groot gekozen zodat probleemloos grote simulaties kunnen worden uitgevoerd. Zodra het programma wordt gestart neemt het deze geheugenruimte in beslag. Indien echter kleine problemen worden gesimuleerd wordt meer geheugen van het PC-systeem in beslag genomen dan nodig en wanneer bijzonder grote simulaties worden uitgevoerd is dit niet mogelijk zonder tussenkomst van de beheerder. De huidige instelling van de omvang is 4 miljoen bytes, wat simulaties met circa 16.000 voertuigen mogelijk maakt. Overigens kennen de nieuwste standaarden van Fortran (Fortran-90 respectievelijk Fortran-95) deze tekortkomingen niet meer. Toen deze standaarden echter werden vastgesteld, was de ontwikkeling van FLEXSYT-IIprogrammatuur reeds zover gevorderd, dat aanpassingen hiervoor tot grote vertraging zou hebben geleid. De gebruikte Fortran-compiler (= hulpprogramma dat van Fortran-programmacode een werkbaar programma maakt) maakt geen volledige Windows programma’s. Weliswaar zijn de programma’s voorzien van een Windowskader en menustructuur, maar de weergave is op de gebruikelijke DOS-manier. Door het Fortran-rekengedeelte te koppelen aan een grafische schil wordt dit ondervangen. Juist dit is gedaan in FLASH.

7.2 Windows95/98/ME/2000/NT 7.2.1 Multitasking

In naam zijn zowel Windows95, Windows98 als Windows ME multi-tasking operating systems, wat zeggen wil dat tegelijk meerdere programma’s kunnen draaien. Deze multi-tasking wordt echter niet afgedwongen, maar is sterk


23

afhankelijk van de bereidwilligheid van programma’s die actief zijn om anderen ook rekentijd te gunnen. Dit wordt aangeduid als “cooperative multi-tasking”. De gebruikte Fortran compiler zorgt ervoor dat FLEXSYT-II- programma’s regelmatig de controle teruggeven aan het operating system. Toch is dit niet optimaal en zullen andere programma’s, die tegelijk met FLEXSYT-IIprogramma’s draaien, daar af en toe last van ondervinden. Door de structuur waarin FLASH is opgezet doet dit probleem zich daar niet voor. Windows 2000 en NT zijn geheel anders opgezet dan Windows95 en Windows98 en kennen dit probleem dan ook niet. Multitasking wordt door deze operating systemen geforceerd, dit wordt aangeduid als “pre-emptive multitasking”. 7.2.2 Intern geheugen

Intern geheugen is de hoeveelheid RAM-geheugen in de vorm van geheugenchips die in een PC zit. Bij inschakelen van een PC wordt dit altijd geteld, gangbare hoeveelheden zijn: 32, 64, 128 MB enzovoorts. Windows kent een systeem van virtueel geheugen: naast de hoeveelheid direct RAM-geheugen in de vorm van chips wordt ook een deel van de harddisk gebruikt als verlengstuk van het interne geheugen. Die ruimte op de disk heet de swapfile. Wanneer een deel van het geheugen enige tijd niet wordt gebruikt, wordt het door Windows naar harddisk geschreven, zodat het weer vrij is voor ander gebruik. Dit maakt dat de er schijnbaar meer geheugenruimte beschikbaar is dan werkelijk aanwezig in de vorm van chips. Wanneer er echter veel wordt gewisseld tussen chips en disk, wordt het systeem aanzienlijk trager: vertragingen van factor 100 tot factor 1000 zijn heel gewoon. Behalve door een trage uitvoering van programma’s komt dit ook tot uiting door een zeer drukke harddisk. Voor een snelle uitvoering van FLEXSYT-II- programma’s is het nodig dat de hoeveelheid intern geheugen (aanzienlijk) meer is dan het programma. Hierbij moet rekening worden gehouden met alle programma’s die tegelijk draaien en Windows zelf. Bij de huidige stand van PC’s is 128 à 256 MB intern geheugen een gebruikelijke waarde. Voor FLEXSYT-II- (en FLASH) is dit ruim voldoende. 7.2.3 File associaties / Filetype

In FLEXSYT-II- is het gebruikelijk om bepaalde extensies te gebruiken voor de verschillende files zoals in tabel 2. Door deze associaties in Windows toe te passen kan eenvoudig het bijbehorende programma worden gestart. Bijvoorbeeld FLXNETW.EXE indien een bestand met extensie ‘.NET’ dubbel wordt aangeklikt. Dit vergemakkelijkt het werken aanzienlijk. In Windows 98 kunnen filetypen worden gedefinieerd. Daarmee worden associaties gemaakt, maar is het bovendien mogelijk andere acties te definiëren. De FLEXSYT-II- programma’s maken hiervan geen gebruik. Volgens de helptekst van Windows 98 kan een filetype als volgt worden gedefinieerd: · In My Computer or Windows Explorer, on the View menu, click Folder Options. · Click the File Types tab, and then click New Type. · In Description of type, type the appropriate information for the new file type. · In extension, type the extension you want for the new file type. · Click New. · In Action, enter the action that you want to define (such as Open or Print). · In Application used to perform action, enter the command that you want to complete this action, and then click OK. Met de huidige installatieprogrammatuur gebeurt dit automatisch.


24

............................... Tabel 2: Files en extensies

bestandsnaam / bestand

extensie

verwerking door

. .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

.............

..... .........

MANDAT (managerdata, FLEXCOL)

*.MAN2

FLXMANW

Gecompileerde MANDAT (uitvoer FLXMANW)

MANFIL2

FLXCONW

CONDAT (regelaar applicatiedata, FLEXCOL)

*.CON2

FLXCONW

Gecompileerde CONDAT (uitvoer FLXCONW)

CONFIL2

FLXSIM/FLXRESW/ FLXREGW

*.C of *.H2

C-sources (RWS C-regelaar) ++

RWS C-regelaar (uitvoer C

compiler)

C++ compiler 2

RWSCREG.DLL

simulatie

NETDAT (netwerkdata)

*.NET

FLXNETW

gecompileerde NETDAT (uitvoer FLXNETW)

NETFIL

FLXSIM/FLXRESW

SIMDAT (simulatiedata)

*.SIM

FLXSIM/FLXRESW/ FLXREGW

resultaten simulatie verkeer (uitvoer FLXSIM)

TRFFIL

FLXRESW

resultaten simulatie verkeer (uitvoer FLXRESW)

RESFIL

editor

status FLEXCOL-regelaar (uitvoer FLEXCOL-regelaar)

CNTFIL2

FLXREGW

tabel statusoverzicht FLEXCOL-regelaar (uitvoer FLXREGW)

REGFIL2

editor

loglijst acties/reacties FLEXCOL-regelaar (uitvoer FLEXCOL)

TRCFIL2

editor

netwerktoestand einde subrun ### (uitvoer FLXSIM)

RSMFIL.###

FLXDMPW

netwerktoestand bij congestie (uitvoer FLXSIM)

RSMFIL.DMP

FLXDMPW

netwerktoestand (uitvoer FLXDMPW)

DMPFIL

editor

foutmeldingen

???ERR

editor

7.2.4 Bestandsbeheer

Standaard wordt bij Windows95/98/ME/2000/NT Verkenner meegeleverd voor bestandsbeheer (in de Engelse versie heet dit programma Explorer, niet te verwarren met de Microsoft Internet browser met dezelfde naam). Omdat een programma voor bestandsbeheer zeer veel wordt gebruikt is het belangrijk dat hiermee prettig kan worden gewerkt. Er zijn dan ook een aantal alternatieve programma’s beschikbaar om Explorer te vervangen. Deze programma’s zijn in de regel vrij goedkoop en verhogen de productiviteit. Noemenswaardig in deze categorie zijn Windows Commander of het gratis 2xExplorer. 7.3 Event-by-event simulatie

De snelheid waarmee simulaties worden uitgevoerd is belangrijk. Indien er (te) lang moet worden gewacht voordat resultaten beschikbaar zijn, dan verliest een simulatieprogramma zijn waarde. De tijd die de computer nodig heeft om de simulatie uit te voeren wordt aangeduid als rekentijd; de hoeveelheid gesimuleerde tijd simulatietijd. Naarmate de verhouding simulatietijd/rekentijd groter is, wordt er dus sneller gesimuleerd. FLEXSYT-II- is net als FLEXSYT-I- een micro-simulatiemodel: een model waarbij individuele voertuigen worden gesimuleerd. Dit in tegenstelling tot bijvoorbeeld TRANSYT dat met voertuigstromen werkt. Het afzonderlijk simuleren van voertuigen met alle bijkomende detaillering brengt echter wel zeer veel rekenwerk met zich mee. 2


Bestand staat in de regelaardirectory

25

Om de rekentijd te beperken wordt in FLEXSYT de simulatie uitgevoerd op basis van ‘event-by-event’. Hierbij wordt alleen rekentijd besteed aan een object (voertuig, verkeerslicht, etc) in de simulatie als daar iets ‘interessants’ mee gebeurd. Echter, slechts een klein deel van de acties die objecten in de simulatie uitvoeren zijn interessant. Op deze manier wordt veel rekentijd aan oninteressante gebeurtenissen bespaard. De tegenhanger van deze wijze van simuleren heet ‘timestep’ simulatie, bij deze wijze wordt met regelmatige tijdstappen naar alle objecten in de simulatie gekeken om acties door te rekenen. Het verschil tussen beide typen simulaties wordt duidelijk gemaakt aan de hand van figuren 6 en 7. In beide gevallen gaat het om een verplaatsing van een voertuig over een stuk weg met de volgende gegevens: · voertuigsnelheid 90 [km/h] = 25 [m/s] · af te leggen afstand 30 [m] · simulatietijd: 30 / 25 = 1.2 [s] · nadat de achterzijde van het voertuig op het stukje wegvak is gekomen, is de eerstvolgende belangijke gebeurtenis dat de voorzijde van het voertuig bij het einde van het wegvak komt. ................................ Figuur 6:

Timestep simulatie

1

2

3

4

5

t=0

v = 90 km/h = 25 m/s

t = 1.2 S = 30 m

In figuur 6 is de timestep simulatie weergegeven. De tijdsstap is 0.3 seconde. Dit betekent dat op een bepaald moment de situatie in het systeem model wordt bepaald. Daarna wordt de tijd 0.3 sec verder gezet en wordt opnieuw bepaald wat de situatie in het systeem is. In de periode van 1.2 [s] komen dus 4 stappen voort. Als de hoeveelheid rekenwerk die nodig is om de situatie na elke stap te bepalen 10 [ms] duurt, bedraagt de totale rekentijd 40 [ms]. ................................ Figuur 7:

Event-by-event simulatie

1

2

t=0

v = 90 km/h = 25 m/s

S = 30 m

t = 1.2

Figuur 7 toont dezelfde simulatie in event-by-event. Omdat de eerstvolgende belangrijke gebeurtenis pas na het afleggen van de 30 [m] is, hoeft de


26

berekening nu maar een keer te worden uitgevoerd. De benodigde rekentijd is daardoor slechts 10 [ms]. Omdat de timestep voor een nauwkeurige simulatie klein moet zijn (orde grootte: 0.01 [s]) is het verschil tussen de twee manieren van simulatie veel groter dan in dit voorbeeld. Een nadeel van event-by-event simulatie is echter wel dat de berekeningen op zich complexer zijn. Bij het timestep model hoeft slechts de huidige situatie te worden bepaald en een klein constant tijdsinterval vooruit te worden gekeken. In het event-by-event model moeten vaak grotere voorspellingen worden gedaan. Deze voorspellingen zullen vaak niet uitkomen vanwege veranderde omstandigheden waardoor weer extra gerekend moet worden. Dit is bijvoorbeeld het geval indien het voertuig uit het voorbeeld in een cluster rijdt en het voorste voertuig begint af te remmen. Hierdoor zal het voertuig niet op de snelheid van 90 [km/h] kunnen blijven rijden en zal de gedane voorspelling over de reistijd een aankomsttijdstip herzien moeten worden. Om relatief eenvoudig voorspellingen te kunnen doen worden segmenten opgedeeld in wegvakken met een constant kenmerk: netwerkelementen. Bijvoorbeeld: · wegvak met aan einde lengteloze detector · wegvak met detector over volle lengte · wegvak met aan einde stopstreep van verkeerslicht Het programma FLXNETW converteert de invoer die in segmenten wordt gedaan naar een intern formaat. In dit interne formaat worden segmenten opgedeeld in wegvakken met constant kenmerk. Dit wordt hieronder duidelijk gemaakt in figuur 8. ................................ Figuur 8:

Opsplitsing segment in netwerkelementen

Het opgegeven segment heeft een aantal attributen, in rijrichting: bushalte, detector met lengte en korte lus detector samen met stopstreep van verkeerslicht. Gebruikers van FLEXSYT-I- zullen dit herkennen als de netwerkelementen waarmee een netwerk moest worden gebouwd.

7.4 Visualisatie

Het is mogelijk om met FLASH 2-dimensionale visualisaties te zien van FLEXSYT simulaties. In het in FLASH getekende netwerk worden dan rijdende auto’s nagebootst. Vanwege de event-by-event opzet van de simulatie is het niet mogelijk om deze visualisatie direct tijdens de simulatie uit te voeren. Neem als voorbeeld


27

een voertuig dat over een segment rijdt (zie figuur 9): als deze op moment t1 op het segment komt is het verkeerslicht dat verderop staat nog groen. Dus in de simulatie wordt een voorspelling gedaan wanneer het voertuig daar aankomt en dat wordt het volgende event. Bij aankomst op t3 blijkt het licht echter rood te zijn geworden en het voertuig moet dus stoppen. Dit kan echter niet ineens en dus had het voertuig al eerder moeten beginnen met afremmen (t2) waardoor het uiteindelijk wat later bij het verkeerslicht aankomt: t4. ................................ Figuur 9:

Correcties bij event-by-event simulatie

t1 t2 t3

t4

Als dit zo zou worden geanimeerd zou het voertuig eerst constante snelheid over het segment rijden, op t3 ineens een stuk terugspringen en vervolgens eenparig vertraagd afremmen. Hoewel FLEXSYT dit verplaatsingsgedrag correct berekent, geeft dit op het beeldscherm een onrustige en bovendien onbetrouwbare weergave. Om deze reden is gekozen om tijdens de simulatie-berekening alleen events te loggen en dit naderhand met een conversie programma zichtbaar te maken in een animatie. Hierdoor rijden de voertuigen in de animatie wel vloeiend. Een bijkomend voordeel is dat de simulatieberekening zelf nog steeds snel kan worden uitgevoerd, een van de sterke punten van FLEXSYT.

7.5 Optimalisatie

In de context van programmatische aspecten is het doel van optimalisatie om simulaties zo snel mogelijk uit te voeren oftewel de rekentijd te beperken. Om dit te bereiken zijn verschillende optimalisaties mogelijk zowel buiten FLEXSYT als daarbinnen. 7.5.1 Optimalisaties buiten FLEXSYT

Deze hebben voornamelijk met Windows en de PC zelf te maken. FLEXSYT simulaties worden het snelst uitgevoerd indien ze ongehinderd kunnen beschikken over een aantal componenten (resources) van het computersysteem: processor, geheugen en harddisk. De processor is de centrale verwerkingseenheid: de chip waar het eigenlijke werk in een PC plaatsvindt. Alle programma’s die op een PC draaien zijn van deze processor afhankelijk. Als er op een bepaald moment meerdere programma’s tegelijk draaien wordt de rekenkracht van de processor verdeelt over deze programma’s. FLEXSYT simulaties worden dus sneller uitgevoerd indien er tegelijk minder andere programma’s actief zijn. Alleen de gegevens die zich in het interne RAM geheugen van de PC bevinden kunnen door de processor worden verwerkt. De hoeveelheid intern geheugen is in moderne PC’s vrij ruim (128 MB of meer), maar toch altijd beperkt. Zoals eerder is behandeld heeft Windows een virtueel geheugenmechanisme waarbij


28

een deel van de ruimte op de harddisk wordt gebruikt als een verlengstuk van het interne geheugen, maar wel in een zeer langzame uitvoering. Indien er zoveel geheugen in gebruik is door FLEXSYT en andere programma’s dat het interne RAM geheugen volledig wordt gebruikt, gaat Windows delen daarvan tijdelijk naar disk zetten (swapping). Dit vertraagt het systeem als geheel enorm. FLEXSYT simulaties worden dus sneller uitgevoerd indien er voldoende geheugenruimte vrij is, zonder dat er met swapping wordt gewerkt. Ook hiervoor geldt dat tegelijk met een FLEXSYT simulatie beter tegelijk geen andere programma’s kunnen worden gedraaid. Dit geldt zelfs voor "kleine handige" programmaatjes zoals een screensaver. Naast swapping gebruiken de FLEXSYT programma’s zelf de harddisk ook intensief voor het opslaan en opvragen van gegevens. Een snelle toegang tot de harddisk bevordert dan de snelheid van de simulatie. In Windows95/98/ME/ 2000/NT is dit automatisch geregeld. Deze optimalisaties gelden uiteraard niet alleen voor FLEXSYT maar ook voor andere programma’s. 7.5.2 Optimalisatie binnen FLEXSYT

De belangrijkste maatregel voor optimalisatie binnen FLEXSYT is de hoeveelheid data beperken: hoe minder objecten er in de simulatie aanwezig zijn, hoe minder er hoeft te worden gerekend en des te sneller de simulatie wordt uitgevoerd. Een aantal eenvoudige maatregelen daartoe zijn: · studiegebied niet groter maken dan noodzakelijk; · voertuigen verlaten generatoren op een correcte manier, het is niet nodig om direct na een generator een loos segment te plaatsen om het afrijgedrag te modelleren (was in FLEXSYT-I- wel nodig); · segmenten aan het einde van het netwerk niet langer maken dan noodzakelijk, vrijwel altijd kunnen deze relatief kort zijn; · indien bepaalde typen voertuigen niet van belang zijn voor de simulatie deze achterwege laten (bijvoorbeeld langzaam verkeer); · als ongeregelde conflicten geen merkbare invloeden hebben op de resultaten deze achterwege laten; · beperking aantal segmenten; · beperking aantal attributen op segmenten. Zoals in figuur 8 is getoond, wordt bij elk attribuut een grens tussen netwerkelementen (raai) gelegd. Omdat de simulatie op basis van deze netwerkelementen wordt uitgevoerd zal er meer rekenwerk te doen zijn als er meer attributen zijn. Om dit enigszins te beperken en niet te kleine netwerkelementen te creëren neemt FLXNETW raaien die 2 [m] of minder uit elkaar liggen samen en combineert ze op een netwerkelement. In afbeelding 3 is dat het geval met de korte lus en de stopstreep bij het verkeerslicht; · toepassing internode segmenten. Internode segmenten hebben een eenvoudiger voertuigmodel door middel van een stop/go gedrag waarbij voertuigen vanuit stilstand instantaan op wenssnelheid kunnen rijden en omgekeerd direct kunnen stilstaan. Voor dit eenvoudigere model hoeft minder gerekend te worden dan het normale model waarbij voertuigen een acceleratie en deceleratie gedrag hebben. Buiten de directe invloedssfeer van kruispunten kunnen deze segmenten goed worden gebruikt om stroomopwaartse effecten op het verkeer correct te simuleren; · beperking aantal voertuigen in de simulatie. Het grootste deel van het rekenwerk bestaat uit het berekenen wat voertuigen doen/zullen gaan doen. Minder voertuigen betekent automatisch minder rekenwerk. Dit kan worden bereikt door de eerder genoemde punten: segmenten niet langer te maken dan nodig of niet opnemen in de simulatie; · beperking hoeveelheid te genereren informatie. Tijdens simulatie logt FLXSIMW deelresultaten in de files TRCFIL en TRFFIL. Bij grotere simulaties kan de omvang van deze files vele MegaBytes groot zijn. Niet meer


29

resultaten genereren dan nodig kan de simulatie aanzienlijk versnellen. Gegevens die de simulatiesnelheid bijzonder negatief beïnvloeden zijn de REGPAR equivalenten 2, 4 en 8 (actie- en reactie-events) en RESPAR equivalent 16 (milieugegevens).


30

8 FLASH 8.1 Inleiding

In het verleden is onder andere ten behoeve van FLEXSYT-I- het COCONpakket ontwikkeld. Dit pakket combineerde de invoerfiles en uitvoerfiles van andere programma's in de verkeersregeltechniek zoals KRAAN, REST, TRANSYT, de CCOL-regelaar, de RWS-C-regelaar, etc. COCON bevat een database en een gebruikersinterface welke de gebruiker van dit soort programma's ondersteund bij het maken van de invoer. Voor FLEXSYT-II- is een dergelijke ontwikkeling in gang gezet en dat heeft geresulteerd in het programma FLASH (FLEXSYT Application Shell). Zoals de naam al aangeeft is FLASH een programma, of schil, om FLEXSYT heen. De toevoeging van dit nieuwe grafische programma maakt FLEXSYT simulaties makkelijker in te voeren en, door middel van animatie, gedetailleerder te evalueren. FLASH maakt voor een belangrijk deel gebruik van bestaande FLEXSYT programma’s en heeft voor de simulatie speciale versies van FLXSIM, de CCOL-regelaar en de RWS C-regelaar. FLASH bestaat globaal uit de volgende onderdelen: · Een Management Tool die gebruikt wordt voor het beheersen van de veelvoud aan bestanden die worden gebruikt/aangemaakt bij het uitvoeren van een verkeerssimulatie. · Een Netwerk Editor die gebruikt wordt voor het ontwerpen en tekenen van verkeerskundige netwerken. · Een Workbench die gebruikt wordt voor het besturen van verkeerssimulaties. · Een Monitor die gebruikt wordt voor het visualiseren van verkeerssimulaties. FLASH draait onder Microsoft® Windows®, een grafisch besturingssysteem. Bediening van FLASH is geheel conform de specificaties zoals die voor dit besturingssysteem zijn vastgelegd.

8.2 Doel FLASH

Met de ontwikkeling van FLASH zijn een aantal uitbreidingen en verbeteringen gerealiseerd ten opzichte van voorgaande versies van FLEXSYT en de RWS Cregelaar. Hoewel het nut van deze versies algemeen erkend wordt, bestaan er enige barrières vanwege gebruiksonvriendelijkheid en beperkingen. FLASH is dan ook ontwikkeld om deze barrières weg te nemen en tegelijk de visuele presentatie te verbeteren. Dit is bereikt zoals blijkt uit een korte opsomming van nieuwe kenmerken van FLASH: ·


Bedieningsgemak Dankzij een geïntegreerde ontwikkelomgeving kunnen verschillende functionaliteiten op eenvoudige wijze worden gekozen en/of geactiveerd. FLASH is een applicatie die conformeert aan de bediening met menu's, knoppen, etc. zoals dat gebruikelijk is in Microsoft Windows; hierdoor is het programma herkenbaar. Tijdens simulatie worden de statussen van signaalgroepen en detectoren gevisualiseerd, zoals bij de oude FLXMON, FLXCOL (FLEXSYT-I-) en CRF, CRFMON (RWS C). Het deel van het netwerk dat op het beeldscherm zichtbaar is, kan worden ingesteld, daarnaast kan de grootte van de weergave via een zoomfunctie worden ingesteld.

31

·

·

·

·

Overzichtelijkheid Doordat FLASH het beheer van bestanden met gegevens die bij de simulatie horen voert, behoeven de namen van directories en bestanden niet te worden onthouden. Vanuit een projectmanagement-scherm kunnen bestanden worden aangewezen en bewerkt. De specificatie van een netwerk (infrastructuur) kan op een grafische wijze worden gedaan door het tekenen van stukjes wegvak en die aan elkaar te koppelen. Invoer van een netwerk gaat hierdoor niet alleen prettiger maar ook sneller dan vele regels codegetallen intikken, terwijl systematische fouten zoveel mogelijk worden voorkomen. Simulatie In één simulatie kunnen maximaal 999 regelaars, van het type CCOL, RWS C en/of FLEXCOL-76- worden gecombineerd. Hierdoor kunnen verkeerssituaties worden gesimuleerd waarbij effecten op één plaats in het netwerk (meestal een kruispunt) correct andere plaatsen beïnvloeden, zoals bij groene golven. Nieuwe visualisatie mogelijkheden maken het mogelijk om meer informatie zichtbaar te maken tijdens simulatie, zoals interne signaalgroep statussen en in de toekomst ook de voertuigen zelf. Nieuw verkeersbeheersingsobject Verkeerssignalering, kortweg MTM, met mogelijkheden om dynamisch snelheidsmaatregelen op te leggen of rijstroken af te kruisen. Debuggen Nauw verbonden aan FLASH zijn nieuwe versies ontwikkeld van bestaande programma's: MKDEBFLS (MaKe DEBugFiLeS) en het debugprogramma voor de RWS C-regelaar. Ook dit zijn nu Microsoft® Windows® programma's met een eenvoudige bediening en uitbreidingen die van de nieuwe mogelijkheden gebruik maken.

Met FLASH kan eenvoudiger en sneller een simulatie worden uitgevoerd. Deze simulatie kan meer aspecten uit de werkelijkheid nabootsen. Uitvoering van de simulatie kan beter worden gecontroleerd.

8.3 Relatie FLASH, FLEXSYT-II- en regelaars

De simulatie componenten FLXSIM (verkeerssimulator) en FLEXCOL-76regelaar van FLEXSYT-II- zijn ten opzichte van de voorgaande versies alleen veranderd door de uitbreiding met 'MTM-portalen'. De CCOL-regelaar en RWS C-regelaar hebben inhoudelijk enkele kleine uitbreidingen ondergaan om de nieuwe functionaliteiten te ondersteunen, de werkwijze volgens de Commissie C-interface is echter ongewijzigd. Bestanden met gegevens zoals die in FLEXSYT-II- en de CCOL/RWS C-regelaar aanwezig moesten zijn, zijn ook in FLASH nog nodig. FLASH maakt het beheer daarvan eenvoudiger. Dit wordt enerzijds gedaan door bij het projectmanagement alleen de relevante bestanden te tonen. Bestanden kunnen hierbij in verschillende subdirectories worden ondergebracht waarbij FLASH bijhoudt welke bestanden waar staan. Anderzijds worden afhankelijkheden bewaakt: als bijvoorbeeld het netwerk is veranderd, maar het voorloopprogramma FLXNET is daarna nog niet uitgevoerd, dan wordt op het moment dat een simulatie wordt gestart, een waarschuwing gegeven. De simulatieonderdelen zijn integraal opgenomen in FLASH als Microsoft Windows 'Dynamic Link Libraries' (DLL's). De overige programma's kunnen direct vanuit FLASH worden gestart. Dit geldt voor zowel de voorbewerkingsprogramma's (FLXMAN, FLXCON, FLXNET, C-compiler, FLXRWS/FLXCCOL en MKDEBFLS) als de nabewerkingsprogramma's (FLXRES, FLXREG, FLXDMP). Deze programma's kunnen eenvoudig worden gestart door


32

in het venster van projectmanagement op de bijbehorende knop te klikken. De samenhang van de programmafiles en hun functies in FLASH is weergegeven in figuur 9. ................................... Figuur 9:

*

ASCII editor

*

MANDAT CONDAT NETDAT

Bestandsindeling FLASH

FLASH.EXE INVOER BESTANDS ANIMATIE GEGEVENS BEHEER

*

FLXMANW FLXCONW FLXNETW

BASIS SPECIFICATIE

*

C-sources APPLICATIE

SIMDAT

FLXSIM.DLL MANFIL CONFIL NETFIL

RWSCREG.DLL

EVTDISP.DLL

C-compiler

FLXRGL.DLL

* FLXRESW FLXREGW FLXDMPW

BINAIRE RESULTATEN

*

ASCII RESULTATEN

ASCII editor gegevens programma’s resultaten

Centraal in de afbeelding staat het programma FLASH met diens functionaliteiten. De hoofdfunctionaliteiten die in dit programma zelf zitten zijn: · projectbeheer (bestandsbeheer); · grafische invoer netwerk (NETDAT); · invoer simulatiegegevens (SIMDAT); · visualisatie van de simulatie. Voor bewerking van ASCII-files wordt een externe ASCII-editor gebruikt. In het schema van figuur 9 zijn de files die met zo’n editor worden bewerkt aangegeven met een sterretje.

8.4 Regelaars

In FLASH is het mogelijk om in één simulatie meerdere CCOL/RWS C-regelaars te simuleren, eventueel te combineren met een FLEXCOL-regelaar. Om dit mogelijk te maken is een speciale structuur ontwikkeld. Deze wordt weergegeven in figuur 10. ................................... Figuur 10:

Opbouw FLASH

FLEXCOL-76-

RWS C

regelaar

regelaar

X

Y

Z RWS C

CCOL

debugger

regelaar

X

Y

Event Dispatcher

FLXSIM

WorkBench

verkeerssimulatie

Klok

Monitor

Bij start van een simulatie zorgt FLASH dat de benodigde onderdelen worden geladen. De Event Dispatcher zorgt voor de communicatie van de onderdelen. Deze modulaire opzet kent een aantal belangrijke voordelen:


33

·

·

·

·

De gebruikte onderdelen van FLEXSYT zijn (nagenoeg) ongewijzigd. Alleen FLXSIMW en de CCOL/RWS C-regelaar zijn gewijzigd. Het programma FLXSIMW is opgedeeld in de FLXCOL-regelaar (FLXRGL.DLL) en de verkeerssimulator (FLXSIM.DLL). Van een RWS C-regelaar wordt een DLL gecompileerd: RWSCREG.DLL, bij de CCOL-regelaar is dat de CCOLREG.DLL. Behalve dit zijn alle vier de onderdelen zodanig gewijzigd dat ze via de eventdispatcher kunnen communiceren met de andere onderdelen. Modelmatig is er geen enkele wijziging aangebracht; Voor communicatie tussen de onderdelen is een gestandariseerd protocol opgezet. In FLXSIMW en de CCOL/RWS C-regelaar worden signalen tussen het netwerk en de regelaar door middel van binaire codes uitgewisseld. Het nieuwe protocol gebruikt dezelfde identificatie als de gebruiker heeft ingevoerd: regelaarnummer, signaalgroepnummer en eventueel volgnummer. Dit maakt het mogelijk om eenvoudig andere onderdelen toe te voegen, bijvoorbeeld een ander type verkeerssimulator of ander type regelaar; Meerdere regelaars. De Windows-omgeving en de communicatie via de event dispatcher laten toe dat in één en dezelfde simulatie de FLXCOLregelaar en meerdere CCOL en/of RWS C-regelaars zijn geladen. Dit maakt het mogelijk dat het verkeer in een netwerk kruispunten wordt gesimuleerd. Bovendien is het ook mogelijk speciale versies van regelaars te simuleren. Zo zijn de in het verleden ontwikkelde RWS C-regelaar special (CRS) en de recent ontwikkelde RWS C-regelaar doseren (CRD) onder FLASH te draaien, eventueel in combinatie met andere regelaars.

8.5 ASCII-Editor

Invoer van netwerkgegevens (NETDAT) en simulatiegegevens (SIMDAT) wordt binnen FLASH gedaan. De overige invoergegevens moeten met een ASCIIeditor worden ingevoerd. Ook het inzien van de uitvoergegevens moeten worden gedaan met een ASCII-editor. Binnen FLASH kan elke gewenste editor daarvoor worden toegepast, dit kan zowel een Windows-programma als een DOS-programma zijn. Omdat een kolomsgewijze opmaak de files leesbaarder maakt is het belangrijk om bij een Windows-editor een textfont (lettertype) te kiezen dat niet schaalbaar is, wat wil zeggen dat alle karakters even breed zijn. Hierdoor blijft de kolomsgewijze opmaak gehandhaaft. Bij schaalbare lettertypen zijn karakters als "m", "w" en "0" breder dan "i", "t" en "1" waardoor per regel verschillen ontstaan.

8.6 Windows omgeving

FLASH zelf is een volwaardig Windows-programma, daardoor conformeert het zich aan algemene kenmerken van Windows-programma’s. Deze zijn terug te vinden in afbeelding 11, waar een "exploded view" is gegeven van het scherm waarmee het netwerk kan worden bewerkt. Hierin zijn terug te vinden: · Grafische weergave. "Een plaatje zegt meer dan duizend woorden" bevat ook in dit opzicht een kern van waardheid. Door toepassing van pictogrammen kan op een relatief klein oppervlak van het scherm iets duidelijk worden gemaakt. Bijvoorbeeld voor opslag van gegevens (een diskette) en afdrukken (een printer); · Gestandaardiseerde bediening De plaats van de menubalk waar de hoofkeuzes worden weergegeven, de indeling van hoofdkeuzes op de menubalk en zelfs subkeuzes daarvan zijn constant. Hierdoor kan sneller een


34

bepaalde functie worden teruggevonden. In onderstaande afbeelding is de menubalk van FLASH weergegeven. De twee keuzes links ("Bestand" en "Bewerken") en de meest rechtse keuze ("?" of "Help") staan bij elk goed Windows-programma op deze plaats. Ook andere aspecten zoals het veranderen van de grootte van objecten, kopiëren en verwijderen gebeurd op standaard manier. Doordat dit bij alle Windows-programma’s op dezelfde manier gebeurd, is het makkelijker om met nieuwe programma’s te gaan werken als deze werkwijze eenmaal is aangeleerd.

............... Figuur 11:

Interface FLASH


35


36

9 Andere aspecten .............................................................................................

9.1 Validatie

FLEXSYT-II- is al weer een aantal jaren (sinds 1994) voor gebruikers beschikbaar. Inmiddels is in een drietal studies onderzoek gedaan naar de validiteit van FLEXSYT-II-. De eerste studie is in juni 1995 gereedgekomen [2], [3]. Op basis daarvan zijn een aantal aanpassingen in het programma gerealiseerd. Met het verbeterde programma is nog eens naar de uitkomsten gekeken. Geanalyseerd zijn een viertal situaties: een enkel geregeld kruispunt, een minirotonde, een streng van drie geregelde kruispunten en een stukje snelweg. Voor de eerste drie situaties zijn de gesimuleerde en gemeten reistijden met elkaar vergeleken. Deze bleken goed overeen te komen [4], [5]. Voor de vierde situatie is de validatie vanwege tekortkomingen in de data in deze studie niet gelukt. Daarom is in 1998 een derde validatiestudie uitgevoerd, specifiek gericht op een stuk autosnelweg [6]. Uit deze studie bleek dat FLEXSYT het optreden van congestie niet goed inschatte. Er wordt nog onderzocht hoe dit verbeterd kan worden. Uit dit alles valt te leren dat valideren meer een proces is dan iets wat eenmalig gebeurt en daarna niet meer nodig is.

9.2 Foutmeldingen

Wanneer de programma's FLXNET, FLXSIM, FLXREG, FLXRES of FLXDMP iets te melden hebben aan de gebruiker worden de teksten hiervoor gehaald uit een meldingenbestand, resp. NETMSG, SIMMSG, REGMSG, RESMSG en DMPMSG. Per melding bevatten deze bestanden een foutmelding-classificatie-nummer, de aanduiding voor de ernst van de reden waarom de melding wordt gedaan, de aanduiding voor eventueel afdrukken van een parameter, de aanduiding voor eventueel afdrukken regelnummer in dataset waar de fout is vastgesteld en tenslotte de af te drukken tekst zelf. Met name FLXNET en FLXSIM voeren een uitgebreide controle uit op de consistentie van de NETDAT dataset en de samenhang van het netwerk met de regelingen. Onder FLASH is er nog een extra bestand (RGLMSG) met foutmeldingen voor de FLEXCOL-regelaar, omdat deze volledig onafhankelijk van de simulator draait.

9.3 Omgevingsvariabelen

Een aantal DOS instellingen zijn handig en soms nodig. Zo kan het DOS-pad uitgebreid worden met de directory waarin de executables van FLEXSYT-IIstaan. Op deze manier kunnen vanaf de DOS-prompt FLEXSYT-deelprogramma's gestart worden en is zelfs een bepaalde mate van batchverwerking mogelijk. Dat laatste echter alleen indien geen fouten optreden. Onder Windows zijn daar speciale programma’s voor die gratis via Internet verkregen kunnen worden.


37

Verder moet een DOS omgevingsvariabele gezet worden naar de directory waarin de files met boodschappen en foutmeldingen en de driverfile (FLEXSYT.DRV) staan. Indien bijvoorbeeld de executables in de directory C:\FLEXSYT2\SYS staan en de files met boodschappen en foutmeldingen in de directory C:\FLEXSYT2\MESSAGES dan moeten de volgende regels in de file AUTOEXEC.BAT worden opgenomen: PATH=C:\FLEXSYT2\SYS;%PATH% SET FLEXSYT=C:\FLEXSYT2\MESSAGES Onder Windows NT kan dat eenvoudiger via de systeeminstellingen in het configuratiescherm.


38

10 Ontwikkelingen .............................................................................................

10.1 Koppeling met industriële regelaars

Het lag in de lijn van de verwachting dat, in navolging van de ontwikkeling met FLEXSYT-I-, er koppelingen tot stand worden gebracht tussen FLEXSYT-II- en industriële regelaars. De firma Vialis (voorheen Nederland Haarlem BV) te Haarlem had deze koppeling tot stand gebracht, maar is inmiddels overgeschakeld op een ander model, namelijk VISSIM, waarvan zij in Nederland dealer zijn. Ook andere fabrikanten zijn bezig eigen simulatoren te ontwikkelen of te kopen. Helaas is er daarom nog geen koppeling met een industriële regelaar. De koppeling met de RWS C-regelaar en de CCOL-regelaar is dus wel gerealiseerd en wel onder het programma FLASH. Dit betekent dat FLEXSYT-IIeen willekeurige combinatie van RWS C-regelaars, CCOL-regelaars en één FLEXCOL-76- regelaar kan simuleren.

10.2 Visualisatie

Het blijkt dat veel mensen de visualisatie van gegevens zeer op prijs stellen. Voor FLEXSYT-II- zijn, in combinatie met FLASH, dan ook een aantal ontwikkelingen op dit punt in gang gezet. Zo is inmiddels het project om de visualisatie van voertuigen (in 2D) mogelijk te maken, afgerond. Gebruikers van het programma krijgen dan nog meer inzicht in de situatie, de problemen die optreden en het effect van mogelijke maatregelen. Een voorbeeld is te zien in figuur 12. Het is wel lastig om het netwerk zo te tekenen dat de visualisatie op een goede schaal getoond wordt. In FLASH zijn daar voorzieningen voor getroffen, zoals het kunnen inlezen van files met achtergrondtekeningen (bitmap, AutoCad, DrHalo) en het instellen van een vaste schaal. ................................... Figuur 12:

Voertuigvisualisatie in FLASH


39

Uiteraard is het alleen op een bepaald schaalniveau nuttig om afzonderlijke voertuigen te bekijken. Daarboven (verder uitgezoomd) zijn voertuigen bijna niet meer zichtbaar en kan worden volstaan met een andere manier van visualisatie, namelijk de segmentgegevens. Het is dan mogelijk om de intensiteit, de gemiddelde snelheid en de dichtheid van de segmenten dynamisch te zien. Ook deze uitbreiding is inmiddels ingebouwd. Tenslotte wordt nog gedacht aan een betere presentatie van de uitvoer. Hierbij kan gedacht worden aan een apart programma om de resultaten uit de RESFIL te tonen of het gedurende de simulatie tonen van detectorgegevens.


40

11 Beschikbaarheid en bruikbaarheid .............................................................................................

11.1 Beschikbaarheid

FLASH en FLEXSYT-II- kunnen bij de Adviesdienst Verkeer en Vervoer worden aangeschaft voor de prijs van € 2.250,-) voor elk afzonderlijk programma (dus € 4500,- in totaal). Daarvoor wordt een licentie-overeenkomst afgesloten. Ten behoeve van onderwijsdoelen is FLEXSYT-II- gratis beschikbaar. De AVV heeft met Goudappel Coffeng, adviseurs verkeer en vervoer, te Deventer een onderhoudsovereenkomst voor FLEXSYT-II- en met QQQ Delft een onderhoudsovereenkomst voor FLASH afgesloten, waarbinnen eventueel optredende problemen en geconstateerde fouten snel kunnen worden verholpen. Goudappel Coffeng is, in opdracht van AVV, de vervaardiger van het programma FLEXSYT-II-, terwijl FLASH ontwikkeld is door AND Identifaction en later Bell ID. Aan de ontwikkeling van FLASH en FLEXSYT-II- is en wordt veel zorg besteed. Echter, zoals gebruikelijk in geval van software, kan de AVV niet verantwoordelijk worden gesteld voor optredende fouten en mogelijke gebreken. Voorlopig worden verbeterde versies zonder kosten geleverd. Bezien zal worden of in de toekomst het beheer en onderhoud een andere vorm kunnen krijgen. Te denken valt hierbij aan het uitbesteden van het beheer en onderhoud door AVV aan een 'marktpartij' waarmee gebruikers dan tevens, ter dekking van de kosten, een onderhoudscontract kunnen afsluiten.

11.2 Bruikbaarheid

Sommigen van u zullen zich misschien nog afvragen wat u met het programma kunt (laten) doen of waarom u zo nodig het programma zou moeten toepassen. Het antwoord is dat FLEXSYT-II- richtinggevend kan zijn bij het onderzoeken van dilemma's in de verkeersbeheersing. FLEXSYT kan de motivatie van de investering van vele miljoenen guldens ondersteunen of juist niet. Daarbij hoort echter een goede raad: FLEXSYT vindt nooit vanzelf een goede oplossing. Mensen die met het programma werken, zullen dus ook in de praktijk goede vakmensen moeten zijn om met het programma om te kunnen gaan en om de uitkomsten goed te begrijpen.


41


42

12 Referenties .............................................................................................

[1]

[2] [3]

[4] [5]

[6]


Simulating Traffic and Traffic Control with FLEXSYT-II-, H. Taale and F. Middelham, Proceedings of the European Simulation Multiconference, Prague, June 1995. Validatie FLEXSYT-II-, Eindrapportage, DHV Milieu en Infrastructuur, in opdracht van de Adviesdienst Verkeer en Vervoer, juni 1995. FLEXSYT-II-, A Validated Microscopic Simulation Tool, H. Taale and F. Middelham, Proceedings of the 8th IFAC Symposium on Transportation Systems, Chania, Greece, June 1997. 2e Validatie FLEXSYT-II-, Eindrapportage, DHV Milieu en Infrastructuur, in opdracht van de Adviesdienst Verkeer en Vervoer, juli 1997. The Validation of a Microscopic Model for the Simulation of Traffic and Traffic Control, H. Taale and E.A.M. Scheerder, Proceedings of the 5th World Congress on Intelligent Transport Systems, Seoel, October 1998. Validatie FLEXSYT-II- voor autosnelwegen, Grontmij, in opdracht van de Adviesdienst Verkeer en Vervoer, december 1998.

43

FLEXSYT-II- November 2001

Recommend Documents