*
*
TNO-rapport
Inro-L&T/2001-019
Binnenvaartmodelsysteem
TNO Inro
Afdeling Logistiek en
Transport
Schoemakerstraat 97
Postbus 6041
2600 JA Delft
Eindrapportage 2e fase, versie 0.5
Telefoon 015 269 69 10
Fax
015 269 68 54
Contactpersoon
Hanno Uitenboogaart
Plaats en Datum
Delft, 1 maart 2001
Nummer
Alle rechten voorbehouden.
Niets uit deze uitgave mag worden
vermenigvuldigd en/oi openbaar gemaakt
door middel van druk, fotokopie, microfilm
of op welke andere wijze dan ook, zonder
voorafgaande toestemming van TNO.
01 3N 062 31151
Indien dit rapport in opdracht werd
uitgebracht, wordt voor de rechten en
verplichtingen van opdrachtgever en
opdrachtnemer verwezen naar de
'Algemene Voorwaarden voor Onderzoeksopdrachten aan TNO'. dan wel de
betreffende terzake tussen partijen
gesloten overeenkomst.
Het ter inzage geven van het TNO-rapport
aan direct belanghebbenden is toegestaan
ESRI Nederland
Auteur(s)
QQQ
TU Delft
NEA
TNO Inro
©2001 TNO
TNO Inro doet onderzoek en geeft adviezen op het gebied
van infrastructuur, transport en regionale ontwikkeling met
als doel versterking van de regionale concurrentiekracht.
T.H*
Nederlandse Organisatie voor toegepastnatuurwetenschappelijk onderzoek TNO
INHOUDSOPGAVE
pag1.
Verantwoording
1
2.
Achtergrond
4
3
Model
5
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
Rol van microsimulatie
Tijdschaal
Groeifactorenmodel
Iteraties in model
Modal shift
Leegvaartmodule
Welke gegevens zullen gebruikt worden voor de calibratie?
Voorrangsregels
5
5
6
6
6
7
7
7
4.
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
Data
Basisjaar
Categorisatie schepen (zie ook bijlage 1)
Koppelverbanden (zie ook bijlage 1)
BVMS-zones
Goederengroepen
Verwerkingstijd sluizen
Weergave openstellingstijden sluizen en bruggen
Flexibiliteit kostenstructuur schepen
Vlootomvang
Waterstanden
Oormerken gevaarlijke stoffen
Modellering van niet-ontgaste tankers
Oormerken containervervoer
8
8
8
9
10
10
11
11
11
11
12
12
12
13
5.
5.1
5.2
5.3
5.4
5.5
5.6
5.7
User interface
Gebruik van GIS software voorde user interface en de database
Aanpassen zone-indeling
Aanpassen goederengroepen-indeling
Aanpassen kunstwerken (sluizen, bruggen)
Beheer van basisjaar
Groepering van gegevens
Bouw van een case
14
14
14
15
15
15
15
17
6.
6.1
6.2
Rekenmodules
Programmeertaal
Simulatieframework
18
18
18
7.
7.1
7.2
7.3
Algemeen
Keuze database pakket
Welke koppelingen vanuit BVMS naar andere systemen zullen worden aangebracht?
Calibratie van het model: tijdschaal
19
19
19
19
Bijlagen:
Bijlage 1 Database (databehoefte en beschikbaarheid)
Bijlage 2 Modelspecificaties
Bijlage 3 User interface
Bijlage 4 Software specificaties en Test simulatie framework
Bijlage 5 Lexicon
01 3N 062 31151
1.
VERANTWOORDING
Door de Adviesdienst Verkeer en Vervoer van Rijkswaterstaat is aan een consortium onder leiding
van TNO Inro in juli 1999 de opdracht verleend tot het ontwikkelingen van een nieuw verkeersmodel
voor de binnenvaart (hierna genoemd BVMS). Dit project, dat een totale doorlooptijd heeft van circa
twee en een halfjaar en waaraan verder wordt meegewerkt door QQQ, NEA. ESRI en de TU Delft,
bestaat uit vier fasen. De eerste fase werd met een eindrapportage afgesloten op 9 maart 2000
Thans is de tweede fase aan de orde, die de periode maart 2000- februari 2001 beslaat.
Bijgaande eindrapportage doet verslag van deze fase, zijnde de ontwikkeling van versie 0.5 van het
model.
Deze rapportage bestaat uit een hoofdrapport, alsmede een aantal bijlagen (zie inhoudsopgave),
waarnaar daar waar relevant wordt verwezen.
Conform de offerte "Modelsysteem binnenvaart, fase 2" van 25 februari 2000, worden de volgende
deelproducten opgeleverd:
• Een verder ontwikkelde gebruikersinterface;
• Een nieuwe versie van de scenario- en evaluatiemodule;
• Een voor een deel gevulde database, aangepast aan de rekenmodules;
• Een werkend prototype van de rekenmodules;
• Een compleet werkend systeem, waarin bovengenoemde onderdelen zijn geïntegreerd.
In het nu volgende wordt kort ingegaan wat de precieze stand van zaken is met betrekking tot de
opgeleverde deelproducten en wordt een doorkijkje gegeven naar de directe vervolgactiviteiten. Per
onderdeel wordt waar mogelijk verwezen naar (één van de) bijlagen.
Verder ontwikkelde gebruikersinterface
De gebruikersinterface is verder ontwikkeld op basis van de door de AVV in gebruiksvoorbeelden
vastgelegde wensen met betrekking tot de manipulatie van invoer en uitvoervariabelen. Tot op heden
is het niet mogelijk geweest de gebruikersinterface te verfijnen op basis van gebruikservaringen. Wel
zijn aan de hand van de memo databeschikbaarheid (zie bijlage 1) alle invoermogelijkheden voor
gebruikers geïdentificeerd en in de user interface gerealiseerd.
Verfijningen van de al in fase 1 beschikbare functionaliteit had daarnaast met name betrekking op het
verwerken van de nieuwe inzichten met betrekking tot het netwerk en databeschikbaarheid. Het
karakter van de verdere ontwikkeling kent daarom conform de doelstelling van BVMS 0.5 met name
het karakter van een uitbreiding dan een verfijning. In de volgende fase (BVMS 0.9) komt de nadruk
te liggen op verfijning.
Verdere informatie is te vinden in: hoofdstuk 5 (beslispunten user interface), bijlage 3 (User
interface), en de BVMS 0.5-cd.
01 3N 062 31151
Een nieuwe versie van de scenario- en evaluatiemodule
De scenariobeheermodule is conform specificaties geïmplementeerd. Evaluatie over scenario's en
varianten heen is tevens mogelijk. De evaluatiemodule maakt mogelijk dat scenario's en varianten
onderling kunnen worden vergeleken. De aangeboden evaluatiemogelijkheden zijn gelijk aan de voor
een individueel scenario of variant aangeboden evaluatiemogelijkheden.
Verdere informatie is te vinden in: hoofdstuk 5 (beslispunten user interface), bijlage 3 (User
interface), en de BVMS 0.5-cd.
Een voor een deel gevulde database, aangepast aan de rekenmodules Het rekennetwerk vormt de
kapstok voor de BVMS-specifieke data. Het door de AVV aangeleverde ViN-netwerk bleek echter
onverwacht niet eenvoudig om te zetten naar een netwerk dat gebruikt kon worden in het BVMS.
Daarnaast bleek de voor het BVMS benodigde netwerkgerelateerde data welke uit het ViN en IVS
werden betrokken moeilijk toegankelijk was en was er onvoldoende vertrouwen in de
betrouwbaarheid van deze data. Vanuit de AVV wordt inmiddels hard gewerkt om deze bezwaren uit
de weg te ruimen. De oplevering van het gecorrigeerde netwerk komt voor deze fase echter te laat om
te gebruiken als kapstok voor de door de rekenmodules benodigde data. Bovenstaande heeft er toe
geleid dat in de gebruikersinterface het ViN-netwerk en de daaraan gekoppelde data wel benaderd
kunnen worden, maar dat vanuit de rekenmodules niets met de gegevens uit ViN wordt gedaan.
Hiervoor wordt gebruik gemaakt van een schaduwdatabase.
Verdere informatie is te vinden in: hoofdstuk 4 (Beslispunten data), bijlage 1
(Databeschikbaarheid), en de BVMS 0.5-cd.
Een werkend prototype van de rekenmodules
De rekenmodules zijn geïmplementeerd in MATLAB, een taal waarin de modelbouwers maximale
flexibiliteit hebben om hun modellen naar voortschrijdend inzicht fijn te slijpen. In MATLAB
geïmplementeerde modellen hebben echter het nadeel dat zij zich moeilijk laten aansturen door
externe applicaties, waaronder de BVMS gebruikersinterface. Dit probleem is opgelost door het
MATLAB model technisch zo te omkapselen dat deze vanuit de gebruikersinterface eenvoudig
aangestuurd kan worden. Hierdoor behouden de modelbouwers zo lang mogelijk de flexibiliteit om de
modellen naar voortschrijdend inzicht aan te passen, waardoor zij waar nodig bepaalde
modelleringkeuzen tot later uit kunnen stellen.
Voor het simulatie-deelmodel wordt van deze werkwijze afgeweken omdat dit model aanzienlijke
eisen stelt aan de reken- en geheugencapaciteit. Om performanceredenen is er daarom voor gekozen
om dit model direct te implementeren in de taal waarin uiteindelijk alle rekenmodellen
geïmplementeerd zullen worden.
Verdere informatie is te vinden in: hoofdstuk 3 Beslispunten model), hoofdstuk 6 (Beslispunten
rekenmodules), bijlage 2 (Model specificatie), bijlage 4 (Software specificatie) en de BVMS 0.5cd.
01 3N 062 31151
Een compleet werkend systeem, waarin bovengenoemde onderdelen zijn geïntegreerd (zie de
BVMS 0.5-cd)
Technische integratie van de boven genoemde onderdelen heeft plaatsgevonden. Het ViN-netwerk, de
rekenmodules, de scenario- en evaluatiemodule zijn allemaal vanuit één systeem benaderbaar, maar
functioneren nu nog ten dele los van elkaar. In deze fase is bereikt dat de verschillende onderdelen
samenhangen. De volgende fase heeft tot doel de samenhangende onderdelen ook samen te laten
werken.
Verdere informatie is te vinden op de BVMS 0.5-cd.
Testen
Alle bovengenoemde onderdelen zijn door middel van "peer-review" getest. De producten van de TUDelft zijn voor wat betreft de gekozen modellering getest door TNO. De technische
implementeerbaarheid van de deelmodellen is beoordeeld door QQQ Delft.
De door QQQ Delft uitgevoerde omkapseling van de rekenmodellen is getest door ESRI als onderdeel
van de integratie in Arclnfo. Voor het door QQQ Delft geïmplementeerde simulatieraamwerk geldt
dat deze pas in de volgende fase uitvoerig getest kan worden, wanneer het raamwerk ook
daadwerkelijk door de TU voor de modellering wordt ingezet. In dit stadium is met behulp van een
klein testnetwerk getest of het simulatieraamwerk aan een aantal basiseisen voldoet. De resultaten van
deze test zijn vastgelegd in een document dat als één van de resultaten wordt opgeleverd (zie bijlage
4, deel 4 (voorbeeld simulatie)).
De door AVV opgeleverde bronbestanden, zoals het ViN en het IVS, zijn door NEA, TNO, ESRI en
de TU Delft getest op bruikbaarheid voor het BVMS. Gebleken is dat deze bronbestanden niet
rechtstreeks bruikbaar zijn voor het BVMS. Als gevolg hiervan is de AVV hard aan het werk om deze
bronbestanden op te schonen.
Bij de test van de gebruikersinterface is getest of de handelingen zoals onderscheiden in de door AVV
geleverde gebruiksvoorbeelden worden ondersteund. De gebruiksvoorbeelden betreffen concrete
scenario's van handelingen. Aangezien de verschillende delen van de gebruikersinterface op dit
moment samenhangen maar nog niet samenwerken, is het niet mogelijk gebleken de in de scenario's
geïmpliceerde samenwerking tussen de verschillende delen van de gebruikersinterface te testen.
Verdere informatie is te vinden in: bijlage 4, deel 4 (Voorbeeld simulatie) en de BVMS 0.5-cd.
01 3N 062 31151
2.
ACHTERGROND
Bijgaande rapportage, die een weerslag vormt van de werkzaamheden die in het kader van de 2e fase
(versie 0.5) van de ontwikkeling van het BVMS zijn verricht, vindt zijn basis in een naar aanleiding
van de BVMS Klankbordgroepvergadering van 6 juli 2000 opgesteld beslispuntenmemo. Op basis
van dit memo, dat alle aan de ontwikkeling van het BVMS 1.0 gerelateerde keuzes bevat, zijn de
afgelopen maanden de nodige besluiten genomen. De besluiten zijn geordend naar de verschillende
onderdelen van het systeem, te weten naar model, user interface, data, rekenmodules en algemeen..
De genomen besluiten zijn in deze rapportage integraal overgenomen, omdat zij in sterke mate de
richting bepalen waarin het model zich ontwikkelt. Als opgemerkt bevat dit rapport alle besluiten, die
in het kader van de ontwikkeling van het BVMS moeten worden genomen. Dat betekent dat bepaalde
te nemen besluiten met betrekking tot de derde of vierde fase wel zijn opgenomen, maar hun effect
pas later zullen hebben.
De basisinformatie uit deze rapportage is door de Klankbordgroep BVMS in haar vergadering van 30
november 2000 besproken, van commentaar voorzien en na overleg met de projectleider van AVV
verwerkt.
01 3N 062 31151
3
MODEL
Het eindproduct van het gehele BVMS-project is het tot stand brengen van een nieuw verkeersmodel
voor de binnenvaart, waarbij het verkeersmodel een vertaling moet geven van goederenstromen in
tonnen, gemeten tussen de verschillende gebieden naar scheepsbewegingen in aantal en
onderscheiden naar grootte op de verschillende schakels van het binnenvaart-infrastructuumetwerk.
Het BVMS is derhalve bedoeld voor het beantwoorden van vragen op macroniveau binnen de
binnenvaartsector. Voorbeelden hiervan zijn:
•
Wat zijn de kosten en baten van een grotere sluis?
•
Wat zijn de gevolgen van het afsluiten van bijv. het Amsterdam - Rijnkanaal voor gevaarlijke
goederen?
•
•
•
Wat zijn de trends (aard en omvang) in vervoer over de Dssel?
Wat zijn de gevolgen van een verdubbeling van de brandstofprijs op het traject RotterdamDuisburg?
Uitgaande van een nieuwe prognose: waar en wanneer treden knelpunten op?
•
Wat zijn de effecten voor de binnenvaart op het Knooppunt Arnhem-Nijmegen (KAN)?
Het BVMS is dus niet bedoeld voor:
•
sectoroverschrijdende analyses; daarvoor zijn modellen als TEM en SMILE beter geschikt
•
detailanalyses van schakels (sluizen, bruggen); daarvoor is een model als SFVAK beter geschikt.
3.1
Rol van microsimulatie
Het is een uitdrukkelijke eis van AVV om binnen BVMS gebruik te maken van simulatietechnieken.
In maart van 2000 is uitvoerig van gedachten gewisseld over de voors en tegens van micro-simulatie.
Op grond hiervan is gekozen voor een aanpak waarin simulatie gebruikt zal worden voor de
toedelingsmodule. Waar mogelijk zal gebruik worden gemaakt van de specificatie van het
sluissimulatiemodel SIVAK. Het is echter niet de bedoeling om SIVAK te vervangen. Het BVMS
beoogt immers vragen op macroniveau te beantwoorden en niet vragen betreffende het gedetailleerde
functioneren van een individuele sluis (wel voor het signaleren van problemen van individuele sluis
aan de hand van bijvoorbeeld gemiddelde passeertijd).
Besluit: Gebruik simulatie voor het toedelingsmodel.
3.2
Tijdschaal
Er moet een keuze worden gemaakt voor welke periode een model moet worden doorgerekend.
Hierbij is de wens van AVV geuit om verschillende perioden in het jaar te kunnen analyseren, waarbij
bijvoorbeeld aan seizoenen kan worden gedacht. Daarbij kunnen dan ook een over het jaar variërende
stroomsnelheid en vaarwegdiepte worden meegenomen. Voor de microsimulatie moet ook een
representatieve periode worden gekozen waarvoor een simulatie wordt gedraaid (dag / week / maand).
Relevante aspecten bij de beslissing welke tijdschaal moet worden gekozen zijn:
01 3N 062 31151
•
de behoefte van AVV aan het detailniveau van de output: wil men alleen een gemiddelde dag
kunnen analyseren, een gemiddelde dag in een gegeven seizoen, een piekdag in het jaar, etc;
•
de betrouwbaarheid waarmee data kunnen worden verzameld. Op jaarniveau zijn er kwalitatief
goede data voorhanden, maar de betrouwbaarheid wordt minder naarmate de mate van detail
groter wordt;
• de data-handling niet teveel rekentijd vereist.
Besluit: calibratie op twee seizoenen (seizoen met en zonder recreatievaart). De gebruiker kan
de goederenstromen met een percentage, te specificeren per goederengroep en H/B relatie,
ophogen om zo een piekperiode in een gegeven seizoen door te kunnen rekenen (bijv. een
seizoen die qua omvang van de goederenstromen 25% boven het gemiddelde ligt). Het
simuleren van een representatieve dag (eventueel opgehoogd met het door de gebruiker
opgegeven percentage) vindt basis op een vertrektijdstipverdeling per scheepsklasse (niet per
scheepstype). Deze vertrektijdstipverdeling is onafhankelijk van seizoen en vertreklocatie.
3.3
Groeifactorenmodel
De groeifactorenmodule bepaalt de ontwikkeling van de verkeersvraag door de voorspelde vraag van
het basisjaar te vergelijken met de voorspelde vraag in het toekomstjaar. Teneinde eventuele
onvolkomenheden in de modellering glad te strijken wordt deze ontwikkeling toegepast op de in het
basisjaar gemeten mobiliteit, zoals neergelegd in de basismatrix.
In het prototype is voor een pragmatische invulling van de groeifactorenmodule gekozen, waarbij,
wanneer de stroom in het basisjaar bestaat, bij een voldoende grote groei een groeifactor gekozen
wordt, en anders een absolute groei wordt ingebracht. Indien nodig zal de groeifactorenmodule in het
verdere verloop van het project worden aangepast.
Besluit: Aanpassing van de groeifactorenmodule behoort tot fase 3 van het project.
3.4
Iteraties in model
De keuze van de modeliteraties is nog onderwerp van onderzoek.
Besluit: Behoort tot fase 3 van het project en maakt onderdeel uit van calibratie. Zie tevens
onder punt 3.7.
3.5
Modal shift
Het is de vraag in hoeverre BVMS een indicatie moet geven voor het effect van de kosten van de
binnenvaart op de modal split. In principe is BVMS hiervoor niet bedoeld en is er al een alternatief
beschikbaar in de vorm van SMILE. Het is daarom de vraag of het de moeite waard is om te
investeren in een modal split module, waarbij weer een terugkoppeling naar de goederenstromen
plaatsvindt. Het kan echter wel handig zijn om een indicator te krijgen voor de validiteit van de
resultaten van BVMS in de vorm van een schatting van de modal shift (d.w.z. de verschuiving in het
aandeel van de binnenvaart in het binnenlands vervoer), veronderstellend dat er geen
kostenwijzigingen in de andere modaliteiten optreden. Een simpele faciliteit hiervoor is in te bouwen.
01 3N 062 31151
De functie hiervan is om te kunnen beoordelen of het nuttig is om een modal split analyse te maken
met daartoe geëigende tools als SMILE.
Besluit: BVMS geeft een ruwe indicatie voor de modal shift als gevolg van wijzigingen in de
kosten van de binnenvaart in het prognosejaar op basis van extern gegeven elasticiteiten, zonder
terugkoppeling op de invoer aan goederenstromen.
3.6
Leegvaartmodule
Hiernaar is onderzoek verricht door Mark Bovenkerk tijdens zijn afstudeerstage. Hij heeft vijf
benaderingen met elkaar vergeleken. Een definitief besluit zal eerst in de 3e fase van het project
behoeven te worden genomen.
Besluit: Eerst in de 3e fase van het project opportuun.
3.7
Welke gegevens zullen gebruikt worden voor de calibratie?
Op het ogenblik wordt onderzocht welke gegevens beschikbaar zijn. Hierbij wordt met name gekeken
naar gegevens uit IVS. Er kan momenteel nog geen uitsluitsel worden gegeven. Aangezien calibratie
in deze fase nog niet aan de orde is, is het antwoord op deze vraag niet urgent. Aan het einde van Fase
2 zal meer over de werking van het model bekend zijn, en dus ook welke parameters gecalibreerd
moeten worden. De vraag welke procedure gehanteerd wordt bij calibratie komt aan de orde bij de
ontwikkeling van de calibratietools (Fase 3). Omdat het simulatiemodel zal worden gespecificeerd
aan de hand van SIVAK, is het mogelijk dat sommige parameters uit SIVAK kunnen worden
overgenomen.
Besluit: De ontwikkeling van calibratietools behoort tot fase 3. In de Lexicon (bijlage 5) zal
worden aangegeven wat in dit verband onder calibratie wordt verstaan
3.8
Voorrangsregels
Tijdens de cases van oktober 1999 is geopperd om voorrangsregels bij sluizen en bruggen op te
nemen, bijvoorbeeld beroepsvaart gaat voor recreatievaart en gevaarlijke lading heeft hoogste
prioriteit ('nice to have'). Gegeven de beperkte prioriteit die hieraan is gegeven, de relevantie voor
macrobeslissingen waarvoor BVMS vooral bedoeld is en de additionele complicaties voor het model
is gekozen om dit aspect buiten het BVMS te laten. De consequenties op macroniveau kunnen hoe
dan ook niet worden meegenomen in de modelberekeningen.
Besluit: Voorrangsregels bij sluizen en bruggen worden niet in BVMS opgenomen.
Verondersteld wordt dat alle afhandeling verloopt via het 'First Come, First Served' principe.
01 3N 062 31151
4.
DATA
4.1
Basisjaar
De keuzemogelijkheden zijn ruwweg:
• gebruik het bestaande basisjaar 1992;
• maak een nieuw basisjaar (zo recent mogelijk) en gebruik dit als basis voor het BVMS;
• gebruik een tussenoplossing, d.w.z. maak een 'synthetisch basisjaar' 1997, waarbij de bestaande
gegevens zo goed en zo kwaad als het kan 'houtje-touwtje' tot een dataset wordt aangevuld dat
gelijkenis met een basisjaar vertoont.
Een geheel nieuw basisjaar lijkt het beste, maar daarvoor bestaat binnen het voor de ontwikkeling van
het BVMS beschikbare budget geen ruimte, ook niet als alleen een beperkt basisjaar voor de
binnenvaart wordt geconstrueerd. Bovendien kost het tijd om een nieuw basisjaar te maken, en dat
belemmert de voortgang van de ontwikkeling van BVMS. Nadeel van het bestaande basisjaar 1992 is
echter dat de gegevens eigenlijk zijn verouderd. Belangrijke wijzigingen die sindsdien hebben
plaatsgevonden zijn onder meer de toename van de containerbinnenvaart en de afschaffing van de
beurs. Een tussenoplossing lijkt aantrekkelijk, maar heeft risico's met betrekking tot de
betrouwbaarheid van de data. Aan AVV is daarom gevraagd om een besluit hierover te nemen, en dit
heeft geresulteerd in een keuze voor het bestaande basisjaar 1992 (zie verslag afstemmingsoverleg
TNO-AVV d.d. 8 mei 2000). Wel moet de structuur van BVMS toelaten dat er in een later stadium er
nieuwe gegevens kunnen worden ingevoerd. Als door AVV besloten wordt om een nieuw basisjaar te
construeren, kan bekeken worden hoe dit in de ontwikkeling van BVMS kan worden ingepast en
welke consequenties dit heeft voor de doorlooptijd en het benodigde budget.
Besluit: Gebruik het bestaande basisjaar 1992
4.2
Categorisatie schepen (zie ook bijlage 1)
Binnen het BVMS wordt gebruik gemaakt van scheepstypen en scheep skiassen. Gezamenlijk bepalen
deze alle eigenschappen van de schepen welke binnen het BVMS beschikbaar zijn. Daarbij wordt de
scheepsklasse gebruikt om de voor de afwikkeling relevante eigenschappen van een schip vast te
leggen, terwijl het scheepstype wordt gebruikt om de geschiktheid van een schip aan te geven voor
verschillende typen lading.
De belangrijkste reden om gebruik te maken van scheepstypen en -klassen in BVMS is het traceren
van deze scheepstypen en -klassen en de daaraan gerelateerde goederenstromen in de output. Per
scheepstype kunnen ook andere kostenparameters, vermogen, diepgang gespecificeerd worden. Een
keuze voor onnodig veel scheepstypen en -klassen leidt tot onnodig lange rekentijden (omdat het
model wel een keus uit de beschikbare typen en klassen moet maken), hetgeen de
gebruikersvriendelijkheid niet ten goede komt.
01 3N 06231151
Een voor de hand liggende indeling voor de scheepsklassen is de CEMT-classificatie. Uit analyses
van NEA blijkt dat er de nodige spreiding qua lengte en breedte van de schepen aanwezig is binnen
dezelfde CEMT-klasse. De breedte van schepen is met name van belang bij de vraag of een schip een
sluis of brug wel kan passeren.
Besluit: Voorgesteld wordt daarom om vier scheepstypen te hanteren: motorvrachtschepen,
motortankschepen, en containerschepen. Voorgesteld wordt om de CEMT-classificatie te
vervangen door een op de CEMT-classificatie geënte classificatie op basis van
vaareigenschappen. Daarbij is het van belang om het aantal klassen niet te hoog te laten
oplopen om lange rekentijden en schijnnauwkeurigheid van de resultaten te vermijden. CEMT
kent namelijk slechts 7 klassen. Voorgesteld wordt om gebruik te maken van een beperkt aantal
breedteklassen en om per scheepstype en breedteklasse een paar lengteklassen te definiëren,
zodat het totaal aantal combinaties van scheepslengte en breedte per scheepstype maximaal 15
is. Verder worden de volgende uitgangspunten gehanteerd:
•
De inzinkingsformule gaat terug naar tabel scheepstype-per klasse. Het veld max_volume is
opgenomen in de tabel scheepsklasse.
•
Miniengte en Minbreedte worden gehandhaafd omdat deze voor het opstellen van de keuze
alternatieven meer relevant zijn dan Maxlengte en Maxbreedte. Maxlengte en Maxbreedte
worden toegevoegd.
•
De scheepsklasse wordt gebruikt om de voor de afwikkeling relevante eigenschappen van
een schip vast te leggen. Combinaties met duwbakken worden daarom als een scheepsklasse
beschouwd.
•
Voor duwbakken die in brede of lange formatie varen welke op grond van hun afmetingen
niet in een bestaande klasse kunnen worden ingedeeld, worden aparte klassen
onderscheiden.
4.3
Koppelverbanden (zie ook bijlage 1)
Behalve de soorten schepen als genoemd onder het vorige punt bestaan er ook koppelverbanden. In
BVMS kan dit worden ingebracht door deze koppelverbanden als een apart scheepstype te zien
(oplossing via data) of om de samenstelling van koppelverbanden als een element in het model onder
te brengen. Indien er geen apart scheepstype voor koppelverbanden wordt vastgelegd dient
overwogen te worden een aparte klasse te definiëren binnen één van de bestaande typen.
Besluit: Koppelverbanden en duwstellen worden niet als apart scheepstype beschouwd.
Koppelverbanden en duwstellen worden net als "enkelvoudige" schepen op basis van lengte en
breedte in klassen ingedeeld.
01 3N 062 31151
4.4
10
BVMS-zones
Een BVMS-zone is een geografisch gebied dat gebruikt wordt als aggregatie van nabijgelegen
laad/losplaatsen. Binnen elke zone is één BVMS laad-losplaats aangewezen. Alle goederenstromen
lopen vanaf en naar deze BVMS laad-losplaats. De zonering is een verfijning van de TEM-zonering.
De BVMS-zones worden geconstrueerd, uitgaande van de zonering in het huidige BVMS. Ten eerste
zullen er een aantal zones in het buitenland (ongeveer 10) worden toegevoegd. Daarnaast zullen een
aantal zones uit het oude BVMS worden opgesplitst, daar waar er behoefte bestaat aan een meer
gedetailleerde weergave van de goederenstromen (Rotterdam is een goed voorbeeld). De mate waarin
zones kunnen worden gesplitst hangt samen met de beschikbaarheid van betrouwbare gegevens.
Besluit: Representatieve laad- en lospaatsen in overleg met AVV vastgesteld. Geldt eveneens
voor een beperkt aantal buitenlandse laad-en losplaatsen.
4.5
Goederengroepen
Een indeling in goederengroepen moet een onderscheid maken dat nodig is voor de output en mag
niet te fijnmazig zijn om de rekentijd binnen de perken te houden. In de oude versie van BVMS wordt
in de berekeningen gewerkt met een indeling in 27 goederengroepen, een aggregatie van de 52 NSTR2 groepen. Voor de output vindt weer een aggregatieslag naar 10 goederengroepen plaats.
Voor de nieuwe versie van BVMS is gedacht aan zowel NSTR-2 als NSTR-4, met name in relatie tot
het oormerken van gevaarlijke stoffen. Met betrekking tot dit laatste zijn twee alternatieven
voorhanden:
• Het gebruik van de NSTR4 indeling voor goederensoorten;
•
Het gebruik van de NSTR2 indeling voor goederensoorten in combinatie met kegelklassen
(0,l,2,of 3 kegels).
De keuze is uiteindelijk komen te vallen op alternatief twee en wel om drie redenen:
•
Het is lastig om modelmatig te kunnen bepalen of bepaalde combinaties van goederen als
gevaarlijk moeten worden aangeduid. De kegelaanduiding is een veel betrouwbaarder aanduiding.
•
•
De NSTR4 aanduiding is vaak onbetrouwbaar.
De combinatie van NSTR2 en kegelaanduiding wordt ook als zodanig gebruikt binnen het IVS.
De basis voor de indeling in goederengroepen is dus de NSTR-2 indeling. AVV heeft echter te
kennen gegeven dat de huidige indeling in 27 goederengroepen (aggregatie van NSTR-2) aan de
wensen voldoet, als men al deze 27 groepen maar wel in de output terug kan zien.
Besluit: Gebruik de 27 goederengroepen zoals die ook in de oude versie in gebruik zijn.
01 3N 062 31151
4.6
\\
Verwerkingstijd sluizen.
De afhandelingstijd van schepen bij sluizen is opgesplitst in manoeuvreertijd, nivelleertijd en tijd voor
het openen en sluiten van de deuren. Deze tijden kunnen per kolk gespecificeerd worden,
onafhankelijk van de waterstanden. Effect van waterstand op de nivelleertijd is niet voorzien, omdat
(1) de tijdschaal van getijden veel kleiner is dan van de simulatieperioden (2) dit effect slechts voor
een beperkt aantal locaties in het vaarwegennet relevant is.
Besluit: Verwerkingstijd per kolk specificeren als som van manoeuvreertijd, nivelleertijd en tijd
voor het openen en sluiten van de deuren, onafhankelijk van de waterstanden.
4.7
Weergave openstellingstijden sluizen en bruggen
Tijdens de cases van oktober 1999 zijn twee opties naar voren gekomen voor het vastleggen van de
openstellingsregimes:
•
aantal uren per dag of per week;
• tijdvenster (bijv. van 6.00 - 19.00 en niet in het weekeinde).
Vanwege de simulatie-aanpak kan gekozen worden voor de tweede optie, namelijk een reeks
tijdvensters die de openstelling op een dag weergeven. Openstellingregimes kunnen verschillen per
dagtype (werkdag, zaterdag, zondag) en per seizoen.
Besluit: Openstelling schakels (kolken, bruggen en , indien nodig, vaarwegsegmenten) aangeven
via bedieningsregimes, waarbij een bedieningsregime een reeks tijdsintervallen is waarin de
schakel open is.
4.8
Flexibiliteit kostenstructuur schepen
Tijdens de cases van oktober 1999 zijn twee belangrijke invloedsfactoren voor de kostenstructuur van
scheepstypen naar voren gekomen:
•
kostenstructuur afhankelijk van scheepstype en -klasse;
• kostenstructuur afhankelijk van de lig- wacht- en vaartijd.
Beide elementen zitten in de kostenstructuur van BVMS, zie Tabel 2.5. (Scheepsdata) in Bijlage 1
Besluit: De kostenstructuur bestaat voor klasse en type uit een basistarief per vaart plus de
volgende kosten per uur: personeel, varen vol, varen leeg, wachten en stilliggen. Tot de derde
fase van dit project behoort het vaststellen van de wijze waarop de gebruiker van het model met
kosten in het model kan omgaan. De gebruiker wenst wellicht "onafhankelijke" parameters als
brandstofprijs in te voeren. De vertaalslag van deze "onafhankelijke" parameters naar de
afgeleide kosten, zoals hierboven geschetst, wordt dan door het model uitgevoerd.
4.9
Vlootomvang
Door de aanwezigheid van buitenlandse schepen in Nederland en van Nederlandse schepen in het
buitenland is de beschikbare vloot enigszins 'rekbaar'. Een prognose voor de vlootomvang in het
prognosejaar lijkt geen haalbare kaart. Dit is oplosbaar door de gebruiker zelf de vlootomvang in het
01 3N 062 31151
12
prognosejaar te laten specificeren, afgeleid van de huidige vlootomvang. Qua model kan de
vlootomvang wel als randvoorwaarde in het model opgenomen worden. In het model zal bij een
limietoverschrijding per scheepsklasse de overgebleven lading naar rato van aantrekkelijkheid over de
nog beschikbare scheepsklassen verdeeld worden.
Besluit: Verzamel data voor de aantallen schepen per klasse en type in het basisjaar, maar laat
de gebruiker wel de aantallen schepen in het prognosejaar bepalen. Het model biedt de
functionaliteit om met eindige vlootomvang om te gaan.
4.10
Waterstanden
De waterstand is een relevante variabele om te bepalen welke schepen welke route kunnen afleggen.
De waterstand zal vanzelfsprekend variëren in het jaar, en deze variaties moeten in het model worden
opgenomen. Het is nuttig om zowel variaties tussen seizoenen als binnen seizoenen te modelleren,
waarbij er voor moet worden opgepast dat er niet een dusdanig detailniveau wordt gekozen dat het
model niet meer goed te calibreren is. Op het moment lijkt het de beste keuze om per seizoen drie
waterstanden voor elk vaarwegsegment te definiëren: een lage, midden en hoge waterstand. Voor de
hoge waterstand kan als richtlijn worden gehanteerd dat de aflaaddiepte geen beperking vormt. Voor
deze drie waterstanden kan een frequentieverdeling per seizoen, voor het hele netwerk worden
gespecificeerd. Het simulatiedeel van BVMS zal op basis van deze frequentieverdeling rekenen. Door
deze modellering worden ook variaties binnen een seizoen meegenomen, terwijl afhankelijkheden in
waterstanden tussen vaarwegsegmenten automatisch worden meegenomen.
Besluit: De waterstand wordt voor elke schakel en per seizoen aangegeven als een hoge, midden
en lage waterstand. Voor heel Nederland (en dus niet per vaarwegsegment) dient per seizoen
een frequentieverdeling over deze drie klassen als input te worden gegeven.
De waterstanden zullen in het vaarwegennetwerk worden gedefinieerd ten opzichte van NAP.
Hoogten van bruggen (geopend en gesloten) en overige kunstwerken zullen ook ten opzichte van
NAP worden gegeven. Een doorvaarthoogte van een brug kan dan worden bepaald uit het
verschil tussen waterstand en hoogte van de brug.
4.11
Oormerken gevaarlijke stoffen
In de uitvoer moet geselecteerd kunnen worden op gevaarlijke stoffen. Daartoe wordt in de invoer per
goederengroep aangegeven welk percentage van de goederengroep geen kegels heeft en welk
percentage 1, 2 of 3 kegels heeft.
Besluit: Aangeven procentuele verdeling van het aantal kegels per goederengroep.
4.12
Modellering van niet-ontgaste tankers
Niet-ontgaste tankers vormen feitelijk leegvaart die als het vervoer van gevaarlijke stoffen moet
worden gezien. Omdat de omvang van deze vervoersstroom ongeveer even groot is als het vervoer
van gevaarlijke stoffen zelf, kan deze vervoersstroom niet verwaarloosd worden.
01 3N 062 31151
13
Besluit: niet ontgaste tankers verdienen expliciet te worden opgenomen in het BVMS. Mee te
nemen als miniem beladen schepen met een gevaarlijke lading.
4.13
Oormerken containervervoer.
In de uitvoer moet geselecteerd kunnen worden op containervervoer. Daartoe wordt in de invoer per
goederengroep en per H-B relatie aangegeven welk percentage van de goederengroep
gecontaineriseerd wordt vervoerd. Door een gemiddelde beladingsgraad van containers per
goederengroep aan te geven (tonnen) kan in de impactmodule het aantal vervoerde containers (TEU)
worden afgeleid.
Besluit: Aangeven percentage gecontaineriseerd vervoer per goederengroep en per H-B relatie
en afleiden aantal containers (TEU) uit de gemiddelde belading in de impactmodule.
Opmerking:
Ten aanzien van de data zijn meer keuzes op detailniveau gemaakt. Voor een gedetailleerd overzicht
van datastructuur en databronnen met lopende onderzoeksvragen wordt verwezen naar Bijlage 1.
01 3N 062 31151
5.
14
USER INTERFACE
Betreffende de user-interface is een inventarisatie gemaakt van de wensen die er bij AVV leven door
middel van een aantal cases (najaar 1999). Deze cases hebben geleid tot een checklist voor de user
interface. Merk op dat aan het case-beheer extra aandacht is besteed, zie Bijlage 3. Verder is in
Bijlage 1 aangegeven welk veld in de database door de gebruiker te wijzigen moet zijn (input-deel
van de user-interface).
Bijgevoegd is tevens een rapportage van ESRI Nederland inzake de user interface (zie bijlage 3).
5.1
Gebruik van GIS software voor de user interface en de database
De belangrijkste keuze die in fase 1 gemaakt is, is om van de GIS-softwarepakketten Arclnfo en
ArcMap gebruik te maken. Dit impliceert dat AVV t.z.t. de benodigde licenties moet aanschaffen.
Arclnfo/Map bevat standaard al veel van de functionaliteit die vereist is voor de BVMS applicatie,
terwijl voor de eigen user interface alle functionaliteit geprogrammeerd zal worden. Bovendien is de
ArcMap interface in principe reeds bruikbaar als BVMS user interface. Besloten werd daarom om de
BVMS user interface te baseren op ArcMap.
Besluit: Baseer de user interface op Arclnfo / ArcMap
5.2
Aanpassen zone-indeling
In principe gaat BVMS uit van een vaste indeling in zones, die een verfijning is van de TEM regioindeling. Vanuit AVV is echter de wens geuit om zones te kunnen toevoegen, bijvoorbeeld om de
effecten van het toevoegen van een nieuwe terminal te kunnen analyseren. Als er in de betreffende
zone een sluis of brug is kan het voor de resultaten van BVMS heel wat uit maken aan welke zijde de
nieuwe terminal komt te liggen. Aangezien elke zone per definitie slechts één voedingspunt heeft, kan
de noodzaak ontstaan om een zone in twee stukken te splitsen. Het manipuleren van de zone-indeling
brengt echter het gevaar met zich mee dat, indien dit te ver wordt doorgevoerd, de validiteit van de
resultaten in het geding is. Daarom wordt voorgesteld om het manipuleren met de zone-indeling
slechts in beperkte mate toe te laten. Een gebruiker mag een zone splitsen in twee stukken, en dan
alleen nog op de voorwaarde dat hij de benodigde aanvullende gegevens invoert (bijvoorbeeld
splitsing van de goederenstromen over de twee delen). Het samenvoegen van zones is niet toegestaan,
omdat de combinatie van samenvoegen en splitsen ertoe leidt dat de zone-indeling compleet kan
worden gewijzigd zonder enige garantie voor de validiteit van de resultaten. Er zijn ook geen cases
naar voren gekomen waarin deze faciliteit noodzakelijk is.
Besluit: Het splitsen van een BVMS-zone in twee stukken is toegelaten, het samenvoegen van
zones niet. Op uitvoerniveau kunnen de resultaten van verschillende zones natuurlijk wel
geaggregeerd worden.
01 3N 062 31151
5.3
15
Aanpassen goederengroepen-indeling
In principe gaat BVMS uit van een vaste indeling in goederengroepen. Aangezien geen wensen tot het
aanpassen hiervan in de user-interface naar voren zijn gekomen, stellen wij voor om een vaste
indeling in 27 groepen te hanteren. Het systeem moet wel de mogelijk open houden om bij een update
naar een nieuwe release de indeling te wijzigen (bijvoorbeeld naar 52 NSTR-2 groepen, als dit
gewenst mocht zijn. De 'super-user' kan ook groepen toevoegen of wijzigen.
Besluit: Vaste indeling in een vast aantal goederengroepen, die alleen bij een nieuwe release van
BVMS aangepast kan worden of door de super-user
5.4
Aanpassen kunstwerken (sluizen, bruggen)
Kunstwerken dienen te worden toegevoegd, wanneer de effecten van bijvoorbeeld de aanleg van een
nieuwe brug onderzocht worden. In een variant is het dan mogelijk een brug toe te voegen. De
structuur en functionaliteit van de Arclnfo applicatie is zodanig dat automatisch een schakel
toegevoegd wordt en een extra vaarwegvak (dat ontstaat als gevolg van toevoeging van de brug).
Eventuele variabelen moeten dan nog van een waarde voorzien worden.
Besluit: Kunstwerken kunnen worden gewijzigd, toegevoegd en verwijderd. Bij het toevoegen
en verwijderen van kunstwerken wordt de gebruiker door de user-interface ertoe gedwongen de
benodigde informatie in te geven, zodat een consistent netwerk gegarandeerd wordt.
5.5
Beheer van basisjaar.
Het is van groot belang dat de gegevens van het basisjaar niet blijvend door een gebruiker kunnen
worden gewijzigd. Met deze gegevens is het systeem immers gecalibreerd. Toch kan het nodig zijn
om incidenteel wijzigingen in het basisjaar aan te brengen. De enige mogelijkheid hiervoor die
momenteel voorzien wordt is het wijzigen van het basisjaar als gevolg van het splitsen van zones. Het
lijkt zinvol om een apart basisjaar te definiëren dat gebruikt wordt voor alle BVMS-runs die bedoeld
zijn om de relevante beleidsvraag te kunnen beantwoorden. Dit noemen wij het projectbasisjaar. In
veel gevallen zal het projectbasisjaar identiek zijn aan het gewone basisjaar, soms zal deze afwijken
(als gevolg van het splitsen van zones).
Besluit: Verander de gegevens van het basisjaar nooit, maar gebruik per project een apart
projectbasisjaar om de benodigde wijzigingen voor een bepaald project vast te leggen.
5.6
Groepering van gegevens
Een gebruiker van het BVMS zal een reeks analyses willen maken om een bepaalde beleidsvraag te
kunnen beantwoorden. Alle gegevens die bij deze analyses betrokken worden zullen worden
gegroepeerd in een Project. Binnen een project maken we onderscheid tussen basisgegevens
(projectbasisjaar), een verzameling variabelen die exogene ontwikkelingen beschrijven (scenario) en
een verzameling van endogene variabelen die beschrijven hoe een beleidsmaker op mogelijke
exogene ontwikkelingen, zoals vastgelegd in een scenario, zal inspelen (variant).
01 3N 062 31151
16
De door het BVMS gebruikte gegevens zijn als volgt gecategoriseerd:
•
invoer die door de gebruiker niet gewijzigd hoeft te worden, zoals bijvoorbeeld de
goederenstromen in het basisjaar. Deze gegevens liggen vast in een deel van de database waar de
gebruiker in principe geen toegang toe heeft.
•
modelparameters die tijdens de calibratie door de TUD zijn vastgesteld en die door de gebruiker
niet gewijzigd mogen worden, daar anders de validiteit van de modelresultaten bedreigt wordt.
Ook deze gegevens liggen vast in een deel van de database waar de gebruiker in principe geen
toegang toe heeft.
gegevens die exogene ontwikkelingen beschrijven waar geen invloed op kan worden uitgeoefend
door maatregelen te nemen ten aanzien van de binnenvaart of het binnenvaartnetwerk, zoals de
gegevens uit de CPB-scenario's. Deze exogene gegevens kunnen door de gebruiker gewijzigd
worden, bijvoorbeeld door een ander CPB-scenario te kiezen. Gemakshalve zullen wij voor de
verzameling exogene gegevens ook de naam scenario gebruiken.
gegevens die mogelijke oplossingen en/of maatregelen beschrijven waartoe de overheid zou
kunnen besluiten, bijvoorbeeld het uitbreiden van sluiscapaciteit, het verdiepen van een vaarweg
of het aanleggen van een nieuwe containerterminal. Deze endogene gegevens zijn ook te wijzigen
door de gebruiker en vormen samen een deel van de database die wij variant zullen noemen.
•
•
Op basis van een zestal cases is onder meer een eerste inzicht verkregen in de te wijzigen invoer (deze
slag heeft plaatsgevonden in het najaar van 1999). Mede op basis hiervan is besproken welke
variabelen in de varianten dan wel scenario's gewijzigd, toegevoegd of verwijderd moeten kunnen
worden. In de Dataspecificatie tabel (zie bijlage 1) is aangegeven welke variabelen door de gebruiker
dan wel de systeem administrator (superuser) gewijzigd dienen te kunnen worden. Er is een
classificatie van 'autorisaties' gehanteerd als volgt:
DB = Attribuut dat niet aangepast kan en mag worden door de gebruiker.
DA = Attribuut dat alleen door de System Administrator (ook wel Superuser) gewijzigd mag worden.
Hier is geen user interface noodzakelijk; de superuser zal direct in de database wijzigingen
aanbrengen.
UV = Attribuut waarvan de waarde in een case door de gebruiker gewijzigd mag worden (endogene
variabelen).
US = Attribuut waarvan de waarde in een scenario door de gebruiker gewijzigd mag worden (exogene
variabelen).
R = Uitvoer van een rekenmodule
Voor de exacte classificatie van de variabelen wordt verwezen naar bijlage 1.
Besluit: Variabelen opsplitsen in projectbasisjaar, scenario en variant. Gegevens groeperen in
projecten, waarbij elk project bestaat uit één projectbasisjaar, één of meer scenario's en één of
meer varianten die onderling compatibel zijn. Binnen een project kan de gebruiker
01 3N 062 31151
17
verschillende analyses maken door het projectbasisjaar te combineren met één van de
scenario's en één van de varianten.
5.7
Bouw van een case
Een case kan worden opgebouwd door een run te draaien voor een combinatie van projectbasisjaar,
scenario en variant. Aan het begin van een project zal een projectbasisjaar worden aangemaakt door
een kopie van het basisjaar of van een ander projectbasisjaar te maken (waarbij opengelaten wordt
hoe dat database technisch het beste opgelost kan worden). In deze kopie mag de gebruiker
wijzigingen aanbrengen door zones te splitsen en daarbij de bijbehorende wijzigingen in het
projectbasisjaar door te voeren, zoals het splitsen van de goederenstromen. Varianten en scenario's
kunnen worden gemaakt door bestaande varianten en scenario's te modificeren. Om te voorkomen dat
bij elk project eerst een compleet nieuw scenario en variant moeten worden aangemaakt, zal het
toegelaten zijn om scenario's en varianten van andere projecten te kopiëren. Het is echter uitsluitend
toegelaten om scenario's en varianten tussen projecten te kopiëren waarvan het projectbasisjaar
hetzelfde is. In andere gevallen zouden er immers allerlei controles op consistentie moeten worden
geïmplementeerd, en dat kost onevenredig veel tijd. Het is toegelaten om het projectbasisjaar te
modificeren (uitsluitend door het splitsen van zones), mits het project niet meer dan één variant en één
scenario omvat.
Besluit: Bouw van een case door projectbasisjaar, scenario en variant te combineren. Scenario's
en varianten kunnen vanaf andere projecten gekopieerd worden, mits deze consistent zijn met
het projectbasisjaar. Hierop zal BVMS een consistentie-check uitvoeren.
01 3N 062 31151
6.
REKENMODULES
6.1
Programmeertaal
18
Het ligt voor de hand om een standaardtaal te kiezen als programmeertaal voor het rekenwerk.
Daarom ligt C++ het meeste voor de hand.
Besluit: C++
6.2
Simulatieframework
Een veelheid aan simulatietools is beschikbaar in de markt. Hieronder vallen vooral veel pakketten
die qua modelbouw en user interface (o.a. animatie) goede tot uitstekende functionaliteit bieden
(SiMPLE++, ARENA, Taylor III, etc). Een nadeel van deze modellen is echter de grote hoeveelheid
'overhead' die deze software met zich meebrengt, hetgeen resulteert in relatief lange rekentijden.
Deze software is zeer geschikt voor gebruikers die zelf snel modellen in elkaar willen zetten en
waarvoor de rekentijd niet een grote bottleneck vormt. Dit is voor BVMS echter niet het geval.
Een andere mogelijkheid is om gebruik te maken van zogenaamde 'toolboxen,
simulatieprogrammatuur in een standaardtaal (zoals C++) die goed in te passen is in de ontwikkeling
van een systeem als BVMS. Een voorbeeld hiervan is CSEM18. Dit is een goede optie, met als nadeel
dat de standaardprogrammatuur dan wel betrouwbaar moet zijn. Er zijn namelijk geen aanpassingen
in te maken. De laatste optie is om zelf een simulatieframework te programmeren. Dit kost op zich
tijd, maar heeft als voordeel dat alles in eigen hand is. Vanwege het feit dat het benodigde
simulatieframework voor BVMS eenvoudig is en dus snel ontwikkeld kan worden, wordt de laatste
optie voorgesteld. Een argument daarbij is ook dat er geen ervaringen bekend zijn in het consortium
met toolboxen als CSIM18, waardoor er geen garantie is voor de betrouwbaarheid
Besluit: Ontwikkel zelf een simulatieframework in C++
01 3N 062 31151
7.
ALGEMEEN
7.1
Keuze database pakket
19
Vanwege de aanwezigheid van een Oracle-database bij AVV, ligt het voor de hand om hier op aan te
sluiten. Daarom zal Oracle als database software voor BVMS 1.0 gebruikt worden. Vanuit
pragmatische overwegingen is ervoor gekozen om bij de ontwikkeling van tussenversies van BVMS
gebruik te maken van een Access-database.
Besluit: Baseer BVMS 1.0 op Oracle en tussenversies op Access
7.2
Welke koppelingen vanuit BVMS naar andere systemen zullen worden aangebracht?
Een koppeling tussen BVMS en TEM wordt voorzien voor het bepalen van de goederenstromen in
basisjaar en prognosejaar. Andere koppelingen zijn niet voorzien. Aangezien de datastructuur in ViN
niet bruikbaar is voor BVMS, kan er niet een directe link worden gelegd tussen het netwerk uit ViN
en het BVMS-netwerk. Wel is het mogelijk om het ViN-netwerk om de zetten naar het BVMSnetwerk en om deze procedure te automatiseren. Daarbij kan eventueel ook overwogen worden om
alleen netwerkwijzigingen automatisch over te zetten van ViN naar BVMS. T.a.v. het gebruik van
ViN (of t.z.t. mogelijk NWB-nat) zal ESRI een rapportage opstellen waarin aan de orde komen:
• verschil netwerk database (ViN) en eisen BVMS (modelnetwerk);
• functionele specs conversieprogramma ViN —> BVMS.
Besluit: Alleen een koppeling met TEM; geen koppeling met ViN maar een door ESRI te
bouwen programma om het ViN-netwerk om te zetten naar het BVMS-netwerk. Verder geen
andere koppelingen.
7.3
Calibratie van het model: tijdschaal
Gegeven de projectfase is calibratie nog niet actueel. Wel is duidelijk dat deze activiteit de nodige tijd
vergt. Daarom is het van belang om de calibratie efficiënt en effectief uit te voeren.
Besluit: Zie onder 3.2.
DATABESCHIKBAARHEID EN USER INTERFACE , GEACTUALISEERDE VERSIE D.D. 7 DECEMBER
2000
In het TU Delft rapport "Functionele specificatie modelsysteem binnenvaart versie 0.2: Identificatie in- en uitvoer, databasedefinitie en dummy modules", van 30
november 1999, wordt de database specificatie gesplitst in drie onderdelen:
•
Netwerken.
•
Vlootsamenstelling.
•
Vraagmatrix.
Elk van deze drie onderdelen is verdere uitgewerkt in tabellen, waarin onder meer per veld wordt aangegeven wat de bron is. Per onderdeel wordt eerst een overzicht
van de tabellen gegeven. Vervolgens worden deze tabellen in detail besproken. De oorspronkelijke volgorde van TUD is aangepast, zodat de volgorde van
detailbespreking overeenkomt met de volgorde in de overzichtstabel.
Naast de bronnen voor dataverzameling is deze data-specificatie gebruikt om aan te geven welke objecten en attributen door de gebruiker gewijzigd, toegevoegd
danwei gewijzigd mogen worden. Is het mogelijk een record aan een tabel toe te voegen/verwijderen dan is dit in de toelichting bij betreffende tabel vermeld. .Per
attribuut wordt aangegeven of deze door de gebruiker gewijzigd mag worden indien gewenst. De volgende classificatie wordt hierbij gehanteerd:
•
•
•
•
•
DB = Attribuut dat niet aangepast kan en mag worden door de gebruiker.
DA = Attribuut dat alleen door de System Administrator (ook wel Superuser) gewijzigd mag worden. Hier is geen user interface noodzakelijk; de superuser zal
direct in de database wijzigingen aanbrengen.
UV = Attribuut waarvan de waarde in een variant door de gebruiker gewijzigd mag worden (endogene variabelen).
US = Attribuut waarvan de waarde in een scenario door de gebruiker gewijzigd mag worden (exogene variabelen).
R = Uitvoer van een rekenmodule
Een algemene opmerking ten aanzien van het wijzigen van variabelen is dat indien dit gedaan wordt en daarbij de waarde van attributen in andere objecten tevens
aangepast dienen te worden.dit automatisch gebeurt. De structuur en functionaliteit van de GIS-applicatie Arclnfo zorgt ervoor dat dit automatisch gebeurd. Voorbeeld
hierbij is het toevoegen van een brug; een schakel zal automatisch worden toegevoegd, waarbij dan eventueel nog de additionele attributen van een waarde voorzien
dienen te worden.
Op dit moment is nog niet met Ernst besproken welke output op welke wijze weergegeven dient te worden.
1.1
Netwerken
Voor het onderdeel netwerken zijn door de TU Delft een twaalftal tabellen gespecificeerd (zie tabel 3.1.1), waarvoor input vereist is.
Beschrijving database tabellen netwerkspecificatie
Inhoud
Tabel
bevaarbare verbinding tussen knopen
. 1. schakels
geografische posities
.2. knopen
lijst die aangeeft welke geografische posities als herkomst fungeren
.3. herkomsten
lijst die aangeeft welke geografische posities als bestemming fungeren
.4. bestemmingen
Verzameling van aaneengesloten schakels (vaarwegvakken) die samen een vaarweg vormen. In
.5. vaarwegen
gebruik voor presentatie-doeleinden
schakel die tevens een stuk vaarweg is
.6. Vaarwegvakken
schakel die tevens een kolk is
.7. Kolken
een sluiscomplex is een verzameling bij elkaar horende kolken op één geografische locatie
.8. Sluiscomplexen
schakel die onder een brug doorgaat
.9. bruggen
Tabel met bedieningsregime van een sluis of brug per seizoen en dagtype
.10. bedieningsperioden
Tabel met definitie van bedieningsregimes
.11. bedieningsregimes
achtergrondbelasting op een schakel t.g.v. recreatieverkeer
.12. voorbelasting
stroomsnelheid op een schakel per seizoen en frequentieklasse
13 seizoensstroomsnelheden
vaardiepte op een schakel per seizoen en frequentieklasse
.14. seizoensdiepte
frequentieverdeling van de vaarwegdiepte (waterstand) per seizoen, voor het hele netwerk
.15. frequentie diepte
Identificatie van telpunten; koppeling met schakels
16 telpunt
Onderstaand worden deze zestien tabellen in detail weergegeven.
Tabel 1.1.
Veld
schakelnr
naam
omschrijving
Voorbelstingnr
Dieptenr
Telpuntnr
Vaarwegvak
anode
bnode
lengte
max_breedtek!asse
Opmerkingen
Schakels. Een schakel is een vaarweg, een brug of een kolk binnen een sluiscomplex.
Opmerkingen
Eenheid
Categorie
Omschrijving
Aanwezig
DB
schakel nummer
DA
Aanwezig
DA
Aanwezig
DB
Pointer naar tabel met voorbelastingen
DB
Pointer naar tabel met seizoendieptes
DB
Pointer naar tabel met telpunten
DB
Pointer naar tabel met vaarwegvakken
Aanwezig
DB
a node (begin node van schakel)
DB
Aanwezig
b node (eind node van schakel)
Aanwezig
DB
lengte van de schakel
rmi
Een maximaal toegestane lengte- en breedteklasse is
UV
maximaal toegestane breedteklasse van schip
toereikend. Dan kunnen de min/max
bevaarbaarheidsklasse en de categorie vaarweg
worden weggelaten.
De velden max_breedteklasse en maxjengteklasse
die per schakel worden opgegeven zijn in ViN
beschikbaar, echter, zijn niet eenduidig per schakel.
w
max lengteklasse
max_k*egels
maximaal toegestane lengteklasse van schip
maximaal aantal kegels bij doorvaart
-
UV
UV
max_vaarsnelheid_vol
maximale snelheid waarmee een vol schip mag
varen
[knVhr]
UV
max_vaarsnelheid_leeg
Maximale snelheid waarmee een leeg schip mag
varen
[km/hr]
UV
capaciteit
Maximaal aantal normaalschepen per uur
[se/hr]
UV
type
richtingindicator
Vaarwegnummer
vaste verliestijd
Schakeltype (1: vaarwegvak, 2:brug, 3: sluis)
l=alleen a->b; 2=alleen b->a; 3=tweerichtingen
f 1.2,31
Vaste (instelbare) verliestijd
[min]
DA
DA
DB
UV
Maximum breedte klassen en lengte klassen worden
namelijk voor categorieën van schepen opgegeven.
Afgesproken is dat ten behoeve van het model het
maximum over alle categorieën kan worden
genomen voor de velden max_breedteklasse en
maxjengteklasse.
Zie max_breedteklasse
Er is momenteel geen grens op het aantal kegels,
maar dat kan in de toekomst wijzigen. Voorstel: zet
in de database alle velden op het maximum aantal
kegels. Er moet modelmatig met het oog op de
toekomst met dit veld wel rekening worden
gehouden.
De velden max_vaarsnelheid_vol en
max_vaarsnelheid_leeg bevinden zich in ViN, maar
zijn slechts als "vrij" tekstveld voor handen. Ten
einde deze data te kunnen gebruiken voor
rekendoeleinden moet dus handwerk worden
verricht.
De velden max_vaarsnelheid_vol en
max_vaarsnelheid_leeg bevinden zich in ViN, maar
zijn slechts als "vrij" tekstveld voor handen. Ten
einde deze data te kunnen gebruiken voor
rekendoeleinden moet dus handwerk worden
verricht.
In database voorlopig op oneindig zetten, de
gebruiker kan dit wel aanpassen (met name relevant
voor bruggen en kolken)
Aanwezig
Vervangt tegenliggerschakel
Default-waarde 0 invoeren
Databasestructuur
Voorstel is om een aparte tabel te maken voor vaarweg waarin om. het attribuut Vaarweg_categorie is opgenomen. Vaarwegnummer is toegevoegd om de link te
leggen met de Tabel Vaarweg.
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel. Waar "Aanwezig" staat kunnen de gegevens door AVV uit ViN worden gehaald.
Voor de buitenlandse schakels heeft Simon bekeken wat er beschikbaar kan worden gemaakt; het zal op geaggregeerd niveau mogelijk zijn om data beschikbaar te
maken. Voor de details wordt naar de notitie van NEA verwezen [datum].
De data van de maximale vaarsnelheid van volle en lege schepen is gedeeltelijk aanwezig in ViN.
Stand van zaken NEA medio februari 200!
Voor het buitenland is bij NEA beschikbaar:
•
•
•
•
De maximaal mogelijke laadvermogenklasse-indeling (AW-indeling). Uit deze indeling dient een maximale toegestane lengte- en breedleklasse bepaald te
worden.
De afstand.
Stroomsnelheid.
De totale voortijd (incl. oponthoudtijd).
User Interface
Een schakel wordt in het netwerk aangeklikt en een invulscherm zal verschijnen. Het is niet direct mogelijk om een schakel toe te voegen/verwijderen. Een brug, sluis
(kolk) of vaarweg kan toegevoegd worden. Een schakel zal dan automatisch worden toegevoegd/verwijderd.
Indien de max-breedteklasse of maxjengteklasse zodanig gewijzigd wordt dat de afmetingen conflicteren met de fysieke eigenschappen van bijvoorbeeld de sluis.zal
het systeem dit conflict detecteren middels een melding.
Tabel 1.2.
Veld
ID
naam
omschrijving
X
y
zone
Binnenland
Knopen (=nodes)
Omschrijving
Dbms intern
x-coordinaat
y-coordinaat
BVMS zone
Binnenland: 1; buitenland: 0
Eenheid
9
9
-
[0/1]
Categorie
DB
DA
DA
DB
DB
DB
DB
Opmerkingen
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel.
Er is voor gekozen per BVMS zone slechts één representatieve locatie aan te duiden. Deze locatie is dientengevolge zowel laadplaats als losplaats. Vanuit het BVMS
gezien is er daarom slechts één tabel met knoop- (1.2), herkomst- (1.3), bestemming- (1.4), laadplaatsgewicht- (3.3) en losplaatsgewicht-informatie (3.4). Indien een
bepaalde locatie niet gebruikt wordt voor het lossen van schepen kan het losplaatsgewicht op 0 gesteld worden.
Ter verduidelijking:
Een zone-indeling is een verfijning van de TEM regio-indeling. Elke zone heeft één laad/losplaats. Een laad/losplaats is een knoop in het model.
Stand van zaken NEA medio februari 2001
De zone-indeling in Nederland is, in overleg met de AW, grotendeels hetzelfde gebleven als in het huidige BVMS. Bij Rotterdam is een extra zone toegevoegd (AW:
bij Delfzijl nog een extra zone erbij?). Voor zeeriviervaart zijn knopen op de Noordzee toegevoegd, bij Rotterdam, Amsterdam, Vlissingen en Delfzijl De keuze van
laad/losplaatsen in termen van VIN-locaties is in samenspraak met de A W vastgesteld.
Voor het buitenland zijn de volgende laad/losplaatsen vastgesteld:
•
•
•
•
•
•
•
•
•
•
•
Gent (België)
Antwerpen (België)
Luik (België)
Lille (Frankrijk)
Parijs (Frankrijk)
Straatsburg (Frankrijk)
Nancy (Frankrijk)
Bremen (Duitsland)
Berlijn (Duitsland)
Duisburg (Duitsland)
Mainz (Duitsland)
Aan deze laad/losplaatsen zullen de buitenlandse TEM-gebieden gekoppeld worden.
In bijlage I zijn de binnenlandse laadAosplaatsen opgenomen met hun VIN-code en VIN-naam. In bijlage 2 is een schets opgenomen van de buitenlandse
laad/losplaatsen en de knooppunten op zee.
Tabel 1.3.
Veld
ID
Knoopnr
Herkomsten
Omschrijving
DBMS intern
node nummer die een herkomst is
Eenheid
-
Categorie
DB
DB
Opmerkingen
Categorie
DB
DB
Opmerkingen
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel., zie Tabel Knopen
En voor het buitenland NEA, zie Tabel Knopen
Stand van zaken NEA medio februari 2001
Nog vastgesteld moet worden wat NEA precies moet leveren voor deze tabel.
Databasestructuur
Ernst Bolt vraagt zich af of de Herkomsten en Bestemmingen als aparte tabellen opgenomen worden.
Tabel 1.4
Veld
ID
Knoopnr
Bestemmingen
Omschrijving
DBMS intern
node number that is a destination
Eenheid
-
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel., zie Tabel Knopen
En voor het buitenland NEA, zie Tabel Knopen
Stand van zaken NEA medio februari 2001
Nog vastgesteld moet worden wat NEA precies moet leveren voor deze tabel.
Tabel 1.5. Vaarwegen
Veld
ID
Vaarwegnummer
Vaarwegnaam
Vaarweg_categorie
Databasestructuur
Omschrijving
DBMS intern
Categorie aanduiding vaarweg
Eenheid
-
Categorie
DB
DB
DA
DA
Opmerkingen
Hiervoor wordt de CfcMl-classificatie
gebruikt. Deze classificatie dien alleen voor
gebruik in de user interface (bijv. resultaten
tonen voor alle klasse 4 vaarwegen) en niet
in de modelberekeningen.
Er is een tabel Vaarwegen toegevoegd. De oorspronkelijke tabel Vaarwegen is hemoemd tot Vaarwegvakken. Een vaarwegvak is een deel van de vaarweg die
gekenmerkt wordt door een bepaalde diepte, stroomsnelheid en dergelijke. Een vaarwegvak is een soort schakel. Een vaarweg bestaat uit een aantal schakels; het
Amsterdam-Rijnkanaal is een voorbeeld van een vaarweg. Deze tabel is met name voor presentatie-doeleinden opgenomen.
Tabel 1.6.
Veld
ID
Vaarwegnaam
(inhaairegime)
Breedte vaarwegvak
Vaarwegvakken
Omschrijving
Dbms intern
Inhalen toegestaan? (0: nee, 1: afhankelijk
van belasting op tegenliggerschakel (alleen
inhalen als er in de komende km. geen
tegenliggers zijn), 2: altijd)
Maximale lengte waarmee een schip nog kan
keren op deze schakel
Eenheid
_
Opmerkingen
[0,1,21
Categorie
DB
DA
UV
[m]
UV
Afkomstig uit "Schakels, want alleen relevant voor
vaarwegen
Voorlopig wordt alles op 2 gezet.
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel.
De breedte van het vaarwegvak is in Vin te vinden.
Stand van zaken NEA medio februari 2001
Ook voor buitenlandse vaarwegvakken input nodig voor deze tabel?
Databasestructuur
Het veld Stroomsnelheidnr is verwijderd omdat een vaarwegvak al aan een schakel gekoppeld is. Een vaarwegvak hoort bij een vaarwegnaam (of nummer?) dus dit
attribuut is toegevoegd.
User interface
Een vaarwegvak kan toegevoegd/verwijderd worden . In het geval een bestaand vaarwegvak ten dele veranderd (bijvoorbeeld de diepte),dan wordt een nieuw
vaarwegvak aangemaakt.
Een vaarwegvak wordt gewijzigd door deze in het netwerk te selecteren; een invulscherm verschijnt en de velden kunnen worden aangepast.
Tabel 1.7
Kolken
De tijden voor de afhandeling van schepen in sluizen zijn aangepast (nu: tijd voor manoevreren, nivelleren en openen/sluiten deuren)
Opmerkingen
Eenheid
Categorie
Omschrijving
Veld
DB
Dbms intern
ID
DB
Pointer naar schakel nummer
Schakelnr
DB
Pointer naar sluiscomplex
Sluisnr
[m]
UV
Kolkbreedte
Breedte van de kolk
[m]
UV
Lengte van de kolk
Kolklengte
[min]
Tijd om waterstand in sluis te nivelleren/
Nivelleertijd
uv
Tiid voor het openen / sluiten van de sluisdeuren
/OpenSluittijd
[min]
UV
Deelkolken zullen niet worden meegenomen.
Stand van zaken NEA medio februari 2001
Voor het deel in het buitenland worden geen gegevens over sluizen verzameld. Effecten van sluizen en bruggen zullen door NEA worden verdisconteerd in de
reistijden.
Data structuur
Nivelleertijd en Opensluittijd kunnen bij elkaar worden genomen als één tijd. De manoeuvreenijd die nodig is om een kolk in- en uit te varen kunnen voor in- en
uitvaren verschillend zijn. Het veld kan evenwel uit de database verwijderd worden
De manoeuvreertijd kan namelijk berekend worden aan de hand van de fuiklengte en de afmetingen van het schip. S lel la Catalano (verantwoordelijk voor het
toedelingsmodel) neemt daarvoor contact op met Ernst Bolt. Om nivelleertijden en opensluittijden te achterhalen zou de sluismeester gebeld moeten worden. Deze data
is dus niet voorhanden en dient handmatig te worden ingevoerd.
User interface
Een sluiscomplex zal niet zo gauw worden toegevoegd/verwijderd; een kolk wel (tabel 3.1.10 dus). Indien dit gebeurt ontstaat er bij toevoegen een nieuw vaarwegvak.
Een kolk is te wijzigen door deze in het netwerk te selecteren en er verschijnt een invulscherm om variabelen te wijzigen.
Tabel 1.8.
Veld
ID
Naam
Sluiscomplexen
Omschrijving
Dbms intem
Naam van sluiscomplex
Eenheid
-
Categorie
DB
DA
Opmerkingen
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel.
Voor het deel in het buitenland worden geen gegevens over sluizen verzameld. Effecten van sluizen en bruggen zullen door NEA worden verdisconteerd in de
reistijden.
Datastructuur
De pointer naar bedieningsperiode is verwijderd. Er is een pointer vanuit Tabel Bedieningsperioden naar de schakel (sluiscomplex of brug).
Tabel 1.9.
Veld
ID
Schakelnr
Max hoogte open
Max hoogte_gesloten
Breedte
Opklap tijd
Bruggen
1 of 2-strooks
Manoeuvreertijd
Omschrijving
Dbms intern
Schakel nummer
Maximale doorvaarhoogte indien brug geopend
Maximale doorvaarhoogte indien brug gesloten
Tijd nodig om brug te openen
kunnen schepen van verschillende richtingen
elkaar onder de brug passeren?
Passeertijd brug
Eenheid
[M]
[M]
[M]
[min]
Categorie
DB
DB
UV
UV
UV
UV
UV
[min]
UV
[min]
UV
Max_omhoogtijd
Tijd nodig om verkeersrichting onder brug om te
keren
Maximale tijd dat brug omhoog kan blijven staan
[min]
UV
Min dichttijd
Minimale tijd dat brug gesloten moet blijven
[min]
UV
Omkeertijd_verkeersrichting
Opmerkingen
Gegevens zijn niet direct beschikbaar, er zit wel
wat in het oude model. Misschien is er ook wat
via de Bouwdienst te verkrijgen. De verschillen
tussen bruggen lijken echter klein.Voorstel:
Voorlopig overal 3 minuten invullen, dat lijkt
voor BVMSD voldoende.
Het veld " 1 of 2-strooks" kan voorlopig gevuld
worden met de waarde 1.
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel.
Voor het deel in het buitenland worden geen gegevens over bruggen verzameld. Effecten van sluizen en bruggen zullen door NEA worden verdisconteerd in de
reistijden.
Voor alle tijden neemt Stella contact op met Emst. Manoeuvreertijden, omkeertijden verkeersrichting, maximum omhoogtijden en minimum dichttijden zijn analoog
aan de sluizen moeilijk tot nauwelijks te achterhalen. Ook dit probleem kan echter modelmatig worden opgelost.
De data in het SIVAK is in het oude model beschikbaar.
Databasestructuur
De pointer naar bedieningsperiode is verwijderd. Er is een pointer vanuit Tabel Bedieningsperioden naar de schakel (sluiscomplex of brug).
Het attribuut Breedte van de brug is toegevoegd.
User interface
Een brug kan toegevoegd/verwijderd worden . In het geval een brug toegevoegd/verwijderd wordt ontstaat er bij toevoegen een nieuw vaarwegvak. Een brug is te
wijzigen door deze in het netwerk te selecteren en er verschijnt een invulscherm om variabelen te wijzigen.
Vaste bruggen worden ook in deze tabel gezet.
Tabel 1.10.
Bedieningsperioden
Voorstel: Tabel opsplitsen en bedieningsregimes (openstellingen op een dag) en toewijzing van regimes aan dagen/vaarwegen
Veld
ID
Schakelnr
Seizoen
Dagtype
Regime
Omschrijving
DBMS intern
Pointer naar schakel nummer
Bedieningsregime in het gegeven seizoen op
het gegeven dagtype
Eenheid
-
Categorie
DB
D
DB
DB
UV
Opmerkingen
N.B. Referentiewaterstand voor brughoogten wordt nog toegevoegd.
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel. Het is nog niet duidelijk of er voldoende informatie bioven tafel komt om bedieningsregimes uit te splitsen voor
seizoenen. Het datamodel moet wel in deze optie voorzien. Bij gebrek aan gedetailleerde data kan altijd hetzelfde regime voor verschillende seizoenen worden
ingevuld.
Het toedelingsmodel zal geen vertrektijdstipkeuze-deelmodel kennen. Het toedelingsmodel houdt als zodanig dan ook geen rekening met de bedieningsregimes van
sluizen. Dit is onhandig indien één van de onderscheiden regimes een weekendregime is (nauwelijks bediening). Vermoed wordt dat het aantal onderscheiden regimes
tot 4 of 5 beperkt zal blijven. Voorlopig wordt echter van het 24-uurs regime gebruik gemaakt. Deze tabel wordt door Ernst in samenspraak met NEA opgelevert.
Stand van zaken NEA medio februari 2001
Voor hel deel in het buitenland worden geen gegevens over sluizen verzameld. Effecten van sluizen en bruggen zullen door NEA worden verdisconteerd in de
reistijden.
Databasestructuur
Naar alle waarschijnlijkheid zijn er ook nog bedieningsregimes die seizoensgebonden zijn. Deze moeten wellicht nog worden toegevoegd. Hier wordt naar gekeken
worden door de TUD.
User interface
In principe zal het mogelijk zijn een nieuw bedieningsregime in deze tabel toe te voegen (door user of superuser?). De gebruiker kan bij het toekennen van een
bedieningsregime aan een brug of sluiscomplex een pick-list krijgen waaruit een standaard regime gekozen kan worden. Het zal mogelijk zijn een bedieningsregime
voor een aantal sluizen/bruggen tegelijk te wijzigen door deze alle te selecteren en voor een standaard regime te kiezen.
Tabel 1.11. Bedieningsregimes
De tabel geeft een patroon op een dag aan
Omschrijving
Veld
DBMS intern
ID
Omschrijving bedieningsregime
Omschrijving
Aanvang bedieningsperiode 1
Til
Einde bedieningsperiode 1
T12
Aanvang bedieningsperiode 2
T21
Einde bedieningsperiode 2
T22
Aanvang bedieningsperiode 3
T31
Einde bedieningsperiode 3
T32
Aanvang bedieningsperiode 4
T41
Einde bedieningsperiode 4
T42
Aanvang bedieningsperiode 5
T51
Einde bedieningsperiode 5
T52
Eenheid
[hhmm]
[hhmm]
[hhmm]
[hhmm]
[hhmml
[hhmm]
[hhmm]
[hhmm]
[hhmm]
[hhmm]
Categorie
DB
DA
DA
DA
DA
DA
DA
DA
DA
DA
DA
DA
Opmerkingen
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel.
Voor binnenlandse vaarwegen, bruggen en sluizen gaat Ernst na of en waar deze gegevens beschikbaar zijn
Voor het deel in het buitenland worden geen gegevens over bedieningstijden en -regimes verzameld. Effecten van sluizen en bruggen zullen door NEA worden
verdisconteerd in de reistijden.
User interface
Slechts de superuser zal een bedieningsregime kunnen maken aangezien de user in principe uit een standaard regime kiest. Of het mogelijk moet zijn om
bedieningsregimnes toe te voegen zal gekeken moeten worden of er meer dan 5 bedieningsperioden mogelijk zijn.
Tabel 1.12. Voorbelastingen (o.a. recreatievaart, maar hierin zijn ook bijvoorbeeld de bruine vaart en de visserij onder te brengen).
Als seizoenen nemen we 2 seizoenen
•
met recreatieve vaart
•
zonder recreatieve vaart
Er zijn hier verkeersseizoenen opgenomen in plaats van kalenderseizoenen. Daardoor is alles 1 maand opgeschoven.
Voorbelastingen worden weergegeven door middel van een percentage en niet meer door middel van normaalschip-equivalenten.
Het is zeer wel denkbaar dat de voorbelasting niet alleen per seizoen moet worden gegeven, maar ook per type dag (werkdag, zaterdag, zondag). Dit is nu nog niet in
de tabel opgenomen.
Veld
ID
Schakelnr
Voor bell
Voor bel2
Omschrijving
Dbms intern
Pointer naar schakel
Voorbelasting seizoen 1
Voorbelasting seizoen 2
Eenheid
-
7
Categorie
DB
DB
UV
UV
Opmerkingen
Voorlopig op 0 zetten
Voorlopig op 0 zetten
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel.
Simon gaat na welke informatie er uit IVS is te halen. Ernst gaat na welke informatie via de provincies te verkrijgen is
Stand van zaken NEA medio februari 2001
In IVS wordt naast vracht- en tankbinnemaart ook de volgende categorieën vaart waargenomen:
•
•
•
Niet uitsluitend vrachtvervoerende binnenvaart (b.v. losvarende sleep- en duwboten, passagierschepen, dienstvaartuigen en vissersvaartuigen).
Zeevaart (b.v. vrachtschepen, tankschepen, containerschepen en marinevaar-luigen).
Recreatievaart (b.v. motor- en zeiljachten en bruine vloot).
User interface
De voorbelasting heeft vooral betrekking op de sluizen en worden hiervoor meegenomen in de user interface. Het is echter nog wat onduidelijk hoe dit er precies uit
gaat zien en hoe het gebruikt gaat worden. Voorlopig wordt dit naar later verschoven (p.m.)
Tabel 1.13.
Seizoensstroomsnelheden
Deze tabel geeft aan hoe de variaties in stroomsnelheid vastgelegd worden. De seizoenen 1-4 corresponderen met de kwartalen, seizoen 5 is een gemiddelde.
De tabel is bij nader inzien veel te uitgebreid. Eén stroomsnelheid per seizoen lijkt toereikend. Beter nog is volgens Nanne een hydrologisch model waarin de
stroomsnelheid afhangt van vaarwegkenmerken en seizoen.
Er is alleen een verdeling nodig voor vaarwegen, niet voor bruggen en sluizen
Veld
ID
Schakelnr
Stroom 1
Stroom2
Omschrijving
Dbms intem
Eenheid
-
Stroomsnelheid in seizoen 1
Stroomsnelheid in seizoen 2
[m/s]
[m/s]
Categorie
DB
DB
UV
UV
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel. Ermst gaat na waar deze gegevens vandaan kunnen worden gehaald binnen AVV
Opmerkingen
Voor het deel in het buitenland worden geen gegevens over bedieningstijden en -regimes verzameld. Effecten van stroomsnelheden zullen door NEA worden
verdisconteerd in de reistijden.
Stand van zaken NEA medio februari 2001
Voor het buitenland zijn wel stroomsnelheden bekend (zie opmerkingen bij tabel 1.1), echter zonder seizoensindeling.
User interface
Wijzigen van seizoensstroomsnelheden wordt gedaan door één of meerdere schakels te selecteren en middels een invulscherm de stroomsnelheid te wijzigen.
Tabel 1.14.
Seizoensdiepten
Deze tabel geeft aan hoe de variaties in vaardiepte vastgelegd worden. De seizoenen 1-4 corresponderen met de kwartalen, seizoen 5 is een gemiddelde).
Eén diepte per seizoen lijkt toereikend, zie ook tabel Seizoensstroomsnelheden
Veld
ID
Schakelnr
Diep 1 Hoog
Diep 1 Midden
Diep 1 Laag
Diep2Hooa
Eenheid
-
Omschrijving
Dbms intem
Diepte in seizoen
Diepte in seizoen
Diepte in seizoen
Diepte in seizoen
1 bij hoge waterstand
1 bij hoge waterstand
1 bij hoge waterstand
2 bij hoge waterstand
[m]
[ml
[m]
[m]
Categorie
D
D
UV
UV
UV
UV
Opmerkingen
Toegevoegd
Toegevoegd
Toegevoegd
Toegevoegd
n.a.v. keuze-memo, 25/7/00
n.a.v. keuze-memo, 25/7/00
n.a.v. keuze-memo, 25/7/00
n.a.v. keuze-memo, 25/7/00
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel. Ernst gaat na waar deze gegevens vandaan kunnen worden gehaald binnen AVV
Voor het deel in het buitenland worden geen gegevens over bedieningstijden en -regimes verzameld. Effecten van stroomsnelheden zullen door NEA worden
verdisconteerd in de reistijden.
User interface
Wijzigen van seizoensdiepten wordt gedaan door één of meerdere schakels te selecteren en middels een invulscherm de seizoendiepte te wijzigen. Deze tabel wordt in
één invulscherm gecombineerd met tabel 3.1.9 Seizoensstroomsnelheden.
Tabel 1.15.
frequentie_diepte
Deze tabel geeft aan hoe de frequentieverdeling in vaardiepte (waterstanden) per seizoen, voor het hele netwerk. Deze tabel is toegevoegd n.a.v. het opstellen van het
keuzememo van 25/7/00. De seizoenen 1-4 corresponderen met de kwartalen, seizoen 5 is een gemiddelde).
Veld
ID
Schakelnr
Seizoen
Stand
Frequentie
Eenheid
.
Omschrijving
Dbms intern
Seizoenindex: 1,2,3,4,5
1 =hoog, 2=midden, 3=laag
Percentage van de tijd dat alle
vaarwegen in periode Seizoen de
waterstand Stand hebben
Categorie
Opmerkingen
D
D
D
D
D
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel. Ernst gaat na waar deze gegevens vandaan kunnen worden gehaald binnen AVV
Tabel 1.16.
Telpun ten
Deze tabel is nodig voor calibratie, vulling hiervan is volgens Nanne niet urgent.
In deze tabel worden de telpunten aan het netwerk gekoppeld. Op IVS telpunten wordt naast de matrix van scheepsbewegingen ook de vrachtmatrix waargenomen; op
radar-telpunten wordt geen matrix waargenomen, maar worden alleen de aantallen schepen geteld.
Veld
telpuntnr
schakelnr
Type
Scheepstype
Scheepsklasse
Goederengroep
Aantal schepen
Aantal tonnen
Omschrijving
Telpunt nummer
Pointer naar schakel
(1: IVS, 2: radar)
Eenheid
-
Waargenomen aantal schepen
Waargenomen aantal tonnen
goederen
[l/week]
[l/week]
Categorie
DB
DB
DB
DB
DB
DB
DB
DB
Opmerkingen
Dataverzameling
AVV dient input te leveren voor bovenstaande tabel. Input voor bovenstaande tabel uit FVS kan verkregen worden.
Voor de radar-telpunten gaat Emst na wat er beschikbaar is.
Voor het buitenland gaat Simon na wat er beschikbaar is.
Stand van zaken NEA medio februari 2001
Omdat binnenlands vervoer in het buitenland (b.v. binnenlands vervoer in Duitsland) niet in BVMS zit, hebben tellingen van schepen en tonnen op buitenlandse
vaarwegen geen relatie met BVMS-uitkomsten. Derhalve is het beter grenspunten als telpunten ie nemen voor internationaal vervoer. Als bron hiervoor kunnen CBS en
IVS gegevens gebruikt worden.
User interface
Deze tabel is niet relevant voor de user interface. De telpunten zijn slechts voor kalibratiedoeleinden nodig en niet voor visualisatie.
1.2
Vloot en goederengroepen
Voor het onderdeel vloot zijn door de TU Delft een vijftal tabellen gespecificeerd (zie tabel 3.2.1), waarvoor input vereist is.
Beschrijving database tabellen specificatie vloot en goederengroepen
Inhoud
Tabel
Tabel met de onderscheiden goederengroepen
2.1. goederengroep
Tabel die aangeeft welke goederengroep door welk scheepstype vervoerd kan worden
2.2. vervoerbaar
Tabel met alle scheepstypen
2.3. scheepstype
Tabel met eigenschappen van een scheepsklasse
2.4. scheepsklasse
Tabel met eigenschappen van elke combinatie van scheepstype en scheepsklasse (lengte, breedteklasse)
2.5. scheepsdata
Tabel met relatie tussen diepgang en belading voor scheepsklassen
2.6. diepgang
Onderstaand is de inhoud van de bovenstaande tabellen nader gespecificeerd.
Opmerkingen
Tabel 2.1.
Goederengroep
Open staat nog de keuze van goederengroepen. In de oude versie van BVMS wordt een aggregatie van de 52 NSTR-2 klassificatie gebruikt. Dit zijn in totaal 27
groepen. Voorstel: Handhaaf deze klassifikatie.
Simon zoekt de indeling van 52 NSTR-2 groepen in 27 BVMS-goederengroepen op.
Omschrijving
Dbms intern
Samenvoeging van NSTR_2 code (27 groepen)
Omschrijving goederengroep
Waardedichtheid
Eenheid
[ecu/m(]
Categorie
DA
DA
DA
DA
Volumedichtheid
Volumedichtheid
[kgW]
DA
gemiddelde partijgrootte
pJcegelO
Gemiddelde partijgrootte
Aandeel van deze goederengroep dat geen kegel voert
[kg * 1000]
-
US
p kegel 1
p kege!2
p kegel3
Aandeel van deze goederengroep dat 1 kegel voert
Aandeel van deze goederengroep dat 2 kegels voert
Aandeel van deze goederengroep dat 3 kegels voert
Veld
ID
BVMS code
Naam
Waardedichtheid
Symbool
us
Opmerkingen
TNO kijkt of er uit SMILE data
kunnen worden aangeleverd.
Verder nu niet al te veel energie
aan spenderen.
NEA bekijkt of de door TNO
aangeleverde gegevens toereikend
zijn. Verder nu niet al te veel
energie aan spenderen.
Deze procentuele verdeling is
opgesplitst in 4 percentages
US
-
us
us
Dataverzameling
Als bron voor de gegevens in de tabel Goederengroep kunnen IVS en CBS gebruikt worden. Gegevens over het volume van goederen zijn in deze bronnen niet
voorhanden, zodat de velden waardedichtheid en volumedichtheid niet hieruit te bepalen zijn (dus aparte dataverzameling noodzakelijk). Voor wat betreft waarde zijn
wellicht gegevens uit CBS-handelsbestanden bruikbaar te maken.
De velden gemiddelde partijgrootte en pjcegel kunnen uit genoemde bronnen wel gevuld worden.
Voor de logitparameter hoeven in principe geen data te worden aangeleverd. TUD zal aangeven als er zinvolle data hiervoor gewenst zijn en deze ook te vinden zijn
(bijv. elasticiteiten uit TEM).
De logitparameter uit de goederengroepen kan tijdelijk verwijderd worden. Uiteindelijk zijn er veel meer parameters waaraan de modelbouwer zou kunnen draaien. De
introductie van slechts één van deze parameters in de database werkt verwarrend. Modelparameters kunnen beter later aan een losse database worden toegevoegd.
Stand van raken NEA medio februari 2001
In bijlage 3 is de relatie tussen de 52 NSTR 2-digit goederengroepen en de 27 goederengroepen uit het huidige BVMS opgenomen.
Voor waarde- en volumedichtheid kunnen waarschijnlijk gegevens van SMILE bruikbaar gemaakt worden. Voor informatie over kegels zijn gegevens uit [VS
beschikbaar, voor 1996 en/of 1998. In CBS gegevens is geen informatie opgenomen over waarde- en volumedichtheid, noch over het aantal gevoerde kegels
User interface
Een goederengroep zal geselecteerd kunnen worden, waarna de diverse aandelen van kegels ingevuld kunnen worden tot het totale aandeel 100% is. De som der delen
mag niet groter dan 100 zijn.
AVV merkt op dat de indeling naar kegels niet correspondeert met de categorieën 'blauw, 1 -rood...' zoals deze in de keuzememo aangeduid worden.
Tabel 2.2.
Vervoerbaar
Vervoerbaarheid hangt alleen af van Scheepstype, niet van scheepsklasse (lengte, breedte)
Omschrijving
Veld
Dbms intern
ID
Goederencode (b.v. NSTR_2 of samenstellingen
Goederencode
hiervan)
Scheepstype identificatie
Scheepstype nr
Eenheid
-
Categorie
-
DA
DA?
Opmerkingen
Dataverzameling
Op basis van de certificaat gegevens (Scheepvaartinspectie) "tankklasse ADNR" en "vrachtklasse ADNR", kan aangegeven worden welke goederen met welke
scheepstypen vervoerd kunnen worden.
AVV heeft enige weken geleden bij de scheepvaartinspectie om deze gegevens verzocht. Vulling van de tabel vervoerbaarheid kan niet geschieden op basis van
contacten met de scheepvaartinspectie. Deze tabel dient daarom door de gebruiker te worden ingevuld.
Nanne checkt hoe diepgang in het model verwerkt zit met Karel. Rekening dient gehouden te worden met trim bij belading
Stand van zaken NEA medio februari 2001
In eerste instantie was het idee om voor deze tabel gegevens te gebruiken van de Scheepvaartinspectie. Omdat de Scheepvaartinspectie geen integrale bestanden ter
beschikking stelt (tabellen en enkele individuele scheepsgegevens zijn wel mogelijk), is nu niet aan te geven of dit een te gebruiken bron is. Wellicht kunnen ook
gegevens uit IVS of CBS voor deze tabel gebruikt worden. Omdat de scheepstype-indeling nog niet definitief vastgesteld is(zie tabel 2.3/2.4), kunnen op dit moment nog
geen precieze uitspraken gedaan worden over de te gebruiken bron(nen).
User interface
De gebruiker kan niets wijzigen. Alleen de superuser kan hier records wijzigen en/of toevoegen (goederencodes). Wordt nader bekeken maar is nu niet relevant voor
user interface.
Tabel 2.3.
Scheepstype
Een schip wordt gemodelleerd door een combinatie van scheepstype en scheepsklasse
Categorie
Eenheid
Omschrijving
Veld
DA
Uniek id voor scheepstype
Scheepstypenr
Omschrijving
Opmerkingen
Voorstel
1 = motorvrachtschepen
2 = motortankschepen
3 = schepen met duwbakken, incl sleepvaartuigen
4 = containerschepen
DA
Dataverzameling
Gegevens voor deze tabel kunnen verkregen worden uit CRB, PVR en gegevens van de Scheepvaartinspectie. Voor het veld "containers" geldt dat het soort vaartuig in
bijvoorbeeld CRB niet altijd voldoende inzicht verschaft. Zo kunnen sommige, als motorvrachtschepen aangeduide schepen, ook containers vervoeren.
Het aantal kegels is niet afhankelijk van het type schip maar van de vervoerde lading. Uit certificaatgegevens (Scheepvaartinspectie) is wel "tankklasse ADNR" en
"vrachtklasse ADNR" bekend.
Stand van zaken NEA medio februari 2001
Middels een notitie "Definitie klasse-indeling voor de binnenvaart" van 17 augustus 2000 heeft NEA voorde klasse-indeling een voorstel gedaan. Op basis hiervan
heeft A W in overleg met de TUD een aangepast voorstel gemaakt, waarin ook de scheepstype-indeling veranderd is. Voor scheepstypen wordt uitgegaan van
motorvrachtschepen, motortankschepen en containerschepen. Duweenheden worden niet meer als apart scheepstype beschouwd. Voor tabel 2.4, en in samenhang
daarmee tabel 2.5, is er ook nog een voorstel van de TUD voor een andere indeling. Noch de scheepstype-indeling noch de scheepsklasse-indeling zijn op dit moment
definitief vastgesteld.
Tabel 2.4
Scheepsklasse
Een indeling in scheepsklassen moet nog worden gemaakt. Gedacht wordt aan een indeling in ongeveer 7 lengteklassen en maximaal 2 breedte klassen per
lengteklasse, afhankelijk van het scheepstype. In totaal zullen er hooguit 15 scheepsklassen (combinatie van lengte- en breedteklasse) per scheepstype worden
gedefinieerd. Simon maakt een voorstel op basis van IVS-data zodra hij de IVS-data binnen heeft.
Opmerkingen
Categorie
Eenheid
Omschrijving
Veld
DB
Uniek id. voor scheepsklasse
klasse nr
Identificatie lengte-klasse
lengteklasse nr
Identificatie breedte-klasse
breedteklasse nr
Omschrijving scheepsklasse
DA
Omschrijving
DA
[m]
Maximale lengte
MaxLengte
DA
fm]
Maximale breedte
MaxBreedte
Stand van zaken NEA medio februari 2001
Zie stand van zaken bij label 2.3.
Databasestructuur
Ernst vraagt zich af waarom er een apart identificatienummer voor lengte-klasse en breedteklasse is.
Tabel 2.5. Scheepsdata
Een aparte tabel is gemaakt, omdat allerlei gegevens moeten worden gegeven per combinatie van lengteklasse, breedteklasse en type.
Opmerkingen
Eenheid
Categorie
Omschrijving
Veld
DB
Identificatie scheepsklasse (combinatie
klasse_nr
lengteklasse en breedteklasse)
DB
scheepstype
type nr
[m]
US
Max. hoogte ongeladen
Hoogte ongeladen
hoogte ongeladen
[m]
US
Max. hoogte beladen
Hoogte geladen
hoogte_geladen
[kg * 1000]
Maximaal laadvermogen
max lading
us
[ml
Maximaal laadvolume
max volume
us
[km/hr]
Maximale kruissnelheid
max kruissnelheid
us
Brandstofverbruik vol schip
[UKm]
Gesplitst in brandstofverbruik vol en leeg
Brandstofverbruik vol
us
[IVKm]
Brandstofverbruik leeg schip
Brandstofverbruik leeg
us
geïnstalleerd vermogen
jl_afschrijving
c personeel
C overig
K vast
K_wachten
Geïnstalleerd vermogen
Jaarlijkse afschrijving
Personeelskosten per uur
Overige kosten per uur
Basis tarief
Kosten bij wachten
[kw]
[ecu/jr]
[ecu/hr]
[ecu/hr]
[ecu]
[ecu/hr]
US
US
US
US
US
US
K stilliggen
K varen vol
K varen leeg
Aantal-beschikbaar
Kosten bij stilliggen
Kosten varen (vol)
Kosten varen (leeg)
Aantal beschikbare schepen in deze klasse en
[ecu/hr]
[ecu/hr]
[ecu/hr]
US
US
US
US
van dit type, TV'
Verschil met T_stilliggen is dat wachten
betrekking heeft op wachten voor bijv. sluizen
/ bruggen (stilliggen met de motor aan)
Tijdens de klankbordgroep van 6 juli heeft
NEA gemeld dat deze aantallen goed te
achterhalen zijn.
Dataverzameling
Als bron voor de velden lengte t/m geïnstalleerd vermogen, met uitzondering van maxjcruissnelheid, kan het CRB, IVR en de meetbrieven van de
Scheepvaartinspectie gebruikt worden.
Uit de bij NEA aanwezige exploitatiegegevens van schepen kan ook informatie over snelheden afgeleid worden, b.v. onderscheiden naar beladen vaart en leegvaart. Of
dit voldoende is om het veld maxjcruissnelheid, zoals opgenomen in tabel 3.2.4, te vullen dient nog nagegaan te worden.
De velden jl_afschrijving t/m T-varenJeeg kunnen gevuld worden met exploitatie-gegevens die bij NEA beschikbaar zijn. Wel dient dan in plaats van "tarief',
"kosten" genomen te worden.
De tariefstructuur is nog onderwerp van discussie, denk bijvoorbeeld aan de vraag of verschillende tarieven per deelmarkt moeten worden gehanteerd. TUD (Karel
Lindveld) zal contact opnemen met NEA (Hans Visser). Zij zullen gezamenlijk met een voorstel komen.
De brandstofkosten per liter ontbreken nog als variabele
Stand van zaken NEA medio februari 2001
Vulling van deze tabel is afhankelijk van de klasse-indeling (tabel 2.4). Daarnaast is er van TUD een voorstel (zie stand van zaken bij tabel 2.3) om de labellen 2.4 en
2.5 anders in te delen. Hierover vindt nog overleg plaats tussen A W en TUD.
Ter onderscheiding van de verschillende kosten, die in het NEA kostenmodel binnenvaart beschkbaar zijn, is een notitie (zie bijlage 4) aan TUD en A W gestuurd,
waarin opgenomen welke kosten en activiteiten in het NEA kostenmodel onderscheiden worden.
Tabel 2.6.
Diepgang
NEA zal per scheepstype en per scheepsklasse een relatie schatten tussen tonnage en diepgang. Dan dienen de parameters van de betreffende functie in de tabel te
worden opgenomen (functie nog te specificeren)
Categorie
Opmerkingen
Eenheid
Omschrijving
Veld
Dbms intem
ID
DB
Pointer naar scheepsklasse
klassenr
Pointer naar scheepstype
DB
typenr
9
DA
1 of meer parameters, nog te specificeren
nog te specificeren
parameters
Gegevens voor de relatie tussen diepgang en belading kunnen verkregen worden uit de meetbrieven van de Scheepvaartinspectie. In deze meetbrieven is het verband
opgenomen tussen de gemiddelde inzinking in cm en de daarbijbehorende hoeveelheid tonnen.
Stand van zaken NEA medio februari 2001
De Scheepvaartinspectie zal niet integraal haar gegevens over de relatie tussen diepgang en belading van schepen ter beschikking stellen. Wel is het mogelijk voor
(een aantal) individuele schepen gegevens over deze relatie te verkrijgen.
NEA heeft inzinkingfuncties beschikbaar per scheepstype (motorvrachtschepen, motortankschepen, vrachtduwbakken en tankduwbakken) en per laadvermogenklasse
uit het PAWN-model (ontwikkeling in de jaren 80). In deze functies zijn het aantal tonnen per dm inzinking afhankelijk van het laadvermogen en de maximale diepgang
van een schip. De maximale diepgang dient dan wel als veld in de tabel scheepsdata te worden opgenomen. Wellicht kan de bruikbaarheid van deze functies getoetst
worden door gebruik te maken van gegevens van (een aantal) individuele schepen, waarvan gegevens wel door de Scheepvaartinspectie ter beschikking zullen worden
gesteld.
10
1.3
Vraagmatrix
Voor het onderdeel vloot zijn door de TU Delft zeventien tabellen gespecificeerd (zie tabel 3.3.1), waarvoor input vereist is.
Beschrijving database tabellen matrixspecificatie
Tabel
Inhoud
3.1.TEM Regio-regio matrix
TEM vervoersvraag matrix
TEM vervoersvraag matrix binnenvaart
3.2. TEM Regio-regio matrix,
binnenvaart
3.3. BVMS laadplaatsgewichten
Gewichten van laadplaatsen binnen een TEM regio
Gewichten van losplaatsen binnen een TEM regio
3.4. BVMS losplaatsgewichten
Vervoervraag matrix op BVMS zone niveau
3.5. BVMS zone matrix, alle modi
Vervoervraag matrix op BVMS zone niveau; binnenvaart
3.6. BVMS zone matrix, binnenvaart
3.7. Stuurinfo modesplit berekening
Stuurfile
Veranderingen in verbindingskwaliteit t.o.v. het TEM
3.8. Absolute verbindingskwaliteit
Fracties van de vervoervraag die niet van vervoerwijze kunnen
3.9. Captive fracties
wisselen
Extern bepaalde modal shift
3.10. Extern bepaalde modal shift
Matrix van scheepsbewegingen
3.11. Reizenbestand
Partijgrootteverdeling
3.12. Partijgrootteverdeling
Partijgrootteindeling
3.13. Partijgrootteindeling
Verbindingskwaliteit tussen laad-losplaatsen
3.14. Verbindingskwaliteit
indeling van diepgang in een aantal discrete klassen
3.15. Diepgangsindeling
Distributiefunctie voor de leegvaart
3.16. Distributiefunctie-leegvaart
Een frequentieverdeling van vertrektijdstippen over de week
3.17. Vertrektijdstipverdeling
3.18. Toedelingsresultaat
De berekende schakel-intensiteiten en schakel-reistijden per schakel
Opmerkingen
_^
In onderstaande tabellen worden de in tabel 3.3 1 opgenomen tabellen nader gespecificeerd.
Tabel 3.1.
TEM regio-regio matrix, alle modaliteiten
Het prognosejaar kan van geval tot geval verschillen. Verondersteld wordt dat per case de gegevens voor het prognosejaar uit een TEM run kunnen worden
overgenomen (anders moeten alle mogelijke prognosejaren in de database worden opgenomen, en dat is niet praktisch).
Opmerkingen
Eenheid
Categorie
Svmbool
Omschrijving
Veld
i
DB
TEM herkomstregio
herkomst
DB
TEM bestemmingsregio
bestemming
i
DB
jaar waarvoor de matrix geldt; 0: basisjaar; 0/1
jaar
yyyy
1: prognosejaar
1,2,3.4,5
DB
Seizoen
DB
g
Goederengroep
goederengroep
ton
US
aantal ton van de betreffende
tonnen
f «.TEM
goederengroep in het seizoen
ij
Toegevoegd 25/7 n.a.v. keuze-memo
Percentage gecontaineriseerd vervoer
perc cont
Dataverzameling
De gegevens voor bovenstaande kunnen rechtstreeks uit TEM gehaald worden. Het betreft de modaliteiten wegvervoer, spoorvervoer en binnenvaartvervoer. De TEM
zones betreffen in Nederland 54 verkeersgebieden en in het buitenland 72 gebieden:
•
Duitsland: 22 gebieden + voormalig Oost Duitsland als land.
•
België 12 gebieden.
•
Frankrijk: 14 gebieden.
•
Italië: 3 gebieden.
•
Overig: landen of landengroepen.
De buitenlandse gebieden zullen door NEA worden geaggregeerd tot ongeveer 10 zones.
Stand van zaken NEA medio februari 2001
In Bijlage 5 is de TEM uitvoer opgenomen, die gebruikt zal worden voor het vullen van de tabellen 3.1 en 3.2. Deze uitvoer betreft vervoer in relatie met Nederland of
(concurrerende) overslag in buitenlandse havens. Voor vervoer door Nederland (DZO: doorvoer zonder overlading) is er alleen voor binnenvaart een TEM-bestand.
Dit bestand bevat het veld stroom (l=landstroom, 2=maritieme export, 3=maritieme import), goederengroep NSTR 2-digit, buitenlands verkeersgebied van herkomst
(zie bijlage 5, codes 101 t/m 172) en buitenlands verkeersgebied van bestemming (zie bijlage 5, codes 101 t/m 172).
Voor wat betreft seizoen zijn er voor het basisjaar 1992 voor binnenvaart gegevens voorhanden, waarmee in de TEM-bestanden "seizoen gebracht" kan worden. Voor
weg- en spoorvervoer is geen seizoensinformatie nodig. Voor het prognosejaar stellen we voor de binnenvaart voor hetzelfde seizoenpatroon aan te houden als in het
basisjaar.
De buitenlandse gebieden van TEM zullen als volgt gekoppeld worden aan de buitenlandse laad/losplaatsen:
•
•
•
•
•
•
•
•
•
Gent (België): Tem-gebieden 112, 104, 111, 103, 105
Antwerpen (België): TEM-gebieden 110, 101, 102
Luik (België): TEM-gebieden 106, 107, 108, 109
Lille (Frankrijk): TEM-gebieden 136, 137
Parijs (Frankrijk): TEM-gebieden 139138, 147
Straatsburg (Frankrijk): TEM-gebieden 149, 141, 142, 143, 160. 130
Nancy (Frankrijk): TEM-gebieden 140, 148, 134, 113
Bremen (Duitsland): TEM-gebieden 119, 114. 115, 116, 117, 118
Berlijn (Duitsland): TEM-gebieden 135, 167, 168, 169
11
•
•
Duisburg (Duitsland): TEM-gebieden 121, 120, 122, 123, 124
Mainz (Duitsland): TEM-gebieden 127, 125. 126, 128, 129, 131, 132, 133, 161, 162, 170, 171
De overige TEM-herkomsten en -bestemmingen betreffen landen/gebieden die alleen overzee bereikbaar zijn, zoals Spanje, Portugal en Verenigd Koninkrijk. Deze
landen/gebieden zullen gekoppeld worden aan knopen op de Noordzee.
Voor wat betreft containervervoer in TEM geldt, dat alleen het maritieme containervervoer is opgenomen.
User interface
Het aantal tonnen moet per herkomst en bestemming aan te passen zijn. Aangezien het hier om een grote matrix gaat, zal deze in Excel voorbewerkt kunnen worden.
Hiertoe zal een macro gemaakt worden die in een later stadium nog verfijnd kan worden indien nodig.
Vraag voor Nanne: wat wordt er met andere modaliteiten gedaan (er wordt geen modal shift berekend) ?
Tabel 3.2.
Veld
herkomst
bestemming
jaar
Seizoen
goederengroep
tonnen
TEM regio-regio matrix, binnenvaart
Omschrijving
Symbool
i
TEM herkomstregio
TEM bestemmingsregio
/
jaar waarvoor de matrix geldt; 0: basisjaar;
yyyy
1: prognosejaar
Eenheid
0/1
1,2,3,4,5
g
«.TEM
T
V
perc cont
Goederengroep
aantal ton van de betreffende
goederengroep in het seizoen
Percentage gecontaineriseerd vervoer
ton
Categorie
DB
DB
DB
Opmerkingen
DB
DB
US
US
Toegevoegd 25/7 n.a.v. keuze-memo
Dataverzameling
Zie tabel 3.3.2.
Stand van zaken NEA medio februari 2001
Zie stand van zaken bij tabel 3.1
User interface
Zie tabel 3.3.2.
Tabel 3.3.
Veld
laadplaats
gewichtsfactor
BVMS laadplaats gewichten
Omschrijving
Symbool
BVMS laadplaats
r
relatieve gewicht van deze locatie
Gr
Eenheid
Categorie
DB
US
Opmerkingen
Dataverzameling
De 'gewichten' uit tabel 3.3.4 en 3.3.5 dienen om vervoerstromen uit TEM te desaggregeren naar BVMS-regio's. Omdat de BVMS laad- en losplaatsen nog niet
precies gedefinieerd zijn, is nog niet goed aan te geven of bronnen voldoende gegevens voor deze tabel kunnen leveren.
Voor binnenvaart en spoorvervoer kunnen de betreffende gegevens waarschijnlijk grotendeels uit resp. CBS/IVS en CBS data gehaald worden. Voor wegvervoer is er
geen bron die al het wegvervoer (Nederlandse + buitenlandse ondernemingen) op een laag regionaal niveau registreert.
Ernst merkt op dat de laad- en losplaatsen nog niet definitief vastgesteld zijn (Esri heeft ze ook nog niet) en dat voorlopig hiervoor het oude model aangehouden wordt.
Stand van zaken NEA medio februari 2001
Voor een aantal van de huidige BVSM-zones, die ook in het nieuwe BVMS gebruikt zullen worden, geldt dal deze zich niet in slechts één verkeersgebied bevinden. Dus
b.v. BVMS-zone x bevindt zich in zowel TEM-gebied A als B. Dit is ontstaan doordat de samenstellende gemeenten van een BVMS-zone in meer dan één
verkeersgebied kunnen liggen. De aan een BVMS-zone gekoppelde laad/losplaats, bevind zicht altijd wel in één verkeersgebied, zodat de locatie van de laad/losplaats
bepalend kan zijn voor de desaggregalie van TEM-zones.
Bij de tabellen 3.3/3.4 is het nog de vraag of deze tabellen apart voor binnenvaart, spoor en wegvervoer gemaakt dienen te worden.
Opmerking: In tabellen 3.3/3.4 dient o.i. de relatie met TEM-gebieden nog opgenomen te worden.
User interface
Een laadplaats kan gekozen worden en het relatieve gewicht per TEM-zone kan worden ingevuld. De gebruiker zal eerst een zone kunnen kiezen, waama eenvoudig
een laadplaats geselecteerd kan worden in het netwerk.
Tabel 3.4
Veld
losplaats
gewichtsfactor
BVMS losplaats gewichten
Omschrijving
Symbool
BVMS losplaats
s
relatieve gewicht van deze locatie
H,
Eenheid
Zie 3.3.4.
Stand van zaken NEA medio februari 2001
12
Categorie
DB
US
Opmerkingen
Zie stand van zaken bij tabel 3.3.
Tabel 3.5.
Veld
laadplaats
losplaats
jaar
Seizoen
goederengroep
tonnen
BVMS zone-zone matrix, alle modi
Symbool
Omschrijving
BVMS laadplaats
r
BVMS losplaats
jaar waarvoor de matrix geldt; 0: basisjaar;
yyyy
1: prognosejaar
Eenheid
0/1
1,2,3,4,5
g
j g,BVMS
rs
perc cont
Goederengroep
aantal ton van de betreffende goederengroep
in het seizoen
Percentage gecontaineriseerd vervoer
ton
Opmerkingen
Categorie
DB
DB
DB
DB
DB
R
Toegevoegd 25/7 n.a.v. keuze-memo
US
Dataverzameling
Tabel 3.3.6 is een uitvoertabel van de module "Verfijning naar BVMS zone indeling". Er is derhalve voor deze tabel geen behoefte aan basisdata.
User interface
Ernst vraagt of alleen wellicht voor het prgnosejaar het aantal ton kan worden aangepast. Dit moet met de TUD besproken worden.
Tabel 3.6
Veld
laadplaats
losplaats
jaar
Seizoen
goederengroep
tonnen
BVMS zone-zone matrix, binnenvaart
Omschrijving
Symbool
BVMS laadplaats
r
s
BVMS losplaats
jaar waarvoor de matrix geldt; 0: basisjaar;
yyyy
1: prognose jaar
0/1
1.2,3.4,5
g
J. g.BVMS
rs
Extra_tonnen
tonnen_ms
Eenheid
f g.BVMS
1
rs
perc cont
Goederengroep
aantal ton van de betreffende
goederengroep in het seizoen
aantal extra tonnen per jaar
ton
Categorie
DB
DB
DB
DB
DB
R
US
aantal ton per jaar zoals berekend in
modalsplit module
Percentage gecontaineriseerd vervoer
ton
Opmerkingen
Veld toegevoegd op 12/7/00 door
Matthieu om de gebruiker de
mogelijkheid te geven om bijv. extra
goederenstromen van/naar een nieuwe
terminal in te geven (zie email aan
betrokkenen).
R
US
Toegevoegd 25/7 n.a.v. keuze-memo
Dataverzameling
Tabel 3.3.7 is een uitvoertabel van de modules "Verfijning naar BVMS zone indeling" en "Modal shift". Er is derhalve voor deze tabel geen behoefte aan basisdata.
Tabel 3.7
Veld
Berekeningswijze
Stuurinfo modalsplit berekening
Omschrijving
methode 1 of methode 2
Eenheid
Categorie
Opmerkingen
Zie Masterplan
Dataverzameling
Voor tabel 3.3.8 bestaat geen behoefte aan basisdata.
User interface
In het Run-scherm zal een keuzemogelijkheid opgenomen worden voor methode 1 of 2; dit wordt naar de integratiefase verschoven.
Tabel 3.8
Veld
laadplaats
losplaats
jaar
Absolute verbindingskwaliteit
Omschrijving
' Symbool
r
BVMS laadplaats
s
BVMS losplaats
jaar waarvoor de matrix geldt; 0: basisjaar:
yyyy
1: prognosejaar
g
Goederengroep
Absolute verbindingskwaliteit
Eenheid
0/1
Categorie
DB
DB
DB
Opmerkingen
DB
goederengroep
ecu/ton
R
Absolute
verbindingskwaliteit
Tabel 3.3.9 is een uitvoertabel van de Verkeersproductie module. Er is derhalve voor deze tabel geen behoefte aan basisdata.
Tabel 3.9
Veld
mode
goederengroep
jaar
| captivejract
Captivefracties
Symbool
m
g
yyyy
B
s
OMSCHRIJVING
binnenvaart of overig
Goederengroep
jaar waarvoor de matrix geldt; 0: basisjaar;
1: prognosejaar
fractie captives voor mode overig
Hm
13
Eenheid
0/1
Categorie
DB
DB
DB
US/DA?
Opmerkingen
Dataverzameling
Tabel 3.3.10 dient gevuld te worden voor zowel basis- als prognosejaar. Voor het basisjaar zal ten behoeve van de vulling een analyse gemaakt worden van
vervoerstromen. Bij het bepalen van de captive fractie speelt immers niet alleen de goederengroep een rol, maar ook de herkomst en bestemming van het vervoerde
goed. Zo zijn er b.v. herkomst-bestemming-relaties waarvoor geldt dat binnenvaart geen alternatief is omdat noch de herkomst, noch de bestemming bereikbaar is over
water.
User interface
Aan A W zal gevraagd worden of de gebruiker of superuser de captivefractie moet kunnen wijzigen.
Extern bepaalde modal split
OMSCHRIJVING
Symbool
m
binnenvaart of overig
Goederengroep
g
jaar waarvoor de matrix geldt; 0: basisjaar;
yyyy
1: prognosejaar
Externe modal split
Tabel 3.3.10
Veld
mode
goederengroep
jaar
ExtModalSplit
Eenheid
0/1
Categorie
DB
DB
DB
Opmerkingen
US
Dataverzameling
Deze data zijn bedoeld voor de User interface, er hoeven geen data voor verzameld te worden.
User interface
Het is nog onduidelijk voor Emst en Bert wat hier nu precies gebeurt (en wat de gebruiker precies doet); dit wordt met TUD besproken. Eerste voorstel is dat de
gebruiker voor de 27 goederengroepen het aandeel van de binnenvaart invult. Gebeurt dit voor het prognosejaar?
Tabel 3.11
Veld
jaar
berekeningswijze
Reizenbestand
Omschrijving
Symbool
jaar waarvoor de matrix geldt; 0: basisjaar;
yyyy
1: prognosejaar
c=l: IVS bestand, c=2: synthetische laad-los
c
tabel voor basisjaar c=3: synthetische laad-los
tabel voor prognosejaar c=4: opgehoogd IVS
reizenbestand voor prognosejaar
Eenheid
0/1
Seizoen
laadplaats
losplaats
goederengroep
scheepsklasse
scheepstype
kegel-aantal
containerindicatie
lading
r
s
g
V
j
IVS
BVMS laadplaats
BVMS losplaats
Goederengroep
scheepsklasse
cf. scheepstype-indeling
het aantal kegels
1 als lading gecontaineriseerd is
De hoeveelheid lading aan boord
ton
Categorie
DB
Opmerkingen
DB
Alleen invoer voor c= 1, de rest wordt
berekend.
DB
Door MHE toegevoegd op 10/8 n.a.v.
suggestie SRE.
DB
DB
DB
DB
DB
DB
DB
D/R
"gyq
Dataverzameling
Het reizenbestand, zoals gespecificeerd in tabel 3.3.11, kan zowel betrekking hebben op het basisjaar als op een prognosejaar. Voor het basisjaar zullen de bronnen
zowel 1VS als CBS betreffen. Immers het IVS-bestand bevat niet al het vervoer in relatie met Nederland. In principe bevatten beide genoemde bronnen alle benodigde
gegevens, met uitzondering van het veld "kegel-aantal", dat door het CBS niet wordt geregistreerd. Hiervoor dient dus een oplossing gevonden te worden (NEA).
Stand van zaken NEA medio februari 2001
Voor scheepstype en -klasse geldt dat deze nog vastgesteld moeten worden. Het reizenbestand hoeft alleen voor het basisjaar 1992 gemaakt te worden. Voor dit jaar
zijn door NEA ten behoeve van de huidige binnenvaartmodellen, basisbestanden gemaakt op basis van CBS-bestanden (een IVS-bestand is voor 1992 niet
beschikbaar). In deze bestanden zijn de volgende gegevens opgenomen:
binnenlands vervoer (beladen reizen):
a.
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
goederengroep NVl-indeling
herkomst
bestemming
herkomst verkeersgebied
bestemming verkeersgebied
scheepstype
laadvermogenklasse
vorm van vervoer
aantal reizen
laadvermogen in ton
vervoerd gewicht in ton
1-27
1-206
1-206
1-54
1-54
1-2 (1- geen duwbak, 2 = duwbak)
1-10
1-2 (I = tankvaart/eigen venoer, 2 = overig: wordt gebruikt bij het bepalen van de leegvaart)
internationale aan- en afvoer (beladen reizen):
a.
b.
c.
d.
e.
f.
goederengroep NVl-indeling
herkomst
bestemming
herkomst verkeersgebied
bestemming verkeersgebied
scheepstype
1-27
1-206
1-206
1-172
1-172
1-2(1= geen duwbak, 2 — duwbak)
14
gh.
i.
j-
1-10
laadvermogenklasse
aantal reizen
laadvermogen in ton
vervoerd gewicht in ton
rtnn
JOOi rvocT zonucr overuiuing [ peitt
a.
b.
c.
d.
e.
ƒ
gh.
i.
'}•
goederengroep NVl-indeling
herkomst
bestemming
scheepstype
laadvermogenklasse
herkomst verkeersgebied
bestemming verkeersgebied
aantal reizen
laadvermogen in ton
vervoerd gewicht in ton
1-27
197-205
197-205
1-2 (1= geen duwbak, 2 = duwbak)
1-10
101-172
101-172
Zoals blijkt uit bovenstaande beschrijvingen zijn de basisbestanden voor de huidige binnenvaartmodellen geen reizenbestanden, maar betreft het geaggregeerde
bestanden. Eén record betreft derhalve één of meer reizen. Het CBS beschikt weliswaar over reizenbestanden (apart voor binnenlands en internationaal), echter deze
mogen niet aan derden uitgeleverd worden (vanwege geheimhoudingsplicht). Ten behoeve van de bovenbeschreven bestanden, zijn deze reisbestanden bij het CBS
door NEA bewerkt, en vervolgens geaggregeerd. Deze geaggregeerde bestanden bevatten meer detail dan de bovenbeschreven bestanden. De bestanden bevatten
echter geen gegevens over lengte en breedte van schepen, seizoenen en het aantal kegels. Het in de bestanden opgenomen veld "containerindicator" is onbetrouwbaar.
Zo werden in 1992 bijvoorbeeld de op de Rijn stroomopwaarts vervoerde containers niet apart waargenomen.
Het bovenstaande betekent, dat op de bij NEA beschikbare bestanden van het CBS nog een aantal bewerkingen dienen te worden uitgevoerd. Dit betreft in ieder geval:
•
•
•
•
•
•
Het maken van een reizenbestand uit de geaggregeerde bestanden.
Het inbrengen van de scheepsklasse-indeling.
Het inbrengen van de scheepstype-indeling.
Het inbrengen van het aantal kegels.
Het inbrengen van seizoenen.
Het zo veel als mogelijk corrigeren van hel containervervoer.
Tabel 3.12
Veld
goederengroep
partijgrootteklasse
partijgrootte-intensiteit
jaar
Partijgrootteverdeling
Omschrijving
Symbool
g
Goederengroep
het nummer van de partijgrootteklasse
q
De proportie van aantal partijen in deze
par
F \(<?) partijgrooteklasse t.o.v. het totaal
yyyy
jaar waarvoor de matrix geldt; 0:
basisjaar;
1: prognosejaar
Eenheid
ton
0/1
Categorie
DB
DB
US
Opmerkingen
DB
Dataverzameling
De tabel "partijgrootteverdeling" dient gevuld te worden voor zowel het basis- als het prognosejaar. Voor het basisjaar kunnen als bronnen IVS en CBS gebruikt
worden. Hierbij zal op basis van de partijgrootte op reisniveau, de intensiteit per partijgrootteklasse vastgesteld worden. Voor het prognosejaar is de
partijgrootteverdeling gelijk aan die in het basisjaar. Deze verdeling is door de gebruiker wel aan te passen.
User interface
Aangezien er naar schatting 50 partijgrootteklassen zijn, zal hier ook een link naar een spreadsheet gemaakt worden. De gebruiker kan in de speadsheet de intensiteit
wijzigen. Later zal deze macro verfijnd worden indien gewenst door de gebruiker.
Tabel 3.13
Veld
partijerootteklasse
ondergrens
bovengrens
Partijgrootteindeling
Omschrijving
Symbool
het nummer van de partijgrootteklasse
q
De ondergrens (in ton) die deze
partijgrootteklasse markeert
De bovengrens (in ton) die deze
partijgrootteklasse markeert
ton
Categorie
DB
DA
ton
DA
Eenheid
Opmerkingen
Dataverzameling
De indeling in partijgrootteklassen, zoals weergegeven in tabel 3.3.13, zal afgeleid worden uit een analyse van voorkomende partijgrootten uit IVS en CBS gegevens.
Simon komt met een voorstel. Daarbij kan gedacht worden aan een indeling in ongeveer 50 klassen.
Stand van zaken NEA medio februari 2001
Voor deze indeling is het bijvoorbeeld nog de vraag of deze indeling een relatie hebben met het (maximaal) laadvermogen per scheepsklasse.
De indeling zou er bijvoorbeeld als volgt uit kunnen zien:
•
Tussen 0 en 1000 ton stappen van 100 ton (10 klassen).
•
Tussen 1000 en 2500 ton stappen van 250 ton (6 klassen).
•
Tussen 2500 en 5000 ton stappen van 500 ton (5 klassen).
•
Tussen 5000 en 10000 ton stappen van 1000 ton (5 klassen).
•
Tussen 10000 en 20000 ton stappen van 2500 ton (4 klassen).
•
Groter dan 20000 ton (1 klasse).
15
Over deze indeling dienen nog nadere afspraken gemaakt te worden.
Tabel 3.14
Veld
laadplaats
losplaats
scheepsklasse
diepgangsklasse
verbindings-kwaliteit
Verbindingskwaliteit
Categorie
Opmerkingen
Eenheid
Symbool
Omschrijving
r
DB
L BVMS laadplaats
DB
s
BVMS losplaats
DB
V
scheepsklasse
DB
het nummer van de diepgangsklasse
d
R
ecu
De proportie van aantal partijen in deze
yd
C
partijgrooteklasse t.o.v. het totaal
rs
DB
jaar
jaar waarvoor de matrix geldt; 0:
0/1
yyyy
basisjaar;
1: prognose jaar
Tabel 3.3.14 betreft een tabel die uitvoer is van de Toedelingsmodule. Er is derhalve voor deze tabel geen behoefte aan basisdata.
PM: Wat betekent precies derelatieveverbindingskwaliteit? Zowel de omschrijving als de gebruikte eenheid (ecu -> Euro) klopt niet
Tabel 3.15
Veld
diepgangsklasse
ondergrens
Diepgangindeling
Categorie
Opmerkingen
Eenheid
Symbool
Omschrijving
DB
d
het nummer van de diepgangsklasse
DB
m
De ondergrens (in ton) die deze
diepgangsklasse markeert
DB
m
De bovengrens (in ton) die deze
bovengrens
diepgangsklasse markeert
Op basis van in IVS waargenomen diepgangen zal een klassenindeling gemaakt worden, waarmee tabel 3.3.15 gevuld zal worden, denk aan klassen van 0.5 meter.
Stand van zaken NEA medio februari 2001
De diepgangsindeling wordt gebruikt in tabel 3.14, waarin niet de diepgang van schepen maar de diepgang van een verbinding tussen laad- en losplaats aangeduid
wordt. De indeling dient ons inziens derhalve te worden bepaald uit netwerkgegevens en niet uit IVS-gegevens.
Tabel 3.16
Veld
afstandsklasse
scheepsklasse
functiewaarde
Distributiefunctie-leegvaari
Symbool
Omschrijving
De ondergrens (in kilometer) die deze
afstandsklasse markeert
y
scheepsklasse
distributiefunctie per afstandsklasse
leeg
F
,(c)
Eenheid
km
Categorie
D
m
D
D
Opmerkingen
Dataverzameling
De leegvaartmodule moet nog ontwikkeld worden, zodat over de vulling van tabel 3.3.16 op dit moment geen uitspraken gedaan kunnen worden.
Vult de TUD met calibratietool. Dit deel van het model (leegvaartmodule) staat overigens nog niet vast. Momenteel wordt hiervoor geen extra databehoefte verwacht.
User interface
Aangezien deze module nog ontwikkeld moet worden, is hier voor wat betreft de user interface geen aandacht aan besteed.
Tabel 3.17
Veld
scheepsklasse
vertrekperiode
vertrekintensiteit
jaar
Vertrektijdstipverdeling
Symbool
Omschrijving
scheepsklasse
v
t
uur van vertrek (tussen 0 en 7*24)
De proportie van het totaal die in dit uur
F v v e r t r e k (?)
vertrekt
jaar waarvoor de matrix geldt; 0: basisjaar;
yyyy
1: prognosejaar
Eenheid
Categorie
DB
DB
US
0/1
DB
Opmerkingen
Dataverzameling
De tabel "Tijdstipverdeling", kan zowel het basisjaar als een prognosejaar betreffen. Voor een basisjaar kan de tabel gevuld door het bewerken van IVS-gegevens.
Door terug te rekenen van het tijdstip van passage van het eerste gepasseerde IVS-punt, kan een schatting van het vertrektijdstip bepaald worden. Hierbij wordt gebruik
gemaakt van de afstand tussen de plaats van herkomst en het IVS-punt, alsmede een gemiddelde snelheid. De vertrektijdstipverdeling op uurbasis is toereikend.
Eventueel kan ook gekozen worden voor een verdeling op basis van perioden van 3 uur.
Stand van zaken NEA medio februari 2001
Bij NEA zijn ook nog reisgegevens aanwezig waaruit een vertrektijdstipverdeling bepaald kan worden. Hierbij kan, indien gewenst, onderscheid gemaakt worden
tussen vervoer uit zeehavens en uit niet-zeehavens.
User interface
Deze tabel zal in een spreadsheet wijzigbaar zijn.
Tabel 3.18
Veld
schakel
Toedelingsresultaat
Symbool
Omschrijving
a
schakel
Eenheid
16
Categorie
DB
Opmerkingen
scheepsklasse
schakelreistijd
schakelintensiteit
y
v
v
scheepsklasse
de reistijd voor scheepstype y op schakel a
uur
DB
R
de intensiteit voor scheepstype y op schakel a
schepen/uur
R
DB
jaar
0' basisjaar; 1: progn.jaar
0/1
wvy
Het toedelingsresultaat, zoals gespecificeerd in tabel 3.3.18, is het resultaat van de toedelingsmodule. Er is derhalve voor deze tabel geen behoefte aan basisdata.
17
Bijlage 1
VIN-code
11896
44445
12893
49704
12899
11840
3049
48728
49487
2806
45020
10193
11790
12901
51873
253
618
45249
45552
533
13645
581
11950
11741
45421
49730
2696
13371
12369
11804
166
14027
14034
1151
14054
14047
11963
12329
12355
43895
44077
43936
12338
12885
12878
13102
13110
12237
12228
12226
1189
1568
561
43019
12751
12763
2308
1676
13656
13027
13655
13646
12799
13881
42404
13848
12416
12422
Binnenlandse laad/losplaatsen (VIN-code en -naam)
Naam ligplaats of haven in ViN
Farmsum, Terminal Delfzijl bv
Groningen Hunzehaven, MCS
Groningen, AOG
Zoutkamp, Rostrum bv / Schaaf
Gaarkeuken, ligplaats
Sappemeer, Van Spitsbergenkade
Veendam, Rail-Service Centrum / Vos Groep
Winschoten, Akzo Nobel PQ
Nieuweschans, Kappa-Triton
Julianahaven (Eemshaven)
Schiermonnikoog, veerstoep
West-Terschelling, ligplaats
Dokkum, betoncentrale ELMO
Stroobos, Sikma Veevoeders bv
Leeuwarden, Junokade
Het Dok te Harlingen
Nieuwe Insteekhaven te Makkum
Stavoren, Spoorhaven, ligplaats
Sneek, Van de Horst
Industriehaven Lemmer
Akkrum, Hendrix UTD
Industriehaven-West te Heerenveen
Munnikburen, ligplaats
Drachten, Kijlstra beton bv
Workum, De Boer
Assen, ACM
Alblashaven
Gorinchem, Olieproduktenhandel Tevan-Olie bv
Meppel, Containerservices Meppel bv
Hoogeveen, ACM
Coevorden, haven te
Emmen, Akzo Nobel
Hardenberg, Hemmer Beton
3e Industriehaven te Almelo
Enschede, Betoncentrale Twenthe bv
Hengelo (Ov), Betoncentrale Twenthe bv
Deventer, Mengvoedercentrale DMC bv
Wijhe, ligplaats
Zwolle, Esso Nederland bv
Zwartsluis, Marsman bv
Steenwijk, Friesland Beton / Concrelit
Blauwe Hand, ligplaats
Kampen, Nutricia bv
Emmeloord, ACM
Urk, ligplaats
Dronten, ACM
Biddinghuizen, ligplaats
Elburg, ligplaats
Harderwijk, Steencentrale Harderwijk
Nijkerk, v.d. Ham
Lochem, haven te
Industriehaven Zutphen
Doesburg, haven te
Doetinchem, ABC
Arnhem, Hollandse Constructie Groep (HBG Groep)
Wageningen, Zand en Grindhandel Van Leusden bv
Wijk bij Duurstede, haven te
Industriehaven Zaltbommel
Passewaaij, Korevaer Steenfabriek
Tiel, Landbouwsteiger
Druten, Van Haren Beton bv
Spijk, Boral Nedusa Baksteen / Welling Didam
Huissen, VBI Beton
Nijmegen, Westkanaaldijk
Nijmegen, Container Terminal
Heerewaarden, ligplaats
Veen, ligplaats
Andel, Bouman Mengvoeders
18
VIN-code
12385
1656
13094
13105
12832
12408
12525
12401
13376
12435
12267
1463
1356
12290
12075
12547
13193
12498
51104
52908
13399
2819
13472
13414
13412
12043
13432
13447
12922
12055
2432
1551
12940
13459
1167
12165
12207
54648
12048
12511
13223
12552
13121
13129
13155
46699
13265
12477
13266
13241
12959
52951
12982
12847
51688
48019
380
11872
13690
2949
2934
2741
13682
1962
43160
12571
13362
2746
12652
12998
Naam ligplaats of haven in ViN
Lelystad, Fernhout bv
Flevocentrale NUON nv
Almere, AC De Vaart
Almere, Hagevoort
Culemborg, Aanemingsmaatschappij Hussen
Nieuwegein, Vliet-Jonge
Oude water, Six Mengvoeders
Utrecht, Cereol
Lage Weide, Container Terminal Utrecht/Theo Pouw
Loenen, ligplaats
Amersfoort, Cirkel Betoncentrale
Hilversum, 4e havenarm, zuiderloswal te
Industriehaven te Weesp
Stichtse Brug, De Vries en van de Wiel
Diemen, Betoncentrale en Roossen liften
Uithoorn, Cindu Chemicals bv
Oude Meer, Vermeer Zandoverslag
Haarlem, machinefabriek Figee bv
Amsterdam, Overslag Bedrijf Amsterdam (OB A)
Velsen-Noord, Eutobase
Umuiden, Hoogovens, Buitenkade 2 (Buka 2)
Dirk Metselaarhaven
Zaandam, Gerkens Cacao Industrie
Purmerend, Stoel van Klaveren
Purmerend, BCP Betonmortel
Spijkerboor, W. Woestenburg bv
Alkmaar, Meelfabriek Alkmaar bv
Stolpen, Spaansen
Broekhorn, ligplaats
Schagen, Zand- en grindoverslag Spaansen
Werkhaven Spaansen
Oude Zeug
Medemblik, ligplaats
Den Helder, Gulf
Noorderhaven te Den Oever
Oudeschild, ligplaats
Enkhuizen, Spaansen Transportbedrijf bv
Werkhaven Schelphoek
Edam, ligplaats
Lisse, Otte
Oude Wetering, Boot Betonindustrie bv
Papenveer, ligplaats
Woerden, Pak Mengvoeders
Bodegraven, Meijepad, ligplaats
Alphen aan den Rijn, De Hoorn beton bv
Leiden, Rook Krimpen bv
Voorburg, Mebin Beton
's-Gravenhage, Betoncentrale Fabriton
Delft, NFK Kabel bv
Waddinxveen, ligplaats
Gouda, Unichema Chemi bv
Kortenoord, Blokgroep / E. Blok bv
Krimpen aan den IJssel, Rook Krimpen
Gelkenes, Betonindustrie de Lek
Rotterdam, ECR Heijplaat
Rotterdam, Botlek, Frans Swarttouw
Hartelhaven (NIEUW)
Rotterdam, Europoort, EECV Ertskade
Spijkenisse, Voornse sluis
Spijkenisse, haven te
Uilenvlietsehaven
Wilhelminahaven te Dordrecht
Alblasserdam, NedStaal
Ketelhaven te Papendrecht
Dalm Zandoverslag
Leerdam, Buys
Vianen (ZH), Bonna Vianen
's-Gravendeel, haven te
Middelharnis, Dijkers en Pijl bv
Oud-Beijerland, Mebin Beton
19
VIN-code
12770
2390
2899
2908
2962
12622
2491
2075
11884
2003
42517
492
2551
1467
12285
12716
12714
12701
12671
1116
11918
1052
12145
12424
12414
2987
13905
2991
2996
13938
13870
42105
12111
12113
12117
1087
13763
13599
13844
511
42613
13800
13779
13749
42771
13283
42416
13775
13636
42183
12123
13734
750
11883
Naam ligplaats of haven in ViN
Brouwershaven, ligplaats
Vissershaven te Bruinisse
Burghsluis
Sint Philipsland, haven te
Tholen, haven te
Souburg, ligplaats
Landbouwhaven te Kortgene
Middelburg, Balkenwater
Vlissingen, Sloehaven, ligplaats
Ketelhaven te Goes
Reimerswaal, Kaai 85
Nieuwe haven te Walsoorden
Massagoedhaven
Roosendaal, havens te (Borchwerf)
Steenbergen, van Herel en de Kok
Dinteloord, Maltha Glasrecycling
Dinteloord, Escher Staalconstructie en Mans
Standdaarbuiten, De Mark bv
Breda, CSM Suikerfabriek
Centrale Insteekhaven Moerdijk
Zevenbergen, Beton De Hoorn bv
Amercentrale
Werkendam, Betoncentrale Werkendam
Woudrichem, De Klerck
De Rietschoof, betonindustrie
Oosterhout, haven te
Dongen, Zandoverslag C.J. van Noort & Zn
Industriehaven Loven
Beton Son bv
Lieshout, Bavaria Bierbrouwerij
Heusden, Jonker Fris
's-Hertogenbosch, Buitendijk
Veghel, ligplaats
Helmond, Proreco Regionaal Overslag Centrum
Someren, ligplaats
Billiton Zink bv Budel
Lith, ligplaats
Oss, VBI Beton
Appeltern, SF Beton Groep
Nieuwe Haven te Grave
Betoncentrale Boxmeer
Maashees, Havens Grondstoffen
Neer, Maasoever Mengvoeders
Roermond, Kalle en Bakker
Clauscentrale
Bom, Barge Terminal Bom
Stein, haven te
Maastricht, Wessem Beton Maastricht
Beringe, Heembeton
Nedenveert, ligplaats
Weert, Meneba
Grathem, ligplaats
Edelzand-Brekerij bv
Terneuzen, Braakmansteiger / Dow Chemical
20
Bijlage 2
Buitenlandse knooppunten en knooppunten op zee
21
Bijlage 3
NSTR
0
1
2
3
4
5
6
9
11
12
13
14
16
17
18
21
22
23
31
32
33
34
41
45
46
51
52
53
54
55
56
61
62
63
64
65
69
71
72
81
82
83
84
89
91
92
93
94
95
96
97
99
Relatie tussen de 52 NSTR 2-digit goederengroepen en de 27 goederengroepen uit het huidige BVMS
2- digit goederengroep
Levende dieren
Granen
Aardappelen
Fruit,gr oenten
Textiel,-afval
Hout,kurk
Suikerbieten
Ov grstof pl/drl
Suiker
Dranken
Genotmidd etc
Vlees,vis etc
Bereid landbprod
Veevoer
Olie(zad)en,vet
Steenkool
Bruinkool.turf
Cokes
Ruwe aardolie
Vloeib brandst
Energiegassen
Ov aardoliederiv
Ijzererts
Ov ertsen.afval
Schroot yzer/sta
Ruw ijzer,staal
Halffab staal
Staven staal etc
Plaat-,bandstaal
Pijpen etc
Non-ferromet etc
Zand,grind,klei
Zout.zwavel etc
Ov ruwe miner
Cement.kalk
Gips
Ov bew bouwmat
Nat mest
Kunstmest
Chem basisprod
Aluminiumox etc
Prod stkool etc
Cellul,oud pap
Ov chem prod
Vervoermat
Landbtract,-mach
(Elek) machines
Metaal waren
Glas.keram etc
Leer,text,kled
Ov (halftfabr
Ov (stuk)goed
27 goederengroepen
2 Landbouw I
1 Granen
2 Landbouw I
2 Landbouw I
5 Landbouw II
4 Hout
3 Suikerbieten
5 Landbouw II
6 Voedingsmiddelen
6 Voedingsmiddelen
6 Voedingsmiddelen
6 Voedingsmiddelen
6 Voedingsmiddelen
7 Veevoeder
8 Oliehoudende zaden
9 Vaste brandstoffen
9 Vaste brandstoffen
10 Cokes
11 Ruwe aardolie
12 Vloeibare brandstoffen
13 Energiegassen
13 Energiegassen
14 Ertsen
14 Ertsen
14 Ertsen
15 Metaalhalffabrikaten
15 Metaalhalffabrikaten
15 Metaalhalffabrikaten
15 Metaalhalffabrikaten
15 Metaalhalffabrikaten
15 Metaalhalffabrikaten
16 Zand & grind
17 Overige ruwe mineralen
17 Overige ruwe mineralen
18 Bouwmaterialen
18 Bouwmaterialen
18 Bouwmaterialen
19 Meststoffen
19 Meststoffen
20 Chemische basisprod I
21 Chemische basisprod II
21 Chemische basisprod II
22 Cellulose, papier
23 Chemische produkten
24 Vervoermaterieel
24 Vervoermaterieel
25 Elektrische apparaten
26 Metaalprodukten
27 Overige fabrikaten
27 Overige fabrikaten
27 Overige fabrikaten
27 Overige fabrikaten
22
Bijlage 4
notitie (20-12-2000): kosten binnenvaart
De totale kosten per jaar zijn opgebouwd uit vaste kosten en variabele kosten. De vaste kosten bestaan uit:
•
•
•
•
•
•
•
Afschrijving
Rente
Verzekeringen
Arbeid
Reparatie en onderhoud
Havengelden
Overige kosten (communicatie, administratie etc.)
De variabele kosten bestaan uit:
•
•
Benzinekosten
Reparatie en onderhoud
De totale kosten worden berekend op basis van de duur van verschillende activiteiten en de bijbehorende kosten. De activiteiten die
worden onderscheiden zijn:
nr
1
2
3
4
5
6
7
8
9
10
11
12
13
activiteit
Beladen varen
Beladen kunstwerken
Beladen overig
Leeg varen
Leeg kunstwerken
Leeg overig
Wachten op laden
Netto laadtijd
Wachten op lossen
Netto lostijd
Wachten voor beladen vaart
Wachten voor lege vaart
Wachten op bevrachting
tijd (uur)
kosten (NLG/uur)
ti
C,
t2
0
t4
c2
fj
C5
C3
C4
t6
Có
t?
C7
h
h
t,o
tn
tn
Cs
t,3
Cl3
C9
CJ0
Cll
C/2
Bij elke activiteit worden verschillende soorten kosten berekend, te weten:
Activiteit
Kosten
1,2,3
brandstofkosten beladen varen
variabele kosten reparaties en onderhoud
arbeidsloon
vaste materieelkosten
brandstofkosten leeg varen
variabele kosten reparaties en onderhoud
arbeidsloon
vaste materieelkosten
arbeidsloon
vaste materieelkosten
arbeidsloon wachten op bevrachting
vaste materieelkosten
4,5,6
7,8,9, 10, 11, 12
13
De totale kosten voor de binnenvaartreis zijn gelijk aan
Cl * t , + C 2 * t
2
+ ... + C
J 3
*
t,j
Bij de kostenberekeningen wordt onder meer ook nog onderscheid gemaakt naar de scheepstypen:
•
•
•
•
Motorvrachtschepen
Tankschepen
Duwvaart
Containerschepen
23
Bijlage 5 Beschrijving TEM-output
•
•
•
•
•
•
•
•
•
Stroom
Vervoerwijze
Goederengroep
Herkomst
Bestemming
Haven van herkomst
Haven van bestemming
Vervoerd gewicht in tonnen
Vervoerd containergewicht in tonnen
vervoerwijze
1 Wegvervoer
2 Binnenvaart
3 Spoorwegen
stroom
0 Binnenlands
1 Binnenl. / Buitenl. (internationale invoer over land)
2 Buitenl. / Binnenl (internationale uitvoer over land)
3 Binnenl. / Havens (binnenlands voortraject van export over zee)
4 Havens / Binnenl. (binnenlands natraject van import over zee)
5 Buitenl. / Havens (export over zee buitenland via Nederlandse of buitenlandse havens )
6 Havens /Buitenl. (import over zee buitenland via Nederlandse of buitenlandse havens)
7 Oversl. / buitenl. (Nederland uitgaande doorvoer over land via Nederlandse niet-havens)
8 Buitenl. / Oversl. (Nederland inkomende doorvoer over land via Nederlandse niet-havens)
goederengroep (NSTR 2-digit)
0 Levende dieren
1 Granen
2 Aardappelen
3 Groente/fruit
4 Textielstoffen en afval
5 Hout
6 Suikerbieten
9 Landbouw overig
11 Suiker
12 Dranken
13 Genotmidd.
14 Zuivel/vlees/vis
16 Graan/fruit bereidingen
17 Veevoeder
18 Oliezaden
21 Steenkool
22 Bruinkool
23 Cokes
31 Aardolie
32 Aardolieprodukten
33 Energiegassen
34 Olieprodukten overig
41 Ijzererts
45 Ertsen overig
46 Schroot
51 Ru wijzer/staal
52 Staalhalffrabrikaten
53 Staaf- en vormstaal
54 Plaatstaal
55 Pijpen
56 Non-ferro produkten
61 Zand/grind
62 Zout/zwavel
63 Mineralen overig
64 Cement/kalk
65 Gips
69 Bouwmaterialen overig
24
71
72
81
82
83
84
89
91
92
93
94
95
96
97
98
99
Meststoffen natuurlijke
Kunstmest
Chemische basisprodukten
Aluminiumoxyde/-hydroxyde
Benzol/pek
Cellulose en papier
Chemisch eindprodukten
Vervoermaterieel
Landbouwwerktuigen
Machines
Metaalwaren
Glaswerk
Kleding/leer/schoenen
Fabrikaten
Cont. onbekend
Overige goederen
herkomst/bestemming
1 Oost-Groningen
2 Overig Delfzijl
3 Delfzijl/Eemshaven
4 Overig Groningen
5 Groningen (gemeente)
6 Noord-Friesland
7 Harlingen
8 Zuidwest-Friesland
9 Zuidoost-Friesland
10 Noord-Drenthe
11 Zuidoost-Drenthe
12 Zuidwest-Drenthe
13 Noord-Overijssel
14 Zuidwest-Overijssel
15 Twente
16 Veluwe
17 Achterhoek
18 Agglomeraties Arnhem en Nijmegen
19 Zuidwest-Gelderland
20 Utrecht
21 Kop van Noord-Holland
22 Alkmaar en omgeving
23 Overig Noordzeekanaalgebied
24 Velsen/IJmuiden
25 Agglomeratie Haarlem
26 Zaanstreek
27 Groot-Amsterdam
28 Amsterdam
29 Het Gooi en Vechtstreek
30 Agglomeratie Leiden en Bollenstreek
31 Agglomeratie s-Gravenhage
32 Delft en Westland
33 Oost-Zuid-Holland
34 Overig Groot-Rijnmond
35 Overig Rijnmond
36 Rotterdam
37 Hoek van Holland
38 Vlaardingen
39 Zuidoost-Zuid-Holland
40 Dordrecht
41 Zwijndrecht
42 Zeeuwsch-Vlaanderen
43 Terneuzen en Axel
44 Overig Zeeland
45 Vlissingen
46 West-Noord-Brabant
47 Moerdijk
48 Midden-Noord-Brabant
25
49 Noordoost-Noord-Brabant
50 Zuidoost-Noord-Brabant
51 Noord-Limburg
52 Midden-Limburg
53 Zuid-Limburg
54 Flevoland
101 Antwerpen
102 Brabant
103 West Vlaanderen
104 Oost Vlaanderen
105 Henegouwen
106 Luik
107 Limburg
108 Prov Luxemburg
109 Namen
110 Antwerpen stad
111 Brugge
112 Gent
113 Luxemburg
114 Schleswig-Holstein
115 Hamburg
116 Niedersachsen Nordost
117 Niedersachsen West
118 Niedersachsen Suedost
119 Bremen
120 Nordrhein-Westfalen Nord
121 Ruhrgebiet
122 Nordrhein-Westfalen Suedwest
123 Nordrhein-Westfalen Ost
124 Hessen Nord
125 Hessen Sued
126 Rheinland-Pfalz Nord
127 Reinland-Pfalz Sued
128 Baden-Wuertemberg Nordost
129 Baden-Wuertemberg Ost
130 Baden-Wuertemberg West
131 BayernNord
132 Bayern Ost
133 Bayern Sued
134 Saarland
135 Berlin(West)
136 Noord-Frankrijk
137 Picardie
138 Normandie
139 Parijs
140 Lorraine
141 Frans Compte en Bourgogne
142 Rhone-Alpen
143 Languedoc en Provence-Cote d Azur
144 Pyreneeën
145 Aquitane en Poitou-Charentes
146 Bretagne
147 Centrum Limousin en Auvergne
148 Champagne
149 Saargebied
150 Noord-Italie
151 Midden-Italie
152 Zuid-Italie
153 Denemarken
154 Zweden
155 Noorwegen
156 Ver. Koninkrijk
157 Ierland
158 Spanje
159 Portugal
160 Zwitserland
26
161
162
163
164
165
166
167
168
169
170
171
172
Oostenrijk
Joegoslavië
Griekenland
Turkije
Ov. West-Europa
Sovjet-Unie
DDR (ex)
Polen
Tsj .-Slowakije
Hongarije
Ov. Oost Europa
Rest v/d Wereld
haven van herkomst/haven van bestemming
1 Hamburg
2 Bremen
3 Delfzijl
4 Overig Noordzeekanaalgebied.
5 IJmuiden/Velsen
6 Zaanstreek
7 Amsterdam
8 Overig Rijnmond
9 Rotterdam
10 H. v. Holland
11 Vlaardingen
12 Terneuzen
13 Vlissingen
14 Antwerpen
15 Gent
16 Zeebrugge
27
Memo Voorstel scheepsklasse/scheepstype indeling
Van:
Nanne van der Zijpp, TU Delft
Datum: 15 feb 2001
Inleiding
Binnen het BVMS wordt de vervoersvraag gekoppeld aan scheepsreizen. De vervoersvraag is gegeven in
tonnen per HB-paar per goederengroep, terwijl scheepsreizen onder andere scheepsklasse, scheepstype,
belading, herkomst en bestemming als attributen hebben.
Gezamenlijk bepalen de scheepsklasse en het scheepstype alle eigenschappen van het schip dat binnen het
BVMS beschikbaar is.
Daarbij wordt de scheepsklasse gebruikt om de voor de afwikkeling relevante eigenschappen van een schip
vast te leggen, terwijl het scheepstype wordt gebruikt om de geschiktheid van een schip aan te geven voor
verschillende typen lading.
Attributen
Gezamenlijk bepalen de scheepsklasse en het scheepstype alle eigenschappen van het schip die binnen het
BVMS relevant zijn. Elke combinatie van scheepstype en klasse heeft een groot aantal attributen. Sommige
van deze attributen hangen bij nadere beschouwing alleen van de scheepsklasse af (zie tabel:
Scheepsklasse), andere hangen alleen van het scheepstype af (zie tabel: Scheepstype), terwijl een laatste
groep van de combinatie scheeptype-scheepsklasse afhangt (zie tabel: Scheepstype-per-klasse). Om de
complexiteit zoveel mogelijk te beperken is het aan te raden deze laatste categorie zoveel mogelijk te
beperken.
In de onderstaande opzet zijn daarom een aantal gegevens die betrekking hebben op vaareigenschappen
verhuist van de Scheeptype-per-klasse tabel naar de scheepsklasse tabel. Mogelijk kunnen ook een aantal
gegevens die betrekking hebben op de kosten op deze manier worden verhuist.
Het scheepstype is vooral van belang omdat de tabel 'vervoerbaar' ernaar verwijst.
Scheepsklasse
Veld
Klasse nr
Omschrijving
CEMT klasse
Minimale breedte
Minimale lengte
Maximale breedte
Omschrijving
Uniek id
Aanduiding voor deze
klasse
CEMT klasse waartoe
deze klasse behoort
Minimale breedte die
schepen in deze klassen
hebben, i.v.m. breedte
beperkingen op vaarwegen
Minimale lengte die
schepen in deze klasse
hebben, i.v.m. lengte
beperkingen bij
bijvoorbeeld sluizen.
Maximale breedte
Eenheid
[m]
[m]
[m]
Categorie
Opmerkingen
Minimale breedte
Hoogte ongeladen
Diepgang ongeladen
Maximaal volume
Max-lading
Max-kruissnelheid
Brandstofverbruik vol
Brandstofverbruik leeg
Geinstalleerd vermogen
Scheepstype
Veld
Type_nr
Omschrijving
Minimale breedte
[m]
[m]
[m]
[m3]
[ton]
[km/h]
[L/km]
[L/km]
[kw]
Omschrijving
Uniek id
Aanduiding voor dit
scheepstype
Eenheid
Categorie
Opmerkingen
Eenheid
Categorie
Opmerkingen
[ecu/jr]
[ecu/hr]
[ecu/hr]
[ecu]
[ecu/hr]
[ecu/hr]
[ecu/hr]
[ecu/hr]
D
D
D
D
D
D
D
D
Scheepstype-per-klasse
Omschrijving
Veld
ld van scheepsklasse
Klasse nr
ID van scheepstype
Type nr
Jaarlijkse
afschrijving
jl afschrijving
Personeelskosten per uur
c personeel
Overige kosten per uur
C overig
Basis tarief
K vast
Kosten bij wachten
K wachten
Kosten bij stilliggen
K stilliggen
Kosten varen (vol)
K varen vol
Kosten varen (leeg)
K varen leeg
Aantal-beschikbaar
inzinkingsformule
Aantal beschikbare schepen
in deze klasse en van dit
type, N'
Reken voorschrift dat de
diepgangsverandering als
functie van de belading
aangeeft
DU
Definitieve vorm
hiervan is nog niet
bepaald
Opmerking: Deze opbouw van de verschillende kostenfactoren is nog niet ideaal. Bijvoorbeeld: om hogere
brandstofprijs in te brengen moet K_varen_vol en -leeg en ook K_wachten verhogen. Dat terwijl het
brandstofverbruik vol en leeg ook al opgegeven was. Er moet eigenlijk gewoon een parameter
'brandstofprijs' beschikbaar zijn. Voorts is er ook nog een jaarlijkse afschrijving en personeelskosten (is
dat per persoon of voor de hele bemanning trouwens?) waarmee de inhoud van de K_* parameters al
behoorlijk bepaald zou moeten zijn.
Te onderscheiden scheeptypen
Het scheepstype heeft betrekking op de verschijningsvorm van het schip en de bijbehorende lading. De
volgende types zijn beschikbaar:
•
Motorvrachtschip
•
Tankschip
•
Containerschip
Merk op dat een containerschip uitsluitend gecontaineriseerde lading kan vervoeren, maar dat een
vrachtschip ook kan containers vervoeren.
Koppelverbanden en duwstellen worden niet als een apart scheepstype aangemerkt. In plaats daarvan wordt
voor combinaties in deze categorie aparte scheepsklassen gedefinieerd indien de afmetingen niet te vangen
zijn in de bestaande scheepsklassen.
Te onderscheiden scheepsklassen
De scheepsklasse legt de vaartechnische eigenschappen van een schip of combinatie vast. AVV heeft reeds
een scheepsklasse indeling voorgesteld (zie Tabel 1). Hieraan wordt vastgehouden.
De koppelverbanden en duwstellen passen echter gedeeltelijk nog niet in deze indeling. Het voorstel is om
deze categorieën onder te brengen in bestaande scheepsklassen en in een aantal nieuw te definiëren
scheepsklassen. De volgende tabel geeft aan op welke wijze.
Categorie
Koppel verband
Motorschip met
vaste duwbak
Duwstel met EuroII
bakken
Andere
duwcombinaties
Opmerkingen
Onderbrengen in AVV klassenindeling op basis van de hoofdromp. Een
koppelverband wordt feitelijk als twee aparte schepen beschouwd.
Het betreft hier in feite een motorschip dat de maximaal toegestane lengte voor
motorschepen overschrijdt maar in juridische zin een duwcombinatie is.
Hiervoor is door AVV de BVMS klasse 13 voorgesteld.
Er zijn verschillende configuraties mogelijk. Hiervan worden configuraties met
1,2,4 of 6 bakken in beschouwing genomen. Voor de configuraties met 2 of 6
bakken worden de mogelijkheden van breed en lang varen apart onderscheiden
als klasse.
Andere duwcombinaties worden op grond van tonnage in bestaande
scheepsklassen ingedeeld conform het voorstel van AVV
(
f
Tabel 1: Scheepsklasse indeling BVMS
dvk
bvms
kl
laadv.
klasse
Hl BH IH
standaardschip
CEMT klasse
perc vloot
klasse-grenzen L
T
l e e g •• g e l
1
O
2
2
I
spits
laadvermogen
laags
t
1
h
2/3/4
6.7
50 - 249
20-40
6.9
250 -449
30-55
10.7
0-5.00
5..00-5.11
1.2-2.4
5,11-6,51
1-2-2.3
4
lengte breedte
diepgang
aantal
IVR
t
m
m
m
150
28
5
1.8
434
350
39
2.4
2192
• m ^ r - :.\,-; 340
5.1
;;,;, : '-5;9
•-•••,•••:•
2 , 3
3
4
II
kempenaar
15.2
450 - 649
40-60
6.51-6.71
1.4-2.5
4-5
550
50
6.6
2.5
767
4
5
lla
hagenaar
12.4
650 - 849
50-70
6.71-7.31
1.4-2.6
4-5
750
62
7.2
2.6
640
770
:M:-62
6
5.8
5
7
III
6
8
lila
9
dortmundemskanaal
verl.
dortmunder
oost-europa
schip
rijnhernekanaal
7
10
IV
8
11
12
Va
groot rijnschip
9
13
Vb
10
14
Vlb
r,::.-(y,:;.
50-70
7.31-8.11
1.4-2.6
•fcC;: :• 2.6
ï^.-3.03
(in lila)
850-1049
50-70
8.11-8.31
1.5-2.6
4-5
950
67
8.2
2.6
445
17.7
1050-1249
70-95
8.11-8.31
1.5-2.6
4-5
1150
80
8.2
2.6
919
50-95
8.31-9.11
1.5-2.7
4-5
1180
77
8.9
2.7
491
1.6-2.8
5.25/7.5/
1550
85
9.5
2.8
894
1.6-2.8 5.25/7.5/
1.8-3.5 5.25/7.5/9
.5
1.8-3.5 5.25/7.5/9
.5
1.8-4 5.25/7.5/9
.5
1780
2500
84
10.6
11.4
3.1
977
100
3.2
285
4650
186.5
11.4
4.0
5500
190
16
4.0
11.4
4.2
5.9
10.2
1250-1999
65-110
9.11-9.61
4.2
3.7
2000 - 3499
70-110
80-110
9.61-11.31
11.31-11.50
schip met bak
3500-6000
110-200
11.31-11.50
zeer groot
riinschip
3500-6000
80-
>11.5
Ibaksduwst
3000
95-110
11.31-11.50
1.8-4.1
2950
100
Duvwaart
15
Va
9
16
Vb
2bak lang
6000
172-185
11.31-11.50
1.8-4.1
5900
180
11.4
4.2
9
17
Vla
2bak breed
6000
95-110
22.6-23.0
1.8-4.1
5900
100
22.8
4.2
10
18
Vlb
4baks duwst
12000
185-195
22.6-23.0
1.8-4.1
11800
190
22.8
4.2
10
19
Vlc
6baks breed
18000
193-200
22.6-23.0
1.8-4.1
17700
198
34.2
4.2
10
20
Vlc
6bakslang
18000
270-280
33.9-34.5 i
1.8-4.1
17700
275
22.8
4.2
Functional Specification of the BVMS
Version 0.5:
Specification of the ship type and route choice
model
Prepared for TNO-Inro/ Adviesdienst Verkeer en Vervoer
Ch.D.R. Lindveld
7 januari 2001
Technische Universiteit Delft
Faculteit Civiele Techniek en Geowetenschappen
Sectie Verkeerskunde
Specification of the ship type and route choice model VO.5
1
21-03-01 10:36
BACKGROUND AND MODEL STRUCTURE
l.l
STRUCTURE OFTHIS REPORT
2
THE OVERALL MODEL STRUCTURE OF THE BVMS
4
4
5
2.1
THE SHIP CHOICE MODULE
6
2.2
SPECIFYING THE MODELS AND THEIR DATA USE
8
3
LITERATURE SCAN
10
3.1
REVIEW OF THE GENERAL MODELUNG FRAMEWORK
10
3.2
3.3
3.4
3.5
3.6
THE USE OF L P MODELS
COMBINED GENERATION, DISTRD3UTION, MODE-SPLIT, AND ASSIGNMENT MODELS
COMBINED MODE-CHOICE AND SHIPMENT SIZE MODELS
ROUTE-CHOICE MODELS
MODE CHOICE MODELS
11
12
12
14
15
3.6.1
3.6.2
3.7
3.8
COMBINED ROUTE AND SHIP TYPE CHOICE MODELS
DISCUSSION OF THE LITERATURE SURVEY
3.8.1
3.8.2
3.8.3
3.8.4
3.8.5
3.8.6
3.8.7
3.8.8
3.9
4
4.1
4.2
4.3
5
Model scope
LP-based models and AON models
Combined mode-choice and shipment type models.
Route choice models
Combined route-choice and ship type choice models
Model farm and explanatory factors for ship choice modelling
Model elasticities
Modelling implications
SUMMARY
20
20
20
21
23
24
24
25
26
27
27
29
MODELLING WIDELY DIFFERENT MARKETS
BREAKDOWN OF GOODS STREAMS
MODELLING IMPLICATIONS OF PECULIARITIES AND MARKET STRUCTURE
29
30
32
Ability to sustain losses and the market mechanism
Containers
Sand and gravel
Navigation on the Rhine
North-South navigation
Load factors
MODELLING ROUTE CHOICE
SUMMARY AND CONCLUSIONS
SYNTHESIS AND MODEL SPECIFICATION
5.1 REVISED STRUCTURE OF THE TRAFFIC PRODUCTION MODULE
5.2 THE SHIPMENT SIZE MODEL
5.2.1 Consignment size modelling: criticism
5.2.2 Possible solutions
5.2.3 Model specification for a shipment size model
5.2.4 The possibility of multiple peaks in the shipment size distribution
5.2.5 Converting yearly totals to simulation-period shipments
MODELLING SHIP TYPE AND ROUTE CHOICE
5.2.6
5.2.7
5.2.8
5.3
15
18
SOME CHARACTERISTICS OF THE SYSTEM TO BE MODELLED
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
AA
4.5
Cost variables
Link cost modelling and model type appropriate to market
Intermezzo: possible use of nested logit models
Model proposed for ship type choice
The route choice model
THE UTILITY FUNCTION FOR THE SHIP CHOICE MODEL
5.3.7 Journey cost and link cost functions
5.3.2 Cost calculation
5.4 THE SHIP TYPE CHOICE MODULE
33
34
35
35
35
35
37
39
40
40
41
41
42
42
43
44
47
48
49
50
51
52
53
54
1
Specification of the ship type and route choice model VO.5 21-03-01 10:36
5.4.1
5.4.2
5.5
5.6
5.7
5.8
6
The cost feedback loop
Choice sets and choice set generation
THE SHIP ALLOCATION MODEL
COMMENTS ON THE EMPTY-TRIP MODEL
COMMENTS ON THE MODEL STRUCTURE
NOTES FOR THE CALBRATION PHASE
DATA REQUIREMENTS
6.1
6.2
FLEET RELATED DATA
DEMAND RELATED DATA
6.2.1
6.3
6.4
Additional tables
DATA FOR MODEL ESTIMATION
DATA USE INPUT AND OUTPUT BY MODULE
6.4.7
6.4.2
6.4.3
6.5
Traffic production module
Shipment size model
Ship choice model
SUGGESTIONS FOR DATA COLLECTION AND DATA CLEANING
55
55
57
58
59
59
61
61
61
61
61
62
62
63
64
65
7
SUMMARY AND CONCLUSIONS
66
8
SYMBOLSUSED
68
9
REFERENCES
69
10 APPENDIX A: TABLE OF INPUT DATA ITEMS FOR SHIP TYPE ROUTE CHOICE
MODEL
71
11
APPENDIX B: ADDITIONAL TABLES REQUESTED
73
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Specification of the ship type and route choice model VO.5
1
21-03-01 10:36
Background and model structure
Within the "Binnenvaartmodelsysteem" (BVMS), the purpose of the Traffic Generation
Module is to provide forecasts of inland waterway traffic demand induced by exogenously
calculated freight demand matrix for a forecast year in the BVMS model system. The
forecasts from this model will be used to determine growth factors, which will be applied to
the base matrices to determine the actual forecast.
Central to the traffic generation module are the ship type choice and route choice models.
The purpose of the ship choice model is to model the distribution of cargo over different ship
types given a particular shipment. This model should be sensitive to policy variables, and
should optionally respect fïeet-size limits (fleet size is generally assumed to be able to
accommodate the entire transportation demand).
The purpose of the route choice model is to model the observed spread of traffic over
alternative routes.
This report will propose a model specification for the ship choice model. In view of the need
to specify and implement the model before actual data on the choice behaviour is available,
it was decided to conduct a literature scan to check on possible model forms and explanatory
variables before embarking on the actual specification.
A quick scan was made of a certain key properties of the inland shipping market to check the
appropriateness of the models.
1.1 Structure of this report
The background and the modelling framework in which the ship choice model has to
function are set out in chapter 1. Chapter 2 contains an overview of the BVMS model system
and the place of the traffic generation model (specifically the ship choice model) in it, and
the structure of the traffic generation model as originally conceived. The literature scan is
reported and discussed in chapter 3. The characteristics of the subject system are investigated
in chapter 4, and the model specification is given in chapter 5. The data requirements are
listed in chapter 6. A list of symbols used can be found in chapter 7, and the references are
listed in chapter 8.
Specification of the ship type and route choice model VO.5
2
21-03-01 10:36
The overall model structure of the BVMS
In this chapter we will establish the link between this report and the functional specification
and the overall model structure of the BVMS as specified in [V.d. Zijpp et al. (1999)]. The
overall model structure is reproduced in Figure 1. This report will focus on the traffic
generation module, which is shown as a shaded box.
H-B matrix
goederenstromen
(alle modaliteiten)
laadlosplaats
gegevens
verfijning naar
BVMS
zone indeling
H-B matrix
goederenstromen
(alle modaliteiten)
_£
verbindingskwaliteit per relatie
en goederengroep
modal split
module
Modalshift
Figure 1: BVMS overall structure
The structure of the traffic generation module is reproduced in Figure 2. The base-year datastream is shaded, and the shipment-size model, the ship choice model, and the empty trip
models are hatched.
Specification of the ship type and route choice model VO.5
La-Lo basismatrix
goederenstromen
[tonnen]
waargenomen
La-Lo basismatrix
scheepsbewegingen
21-03-01 10:36
La-Lo progn.matrix
goederenstromen
[tonnen]
I
La-Lo basistabel
goederenzendingen
[tonnen]
La-Lo progn.tabel
goederenzendingen
[tonnen]
geschatte La-Lo
basistabel
scheepsbewegingen
beladen
geschatte La-Lo
prognosetabel
scheepsbewegingen
geschatte La-Lo
basismatrix
scheepsbewegingen
leeg
geschatte La-Lo
prognosematrix
scheepsbewegingen
leeg
beladen
groeifactoren
beladen vaart
j£
groeifactoren
lege vaart
groeifactoren
module
prognose
La-Lo matrix
scheepsbewegingen
Figure 2: Traffic production module
2.1
The ship choice module
The ship choice module ("scheepsinzetmodule") assigns each individual shipment
(characterised by goods type g and shipment size nt) to ship types that are able to transport it.
Specification of the ship type and route choice model VO.5
21-03-01 10:36
It is assumed that ship choice will be based on cost minimisation subject to certain
constraints.
The choice aspects to be modelled are:
•
The ship type. A ship type has a certain tonnage and certain dimensions which determine
which routes are open to the ship.
•
The load factor. The load factor (the ratio between maximum and actual load) determines
the ships draught; for certain routes require a load factor less then 1.
•
The route. Routes are distinguished by travel time and the ship type that can use them.
In practice these factors probably enter the choice process simultaneously. A typical choice
situation may include the choice between a large ship loaded to less than its capacity and
several smaller ships, or between a single fully loaded ship and several partially loaded ships.
The choice set from which a selection is made should include all viable combinations of ship
type, load factor, and route. For this reason the ship type choice model will also have to deal
with route choice.
The choice set is determined partly inside and partly outside the ship choice model. The
assignment module will produce a list of feasible routes for each O/D pair with the
characteristics of these routes (length, free-flow travel time (corrected for the current if any),
waiting time, maximum draught, restrictions on dangerous goods, restrictions on width,
length, and height etc). This approach is known as route enumeration; we expect this
approach to be feasible because of the sparseness of the network.
For each combination of ship type and route a generalised transportation cost will result. One
of components of the generalised transportation cost is the scarcity of each ship type. If the
total demand for a ship type exceeds the number of available ships, an artificial cost is added
to this ship type as a penalty.
Subsequently the shipment is assigned to the combination of ship type and route that results
in the lowest cost for the entire consignment (a consignment may result in several
shipments).
From the above it is clear that the (aggregate) level of service from the assignment module
affects the cost and with it the outcome of the ship choice model. The output of the ship
choice model on the other hand affects the outcome of the assignment. To achieve
consistency between the ship choice model and the assignment model, the system is iterated
a few times. Note that this will only be necessary for the forecast year, as in the base year
the level of service will be calculated by assigning the observed ship movement list to the
network.
Specification of the ship type and route choice model VO.5
vervoervraag
- goederengroep
- totaal tonnage
- zendinggrootte
verdeling
- herkomst
- bestemming
scheepskenmerken
- vaste kosten
- variable kosten
-tonnage
- max. diepgang
- min.diepgang
- max. lengte
- ladingrestricties
- aantal schepen
beschikbaar
Aantal
schepen
per scheepsklasse
per HB paar
verdeling
beladingsgraad
per scheepsklasse
per laadregio
Basismatrix
routes
- wachtijd
- lengte
- max. diepgang
- max. hoogte
- max. lengte
- ladingrestricties
21-03-01 10:36
verbindingskwaliteit
per goederengroep
per laad-los paar
scheepinzet
- aantal ingezette
schepen per
scheepsklasse
verdeling
ladingtype
per scheepsklasse
perlaadregio
bijschatten
lege vaarten &
toepassen
groeifactoren
Laad-Los tabel
Toedeling
Figure 3: The original structure of the ship choice model
2.2
Specifying the models and their data use
The purpose of this report is to specify the ship choice model. This entails a specification of
the model type, structure, a proposal for the model input, and an overview of the algorithms
used.
As no data was available at the time of writing on which to base the selection of explanatory
variables, a list of plausible explanatory variables was taken from the literature.
Specification of the ship type and route choice model VO.5 21-03-01 10:36
Although it is expected that this list covers all variables needed for an acceptable model,
confirmation or refutation of this expectation is only possible when the specified model is
estimated on and validated against empirical data.
As this report will not only be used to document the models, but also to guide the data
collection for both calibration and application of the data, the list of requested explanatory
variables data items should include all explanatory variables that can reasonably be expected
to be significant. Obviously such a list must be expected to contain a number of variables
that will turn out to be redundant when the model is calibrated.
It is conceivable that certain variables that are specified in the report will either be
unavailable, or only with additional effort. In such cases a decision will need to be taken at
consortium level to adapt the model specification, to search for proxy variables, or to invest
the required effort in the data collection.
Specification of the ship type and route choice model VO.5
21-03-01 10:36
3 Literature scan
To aid in selecting a model type and in specifying a ship type choice model and a route
choice model, a literature scan was needed on comparable models in freight transportation
modelling.
The literature on freight transportation modelling was found to a wealth of papers on freight
demand and mode choice. Of these, the freight demand models do not concern us in view of
the decision to use the output of the "Transport Economisch Model" (TEM) as the source of
freight demand information. In a sense the same holds for mode choice as it was decided that
the BVMS model should work with the mode-share forecasts from the TEM. This leaves
shipment-size modelling the choice of ship type, and route choice.
However, ship type choice is just another for of mode choice, and the closest related models
in the literature are freight mode choice models. For this reason they must be included in the
literature scan.
3.1
Review of the general modelling framework
A general framework for freight mode-choice models can be found in [Roberts et al. (1977)].
First of all this report recognises that the market consists of three players: the shipper, the
carrier, and the receiver. All three of them have made commitments through a hierarchy of
previous (long-term) choices (such as investments, location choice etc), and all three must
now make short-term decisions such as whom to do business, and at what price.
Choice of location and plant
size (long run average level
of activitv)
Long run
Choice of supplier
Choice
strategy
of
inventory
Figure 4 : Hierarchy of choices
10
Specification of the ship type and route choice model VO.5
21-03-01 10:36
The authors note that although in the long run all decisions are fluid and interact, the shortterm decisions are taken conditional on the long-term decisions. The decision hierarchy used
is shown in Figure 4.
The following key variables that play a role in mode choice are identified, subdivided
according to whether they concern transport, the commodity itself, market attributes, and
receiver attributes.
T
M
R
Market attributes (at
potential origins)
Receiver attributes (at the
destination end)
C
Transport level of service Commodity
attributes
attributes
Wait time
Value
Price
Use rate
Travel time
Shelflife
Quality
Variability in use rate
Delivery reliability
Seasonality
Availability
Stockout cost
Loss and damage
Density
Production rate
Reorder cost
Tariff
Perishability
Minimum shipment size
Capital carrying cost
Risk of stockout
Special services
Packaging cost
Handling cost
Figure 5 : Factors determining mode choice
The BVMS model only deals with the short-term decisions shown inside the shaded box in
Figure 4.
3.2
The use of LP models
A very recent study conducted at Delft University of Technology on how to model inland
shipping freight transport using Linear Programming (LP) models in the Netherlands is
[Khoshyaran (2000)]. The report on this study has been made available to the consortium
partners, and therefore will not be reproduced in detail here. This study is relevant here
because it focuses on the modelling needs of the BVMS, and will be discussed in some
detail.
The modelling framework used in this study addresses the interaction between shippers and
carriers, and proposed a model system in which the O/D pattern of freight flows, the mode
choice and route choice are modelled.
For the O/D pattern, the ship type choice, and the route choice LP models are proposed,
based on cost minimisation. The costs considered are costs associated of shipping a
particular type of goods between a given origin and a destination with a particular ship type
via a particular route. IPF based procedures are used to ensure consistency between observed
(aggregate) and modelled (disaggregate) O/D matrices and shipping matrices.
The study offers a valuable contribution to the conceptual analysis of the modelling process,
but it was feit that the emphasis on the use of LP models merited some investigation of
alternative modelling approaches.
11
Specification of the ship type and route choice model VO.5
3.3
21-03-01 10:36
Combined generation, distribution, mode-split, and assignment
models
A general integrated modelling approach towards freight transportation modelling has been
reported in [Harker and Friesz (1986a) and (1986b)].
In their papers, Harker and Friesz analyses and model the simultaneous interaction between
shippers and carriers in what they call a Generalized Spatial Price Equilibrium. The model is
operationalised as a non-linear complementarity problem (NCP). Existence and uniqueness
of the resulting NCP are proved. It is furthermore shown that under additional constraints
(strictly monotonie demand and supply functions), the NCP can be reduced to a Variational
Inequality (VI) problem, which is reported to be soluble for large and realistic cases.
3.4
Combined mode-choice and shipment size models
A combined mode-choice (truck versus rail) and shipment size model has been proposed and
estimated in [Abdelwahab, W. et al. (1992)] , and [Abdelwahab, W. (1998)].
The model is simultaneous equation model, and takes the following form:
STi = Pó + PI -CA + p'2.MA + pi .OA + £,'
(1)
SR: =pr0 + p[.CA + pr2.MA + p;.OA + £,'
(2)
I* = # 0 + #, .CA +1?2 .MA + #3 .OA + y/-, .57; + \j/2.5/?, + £,
(3)
where:
'
:
shipment size of ith truck shipment [tonnes]
•
ƒ*
:
:
shipment size of /th rail shipment [tonnes]
an unobserved index which determines mode choice (truck versus rail)
CD
CA
MA
OA .
F
fc fc
:
p
r
r
F
P',
1
:
F
, &
commodity attributes (value, density, state)
mode attributes (freight charges, reliability, transit time)
other attributes (regional dummy variables, volume of commodity moved on
each link by each mode)
:
parameters to be estimated
'' ' ' fc< :
error terms for truck shipment size, rail shipment size, and mode
choice respectively.
The error terms e', e[ , £, are assumed to have a joint normal distribution.
Equations (1), and (2) are linear models that estimate the shipment size, and (3) is an
(unobserved) indicator for regime switch. The quantity ƒ * enters a Probit model for the
selection between truck and rail.
Jourquin et al.
In [Jourquin et al. (1999)], a multi-modal network-oriented freight transportation model is
presented. The model incorporates mode choice (rail, water, road), type choice (e.g. small,
medium, large ships, small and big trucks, ordinary trains and block trains), and route. The
model is used to calculate market-wide elasticities of price changes based on the shift of
traffic flows to the cheapest transport alternative.
12
Specification of the ship type and route choice model VO.5
21-03-01 10:36
The model is not an econometrie one (no discrete choice model), but is GIS-based: all
aspects of transport alternatives (route, mode, and means) are represented in the network.
Routes, modes, and means are determined simultaneously by minimising the total travel cost
TC(l,t,m) as a function of route, mode, and means. Freight is assigned to the least-cost
combination of modes, means, and route using an all-or-nothing (AON) assignment, which is
done by fïnding least-cost paths in the GIS network in which mode, means, and route are
represented explicitly.
The cost of a combination of mode (r), means (m), and route (/) is modelled as:
TC{l,t,m)=YÏ^TClm = X £ ] T e J 2 X +2X J
l
t
m
l
t
m
I jel
jel
W
J
with:
TC(l,t,m)
: total transport cost from origin to destination
TCi,m
'• transport cost on route / with mode f and means m
Qlm
: quantity of goods transported
Atmj
: fixed cost component (capital cost, insurance, maintenance cost, wages)
Btm
: distance-related cost component (speed, fuel consumption, loading rate)
Sj
: distance of link j
This paper also mentions a model for handling time (without giving parameter values):
tllm=a
+ bQïm
(5)
Interestingly, the authors report very good agreement between observed and modelled traffic
flows, especially the mode-split. Although we note that the O/D matrices were estimated for
each mode separately, they were aggregated across modes before assignment to the multimodal network. Apparently the transport costs per mode -on average- reflect the mode-split.
It is interesting that the authors note that the model succeeded quite well in reproducing the
ship type choice.
The model is then used to calculate cross-elasticities between all modes as follows:
N'
t-ml.n.2
— N'
J
C
ml
=;
°ml
C'
„j
yV
+C'
CJ j
m2+yVrn2
<• >
where:
e'mX
m2
iVj|,, Njm2
Cii > CL
: the cross-elasticity between modes ml and ml for goods groupy'
: the amounts (tonnes or tonne / Km) before and after the price increase
'•tne
re
ference cost and the cost after the price increase
(note the use of the mean of the reference and increased costs to calculate the elasticities.)
The authors note that the elasticities have the same order of magnitude as the values found in
the literature, and that the elasticities with respect to price increase of all components of
transport differ from those obtained when only travel costs are increased. This highlights the
13
Specification of the ship type and route choice model VO.5
21-03-01 10:36
necessity of incorporating handling costs and capital cost in addition to pure transport cost.
The model elasticities are reproduced in Figure 6.
Tonnes
Tonnes/
Km
Set 1
Set 2
(Total cost reduction of 5%)
(Travel cost reduction of 5%)
Road
Rail
Water
Road
Rail
Water
Road
-0.63
0.17
0.16
-0.44
0.12
0.06
Rail
1.75
-1.56
1.54
1.35
-1.22
0.76
Water
2.64
0.82
-2.94
1.75
0.67
-1.42
Road
-1.28
0.51
0.11
-1.03
0.46
0.05
Rail
1.24
-0.81
0.71
1.03
-0.72
0.53
Water
1.29
0.57
-2.16
0.94
0.46
-1.65
Figure 6: Model elasticities
A breakdown of the elasticities in Figure 6 by NSTR category yields elasticities as high as
10, and cross-elasticities as high as 6.5 or 10 between road and water.
Comment
Although the authors note that such high elasticities may be caused by absorption of small
goods flows into much larger goods flows, we feel that this reflects the AON character of the
decision process, and should therefore not be trusted. To us this "flip-flop" behaviour of the
models strongly suggests the use of RUM-based choice models.
3.5
Route-choice models
A rich literature exists on route-choice models, ranging from shortest-path algorithms to
implicit path enumeration combined with Logit modelling of route choice as proposed by
Dial (see [Sheffy]), to explicit route enumeration with Probit models.
In principle the idea of random utility maximisation can be applied to route choice, and a
utility can be assigned to a route. However, there is an important difference between routechoice and e.g. mode choice in that route-alternatives often overlap to a significant degree.
This means that the error terms of the alternatives are correlated, which is counter to the
hypothesis underlying e.g. the Logit model. The famous red bus - blue bus paradox is based
entirely on violation of the assumption of independent error terms in the Logit model. Any
usable route-choice model must therefore deal with route overlap.
In [Yai et al. (1997)] a probit model is proposed for route choice. The computational
complexity is curbed by restricting the structure of the covariance matrix, and credible
estimation result are reported. The model was estimated using the GAUSS package. The
advantage of the probit model is the ability to deal with route overlap in a natural way.
In [Cascetta, E., et al. (1996)] a correction is proposed to the Standard logit model to account
for route overlap. The revised model is known as the C-logit model.
Where the ordinary logit model calculates the choice probabilities as:
pn(j\r)=
expH
Z*1
(7)
hel"
14
Specification of the ship type and route choice model VO.5
21-03-01 10:36
where:
j
:
an altemative
/"
:
the choice set for individual n
V"
:
the utility of altemative j for individual n
the C-logit model calculates the probabilities as:
/
x
explv," - P0CF]
hel"
with:
Po
:
the weight coëfficiënt of the route overlap
CFj
:
the "commonality factor" of altemative j
(9)
jzir{iLhLj
t
with:
Lhj
:
the length that links h and j have in common
fl
:
a parameter
Lh and Ly the lengths of links h and j respectively.
3.6
Mode choice models
The mode choice models found in the literature are sometimes LP models, but mostly
Random Utility Maximisation (RUM) models, sometimes of the Probit type but mostly of
the Logit type.
3.6.1 Cost variables
In [Bolis and Maggi (1999)], the following variables are identified as significant in the mode
choice: cost, time, reliability, frequency, notice time, use of road, use of combined transport.
It is noted that both the seize and the statistical significance of the parameters vary strongly
by goods type.
In [Nuzzolo and Russo (1998)] we find a model specification for a logit model with
coëfficiënt estimates for mode-choice of freight transport through Italy. Available modes
were: lorry, rail, and combined lorry/rail.
The shipment characteristics are:
qm
= weight of shipment for mode m [tonnes]
v
= value of shipment [Lit. 1000]
P
=perishable goods (0/1)
The characteristics of the shipping firm were:
Q
= annual shipment size [tonnes]
The transport characteristics are:
15
Specification of the ship type and route choice model VO.5
m
21-03-01 10:36
= travel time by mode m [Hr]
c
m
traV
= travel cost [Lit. * 1000 ] by mode m
m
Pioss = percentage of loss and damage for mode m
The explanatory variables in the model are:
In-transit capital cost: C™_„ = —— Qv
365
Transport charges:
C irm
-
m SeL
tr
lm
C
Loss and damage cost: Closs = p™ssQv
Inventory cost:
C"v = - ^
Name
Train
Combined
Road by own lorry (light)
Road (light)
f* ffl
In-transit capital cost *~C_tr
Unit
0/1
0/1
0/1
0/1
Lit.. 1000
Full model
Value
-1.969
-1.044
4.159
4.159
-0.095
t-ratio
2.4
1.5
4
4
0.7
Reduced model
Value
t-ratio
-2.535
3.8
-1.751
3.2
4.4
3.609
3.609
4.4
-0.025
0.4
-0.033
Transport charges
s^m
^tr
Lit. . 1000
-0.037
1.5
Loss and damage cost
Closs
Lit.. 1000
Lit. . 1000
-0.45E-4
1.1
-0.21E-4
1.2
0/1
0/1
1.559
0.73
96
0.76
1.4
0.5
s~>m
Inventory cost
*-- inv
Perishable and Consumer goods (road)
Own rail siding (train)
N observations
1.3
96
0.74
Figure 7 : Model estimation results
As is shown in Figure 7, two models were estimated: a full model and a reduced model. This
was done to reduce the amount of data needed in model application. Both models show a
good fit, and the explanatory value of the reduced model is only slightly less than that of the
full model. The dummy variables seem large and significant, but a real comparison is
difficult without knowing size of the explanatory variables. The two major cost components
are seen to be transport charges and in-transit capital cost.
In [Kantoor Binnenvaart (2000)] a program to calculate the cost price of a transport is made
available for public download.
Although the authors emphasise that the cost model used in the program is a simple one, the
model includes such variables as depreciation, wages, insurance, fuel cost, maintenance, port
dues, provision to the shipping office, and interest on outstanding debts. The authors note
that the resulting freight tariffs are the minimum freight costs required for break-even
operation of a ship.
16
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Judging from the program input and output, the following cost model is used:
f-cosïprice
>P
\r days ^for _ trip
fixed P
*,Y_sailing_days
_ ^ variable . f-*Y _
~
}P
v
/ 1 Q\
^
'
where:
QWitpnce
. t ^ e CQSt p r j c e Qf a fj-gjght trip along route p with ship type y
C*uabU
.t
C\-flxed
: the fixed cost
Ndays_ for_,rip
.t
NY_Sailing_days
.^
h ev a n a b l e
h en u m b e r
n u m b e r
CQSt
Qf d a y s
Qf s a i
t h a t
ling
t h et r
d a y s
jp
t a k e s
p e r y e a r
The variable cost is calculated as:
f^svtiable
_ <— provision
, f fuel
,(-•»>'
, s~*pnn_dues
, siother
/i i\
where:
c pwvision
. ^ p r o v i s i o n p a id t o the shipping office
Cfud
: the fuel cost
Coil
: the cost of lubricants
£port_dues
. p Q r t c j u e s ^ ^ charges for stopovers in outside the ports
C"h"
: any other variable costs
The fixed costs are calculated as:
s-*Y_fixed
_ ^depreciation
, ^interest
, pinsurance
, s~*ma'm\enance , f^wuges
where:
^depreaation
. y e a r i y depreciation on the ship and the motor
gmterest
. j n t e r e s t payments on the ship mortgage
cU»»rance
.^
cmamenance
.
Cwag"
: wage cost
Cmsc
: miscellaneous costs
i n s u r a n c e
y e a f l y
, s^misc
('19')
c o s t
m a i n t e n a n c e
c o s t
For the yearly depreciation the authors propose the following:
f-iinsured
s-iinsured
*-*
^depreciation
/ 1 ON
20 years
where
cinSured
.±
Q i n s u r e d
v a l u e
To calculate the wage cost, the authors propose the following:
Category
Function
Symbol
Yearly wages
17
Specification of the ship type and route choice model VO.5
1
Ship's captain
/o
80,000
2
Skipper
ƒ.
60,000
3
First mate
fi
50,000
4
Able seaman
f3
40,000
5
Ordinary seaman
U
18,000
21-03-01 10:36
Figure 8 : Yearly Standard wages
The total wage cost is the number of personnel times their yearly wages:
(14)
where:
: the number of persons on board in category i
The authors note however that as most ships are run as a family business the ship's captain is
also an entrepreneur who sets his own salary, and whose salary is therefore is not protected.
There is reason to believe that the yearly wages shown in Figure 8 are on the high side. On
the other hand, yearly wages for hired help are determined through a collective labour
agreement, and are probably not subject to reduction (even though the hours worked almost
certainly exceed those of the collective labour agreement).
3.6.2 Link cost modelling and model type appropriate to market
In [Ieda et al. (1999)] traffic route choice and ship size choice are modelled as a traffic
assignment model that results when a fixed O/D matrix of goods is shipped between ports
using a variety of ship sizes and fleet owners.
In the network a distinction is made between cruise links, loading links, unloading links,
arrival links, passing links, and transhipment links. The link cost of cruise links decreases
with the flow (due to economies of scale). The link cost of arrival links increases with
increasing flow due congestion in port, and a competition for berths.
One of the most interesting aspects of this study is that it distinguishes between three types
of transport markets:
•
a market with total competition, in which the shippers of individual shipments are free to
pursue a User Optimum,
•
a totally controlled market in which a system optimum is pursued,
•
a market in which several fleet owners independently pursue a system optimum for their
own fleet.
One of the findings of this study is that the third market model best fits the observed traffic
pattems.
The shipping type model is cast as an assignment problem. A link a is defined as a cruise
from origin port r and destination port s with vessel type k, and shipping company n. Link
costs Cak are split into cruising costs Clak, arrival costs C2ak, and loading, unloading,
transhipment, and passing link costs C3ak.
Cak=CUk+C2ak+C3ak
(15)
18
Specification of the ship type and route choice model VO.5
21-03-01 10:36
The link cost functions are specified as follows:
Pure transport costs
_au+aik
r
"-la*
~
v
fa-caPk
{
2qak
(16)
with:
annual flow on cruising link a
distance between port r and s
la
V
=
speed of vessels (no difference between ship sizes)
loading capacity of vessel-size category k
capk
=
load factor on link a
fa
time period (i year = 8760 hrs)
T
v
value of time for container transport
,
unit operation cost of vessel size k
"ik
a
unit cost of vessel size k
ik
£>,, b 2 =
model parameters
Port charges and waiting time
lak
J pik
_
C, =
• + v,w„
24
(17)
faCaPk
with:
f prk
port charge at port r for vessel size k
W
expectation of waiting time for mooring on link a
hr
operating hours of port r
a
\*4
^ nbmk
w —
'i
if
3
n
b2k
blk
)
'2
<
n
(18)
*anc 2-1'm
if
r2
>
n
/ , nbmk
bik
n
b2k
4
. ',=£%f capj
'.-1
T^f capJ
°ak
lak
(19)
a
a
Loading and unloading costs
C
3a=df,i
+V,tanc
with:
ƒ//
d
load or unload charge for per TEU at port i
dummy variable (0 for passing links, 1 for loading and unloading links, 2 for
trans-shipment links)
19
Specification of the ship type and route choice model VO.5
3.7
21-03-01 10:36
Combined route and ship type choice models
In a combined choice model for route and ship type, we have a two-dimensional choice set.
In [Ben-Akiva and Lerman (1985)] approaches are given for dealing with this situation,
illustrated for the case of joint choice of destination and mode.
In the event that the utility components related to the dimensions "mode" and "destination"
of the choice set share observed attributes, the "joint Logit" model emerges. This holds for
the following structure of the utility function;
UJm=Vd+Vm+Vdm+Sdm
(20)
in which the error terms edm are assumed to be jointly i.i.d. Gumbel distributed.
The joint Logit model takes the form of a multinomial Logit model in which the systematic
part of the utility function consists of components related to mode, to destination, and to the
combination of both:
^^^
d
dm
m
In the event that the utility components of mode and destination share unobserved attributes,
the utility function has the following structure:
Vdm =Vd +Vm +Vdm +£d +£m+edm
where the error terms £d,£m,£dm
(22)
are assumed to be i.i.d. Gumbel distributed.
In this case we have:
COV(Udm, Udm.) = COvfo + £m + £dm , £d + £m. + £dm.)
= cov(em,em.)
because of the assumption of independence of the error terms £d,£m,£dm •
In the same way we have:
cov(Udm,Ud>J = cov{£d,£d,)
(23)
Taken together, this means that the Utilities of the alternatives in the joint choice set cannot
be independent, thereby violating the fundamental hypothesis underlying the logit model.
If we the contributions of the error terms £d, £m are not negligible, a new form of Logit
model emerges: Nested Logit.
The most general form of dealing with this problem is to use a Probit model instead of a
Logit model, which unfortunately has its own drawbacks.
3.8
Discussion of the literature survey
In this section we will discuss the models reviewed above with a view towards their use in
the BVMS.
3.8.1 Model scope
Models that describe the interaction between shippers and carriers were found to be
redundant because of observations in [de Wit and Van Gent (1996)] on the market situation,
20
Specification of the ship type and route choice model VO.5
21-03-01 10:36
which was confirmed by NEA. The essence is that in the inland shipping market in The
Netherlands, carriers live in perfect competition, lack any real bargaining power, and fleet
size generally exceeds demand levels due in part to foreign-flag carriers. For this reason it
was feit that the model structure proposed in [Khoshyaran (2000)] should be reviewed, as
there is no point in modelling the carriers as independent market parties.
Little is known about the inventory strategy of the receivers of goods. Implicit in the project
is the assumption that inventory strategies are homogenous within the same goods type, so
that the frequency of shipments can be determined from empirical evidence.
As our model only deals with inland shipping, the shipper has already selected shipping as
the main mode. This implies that all goods are suitable for shipping. Unfortunately there is
some uncertainty regarding the sensitivity or the stability of shipment sizes (and its influence
on mode choice), and client-supplier relationships.
In the context of the BVMS, the long-term decisions of the shippers and receivers that
determine structure of the economie interaction (location choice, plant size, and choice of
supplier) are implied by exogenous input. This input consists of the freight matrices
produced by the TEM (Transport Economisch Model) from NEA.
In the BVMS, the only two endogenous decisions are shipment size and choice of mode (in
our case ship type). Although [Roberts et al. (1977)] argue that shipment size and mode
choice are simultaneous decisions, the BVMS will model these choices separately. Ship type
choice is treated extensively, but shipment size will be modelled simply by random draws
from the shipment size distribution. At the moment no information is available about
shipment sizes, but the characteristics of various ship types such as speed and reliability are
expected to be comparable, and characteristics such as lead-time may be comparable.
Therefore it is expected that: shipment-size differences will be much smaller than shipment
size differences across different modes, and more due to logistics considerations that to
transportation considerations. In other words: shipment size differences are not expected to
correlate strongly with endogenous variables, and can therefore be modelled only on basis of
previously observed shipment sizes.
3.8.2 LP-based models and AON models
For LP-based models and models based on All-Or-Nothing assignment we can point to
[Khoshyaran (2000)], and [Jourquin et al. (1999)].
In [Khoshyaran (2000)] the use of LP models and model issues are proposed, of which we
will only discuss the ones linked to ship choice and route choice.
The study proposes an LP approach to the issue of modelling the selection of ship types and
to route choice: ship type selection and route choice are modelled as a simultaneous leastcost solution to a linear cost function with linear constraints for the entire network. In other
words a system optimum is sought.
The advantages of this approach are
•
it is a clear and consistent approach with a clear theoretical interpretation
•
Standard LP solvers are available that can efficiently to handle actual optimisation of
large-size problems
•
the LP models per se involve no calibration
•
the modelling approach transcends the traditional 4-step approach by linking several
levels of choice
However, there are some disadvantages to this approach:
21
Specification of the ship type and route choice model VO.5 21-03-01 10:36
•
there is no allowance for any deviation from the optimal choice as represented by the
objective function: as the model is formulated all, decision makers are assumed to
always take the system-optimal least-cost solution
•
the solution is determined by two elements: the objective function and the constraints,
for which the above approach provides no viable calibration procedure
•
the constraints (e.g. fleet size) are generally unknown for forecast years
•
the solution may change discontinuously when the constraints or the objective function
are changed so that the elasticities cannot reliably be predicted in advance, and
instability in the feedback between route choice and assignment might occur
•
there seems to be no advantage in trying to model the entire decision chain (O/D pattern,
ship choice, route choice) in one go when at the same time the intermediate results are
linked to empirical data through IPF procedures. In fact, the trade-off between improved
consistency compared to the 4-step method versus the much tighter coupling in the
model coupling in model and the possibility of discontinuous response from the model
system seems questionable.
These points will be elaborated below.
Although the market parties are economie entities, so that the assumption of user-optimality
may be warranted, there is no guarantee that any system-wide cost-function proposed
accurately reflects the real "utility" on basis of which decisions are taken. This would not be
a problem, if some flexibility could be built in regarding e.g. mis-specification, perception
errors, unmodelled decision factors etc. However the LP formulation implicitly assumes that
in the global objective function will be minimised exactly. This is might not be realistic.
The precise form of the objective function is open to some debate. The main reason is that
the value of time of various shipments may vary widely, and with it the optimal trade-off
between cost and time. It is to be expected.that the cost function will different by goods
category, and should in some way be calibrated from empirical data. Calibration of costfunctions in LP problems is a difficult undertaking because the calibrated model should
represent both the current state and have the right elasticities. The elasticities derived directly
from the solution of an LP problem are misleading because they hold only up to the next
vertex. On the other hand, disaggregate data on actual mode choice is available through the
IVS dataset, so that it should be possible to estimate disaggregate choice models per goods
type for the mode choice.
For future years fleet-size constraints are either unknown or absent. Therefore it is desirable
to have a model that can handle constraints in a flexible way.
The reason that the solution to an LP program can change discontinuously with small
changes in the constraints or the objective function is that any LP program attains its
optimum in a vertex of a convex cone of linear constraints. Changing the constraints will
change the locations of the vertices may cause the optimum to He in a different vertex. There
is in general no guarantee that a small change in the constraints or the objective function will
lead to small changes in the location of the optimum vertex.
The trade-off between improved consistency compared to the 4-step model is diluted by the
way in which the intermediary model results are linked to aggregate data through IPF
models. Although this linkage is quite desirable in that it ensures that the model firmly stays
in contact with reality (and that units of measurement are consistent with empirical
observations), it counteracts the advantages that might arise from having an integrated model
system. Also the possibility of discontinuous response from the model system that the LPbased model entails seems questionable.
Jourquin et al.
22
Specification of the ship type and route choice model VO.5
21-03-01 10:36
In [Jourquin et al. (1999)] we see a demonstration of a model in which mode, vehicle type,
and route are modelled simultaneously through least-cost path search. We note that after
calibration the mode is capable of reproducing the observed mode split, and that the
aggregate Utilities reported seem reasonable. However, we also note the "flip-flop"
behaviour endemic to all AON assignments. Such behaviour in the BVMS would be
unfortunate for several reasons:
•
the high elasticities are unlikely to be correct
•
an AON model cannot adapt to the observations in the way a RUM-based model can
•
an AON-based ship type choice model will almost certainly get the distribution across
vehicle types wrong at link level
Random utility models
Many of the above disadvantages can be avoided by using discrete-choice models based on
Random Utility Maximisation (RUM) theory (see [Ben-Akiva and Lerman (1985)] for
further information).
In the course of the calibration of the discrete choice models, the precise form of the utility
function on basis of which the shippers are assumed to choose will become apparent. In the
same way, the scale of the estimated model will clarify precisely to what extent the estimated
utility function really explains the choice behaviour, and give an indication of the magnitude
of the error terms in the random utility model. Because of this proviso, the model will be
able to function with an incomplete specification of the cost function. In this case there will
be a loss of accuracy, but the specification error will only result in an increase of the error
term of the model; so that the model as such will function to the maximum extent possible by
reducing the explanatory utility function. A drawback of the RUM models at this point is
that need to incorporate fleet-size constraints through a feedback loop.
3.8.3 Combined mode-choice and shipment type models
First of all we will tum to the pragmatic model by [Jourquin et al. (1999)]. The model
illustrates that it is possible to do a nice job using all-or-nothing assignment provided that the
networks costs are detailed. Unfortunately the aggregate model results (see Figure 6) show
considerable variation as one disaggregates by NSTR goods category: a breakdown of the
elasticities in Figure 6 by NSTR category yields elasticities as high as 10, and crosselasticities as high as 6.5 or 10 between road and water. Although the authors are careful to
note that such elasticities may be caused by absorption of small goods flows into much larger
goods flows, we feel that this also reflects the AON character of the decision process, and
should therefore be viewed with some reservations.
This behaviour of the models strongly suggests to us the use of RUM-based choice models
instead of AON-based models. If on the other hand the decision process truly has an AON
character, this will be made manifest in the calibration of the corresponding RUM models.
The structure of the BVMS calls for combined mode and ship type choice. The combined
mode-choice and shipment-size model described in §3.4 is attractive in a theoretical sense
because it links shipment size and mode (read ship type) choice.
The model as it stands however does not seem to be easily applicable in the BVMS context.
The reason is that the ship type choice model in general has more than 2 altematives, which
immediately leads to 3-dimensional Probit models (the estimation of which is still not quite a
"standard procedure"). Also the number altematives (ship types) varies with the water depth
in the network; in the absence of the IIA property with Probit models we are not completely
confident that (1) one calibration would be sufficient and (2) that a mixed calibration
23
Specification of the ship type and route choice model VO.5
21-03-01 10:36
(including high-water and low-water situations) would be the correct procedure. This could
be approached by estimating a number of choice models, but this would lead to an extra layer
of complexity, both in model estimation and in model implementation.
It would be possible to experiment with logit models for ship type choice linked to linear
models for shipment size, but this would have more of a research nature than a model
implementation nature.
In summary, the only model component which can be readily adapted to the BVMS situation
is the simple idea of estimating shipment size through linear models. Unfortunately
regression models as used in [Abdelwahab, W. et al. (1992)] may be inappropriate because
the sender knows that the shipment will be sent by water, and may match the size of the
shipment to the capacity of the ship that he in mind. For this reason discrete linear models
are proposed.
3.8.4 Route choice models
Route-choice modelling using RUM models is different from e.g. mode choice modelling in
that the Utilities of route altematives are correlated when route overlap occurs (as is usually
the case).
To illustrate the problem, consider a network with three routes from A to B. Routes (I) and
(II) overlap for 95% of their length, and route (III) does not overlap with either route (I) or
route (II). If all three routes have exactly the same characteristics, in reality the choice
probability for route (III) would be about 50%, and for routes (I) and (II) about 25% each. A
logit model however will assign a choice probability of 33% to each route.
This problem is caused by the correlation between the error terms of the Utilities of routes (I)
and (II), which is counter to the hypotheses under which logit models are derived.
The question is whether this is a problem for the BVMS: at the moment no information is
available on the number of feasible routes between altematives or the amount of route
spreading. In the event that at most two feasible routes can be found per O/D pair, the MNL
Logit model can be used. Otherwise a correction is needed for route overlap.
A number of remedies have been found over the years. The most conceptually simple
remedy is to explicitly allow for correlation of the error terms in the utility of altematives
through the Probit model, which assumes a joint normal distribution of the error terms. This
approach has serious drawbacks however, both in estimation and in application.
Another approach is to modify the standard Logit model to enable it to function with
correlations in the error terms of the utility of altematives. The most simple modification is
the C-logit model, which explicitly treats route overlap. The advantage of this approach is
that once the overlap factors are known, the estimation and application can be carried out as
for the standard MNL Logit model.
3.8.5 Combined route-choice and ship type choice models
In a combined choice model for route and ship type, we have a two-dimensional choice set.
With respect to route choice, we noted in §3.8.4 that a correction is needed due to the
correlation between overlapping routes. If we are prepared to believe that the error terms of
the utility components due to ship type are negligible, we can use the C-logit model to
represent choice behaviour.
For practical reasons we propose to assume that this is the case, and to use the C-logit model.
Should it tum out later that these assumptions cause serious inaccuracies, additional research
will be needed to determine which form of choice model is more suited to the correlation of
the error terms, e.g. by trying a suitable nesting structure. We note however, that
24
Specification of the ship type and route choice model VO.5
21-03-01 10:36
identification, estimation, and use of such a model is more complicated than that of the
standard MNL model.
3.8.6 Model form and explanatory factors for ship choice modelling
In this section we will look in some detail at the model form used for ship choice modelling.
Of the transport-related factors identified in [Bolis and Maggi (1999)], time and cost are
included in the model. Use of road is included implicitly, but has a value of 0. As it is
assumed that reliability shows only minor variations across ship types it is omitted from the
model. In [Nuzzolo and Russo (1998)], the cost components comprise both transport charges
and the cost of capital tied up during transport. There is a strong possibility that in view of
the slowness of shipping mode, the value of all cargoes sent by ship on inland waterways are
so low that inventory cost plays no role. In any event, capital cost increases linearly with
travel time.
The logistics-related variables such as frequency, and notice time should not be dismissed
without first looking at the data. For this reason the model specification will include them,
but they may be dropped in the course of the model calibration.
In [Ieda et al. (1999)] two important topics are treated: in the first place additional cost
components are specified for loading and unloading of ships, waiting time before berths.
Cost factor calculation
In our view, the comments put forward underline the need to do model the ship type choice
using disaggregate cost components, rather than imply the absence of a relationship between
the cost perceived by the ship's operator and the cost perceived by the shipper.
Although there is ample evidence that individual ship-owners/operators are often forced to
offer their services at or below cost, there will still be a relationship between cost perceived
by the ship's operator and cost perceived by the shipper. If only because ship-owners have a
certain minimum cost, and cannot subsidise their operations indefinitely or to an unlimited
extent. Those that attempt this will, in the long run, go bankrupt and disappear from the
market. As the BVMS is a strategie model there is some justification in assuming a direct
relationship between the minimum cost that will cover expenses and the freight price.
Although the example provided by "Varende berichtgeving" is not, in itself of statistical
significance we are willing to accept it as an indication. This does not detract from the fact
that on average and in the long run, transportation costs in the market should be expected to
be above a certain minimum cost level. A statistical analysis of the database produced by
"Varende berichtgeving" would be required to determine if and to what extent such
occurrences are the norm.
The cost price of transport however is amenable to modelling; an example of (approximate)
minimum cost calculations can be found in [De Vries (2000)].
For this reason we expect a relationship between the cost perceived by the shipper and the
ship's operator. The difficulties then revolve around the precise nature of this relationship
and how to best model it. Even if (as we have been led to expect) freight charges regularly
fail to cover the operating cost (so that ship operators are forced to eat into their capital),
there should on average still be a relationship between cost price and freight charge. Such a
relationship can be investigated during the calibration.
Ship type choice
The argument that ship type choice is not related to operating cost may have merit in that the
shipping office selects which ship to contact to bid. However, the shipping office will be
aware of the price structure of all relevant ships, and will choose accordingly.
25
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Even if individual shippers are to bid on publicly announced transports, we hypothesise that
the probability that they will be less likely to bid on assignments in which they are
guaranteed to incur a loss.
In the absence of factual information or previous research, we feel that we should maintain
the proposed model structure and attempt to identify the relationships during the calibration.
3.8.7 Model elasticities
In this section we will report some discussions found in the literature conceming the issue of
model elasticities in the BVMS, focussing on their relationship with the specification of the
ship type choice model.
One of the most important uses of transportation models is to predict the effect of extemal
factors, notably price changes. Sensitivity of changes e.g. in demand for y due to changes in
price p are usually expressed as the (dimensionless) elasticity:
<y) = JLÊL„£±.
y dp
(24)
y Ap
Of the BVMS models those that are sensitive to price changes independently of the TEM, are
the ship type choice model, the route choice model, and perhaps the shipment size model and
the empty trip model.
The ship type choice model to be specified in the next chapter will be basically a
disaggregate discrete choice model based on random utility maximisation. As such it
specifies elasticities w.r.t. changes on policy variables, notably travel time and price. What,
according to the literature, can we expect of these elasticities and what are the factors
affecting these?
A survey of various price elasticities in transport demand is given in [Oum et al. (1992)] and
[Goodwin (1992)], which is commented on by [Dargay (1993)]. In summary these articles
contend the following:
•
•
•
•
•
•
Correct estimation of demand elasticities must take account of intermodal competition
Different functional forms of demand models often lead to different elasticities on the
same data, so care is needed in selecting the model form
There are time and space effects: long-run elasticities are higher than short-run
elasticities, and elasticities vary from country to country and from market to market
Aggregate elasticities are always lower than disaggregate elasticities because high and
low elasticities "average out"
Elasticities are complicated by the interaction between supply and demand (see also the
difference between long-term and short-term choices in 3.1).
Elasticities with respect to price increase may be different from those for price decrease:
in other words a hysteresis effect may be present.
As noted, both mode-split and traffic demand in the BVMS are driven by the TEM models,
so that the TEM determines the type (aggregation level, long term / short term,
supply /demand interaction, whether for price increase or decrease etc.) of the elasticities of
destination split, mode share, goods volume, and their magnitude.
As the quantities modelled by the BVMS (such as traffic volume and ship type use) are
derivatives of the transportation demand, the change in traffic load on specific links is
strongly dependent on changes in transportation demand, both in volume and in distribution.
26
Specification of the ship type and route choice model VO.5
21-03-01 10:36
For this reason a major part of the elasticities of the BVMS are conditional on the input
provided by the TEM, and therefore share the characteristics of the TEM. No feedback is
currently envisaged between the BVMS and the TEM.
3.8.8 Modelling implications
A possible implication is that the way cost is calculated in §5.3.1 has little relationship with
the cost perceived by the shipper, and therefore does not have much explanatory power in
the ship type choice.
If true, this would mean that:
•
the detailed ship choice required within the BVMS framework is essentially
unidentifiable, and
•
the estimated model will either be largely insensitive to cost factors, or have illogical
coefficients (e.g. a positive contribution to the utility function) and will therefore have to
be replaced by a model that is wholly insensitive to cost factors (and therefore to most
policy measures)
Examples of models that are insensitive to cost factors are: sampling from a frequency
distribution, and using a choice model which predicts constant market shares for the ship
types concemed as is the case in the present inland shipping models.
As we do not yet have direct statistical evidence that this is the case, for the moment we will
stand by the model specification in this report. We note that the model structure specified in
this document can, without modifications, deal with either cost-sensitive or cost-insensitive
relationships between ship type and operating cost as perceived by the ship's operator. The
only differences would be in the coefficients.
The model structure as proposed does have the advantage that if statistically significant
relationships exist between the operating cost and the cost perceived by the shipper, the
model is in a good position to incorporate such relationships. Our position is that in the
absence of real data, the calibration of the choice model is the place to determine the
existence or non-existence of such relationships.
In the mean time we can identify three possible courses of action:
1. wait for the estimation of the model coefficients (the model calibration) to confirm or
refute the hypothesis that the utility components are indeed those specified in §5.3, and
take appropriate action at that time.
2. investigate the statistical relationship between cost incurred by the ship and cost billed to
the shipper (e.g. using the , and the relationship between cost incurred by the ship and
ship type choice, e.g. by doing a variance analysis and estimating a linear regression
model for certain combinations of goods type and ship category
3. decouple the ship type choice model from the route choice model to allow for different
choice mechanisms in ship type selection and route choice selection
4. extend the model specification by having a nested structure: the top level nest for the
ship type choice, and the bottom level for route choice.
3.9
Summary
In view of the complexity of the integrated models described in the literature (bearing in
mind the constraints of the BVMS project), the adoption of models for combined mode- and
shipment size choice is unattractive.
27
Specification of the ship type and route choice model VO.5
21-03-01 10:36
On basis of a comparison between the LP-type models and Random Utility Maximisation
type models, it was decided to use the RUM models.
We note that for the Belgian freight transport network the use of all-or-nothing assignments
coupled to elaborate network modelling, and fairly detailed cost modelling led to a model
that successfully reproduces the ship type choice. We also note that the elasticities seem to
have the right order of magnitude, and reflect the importance of including handling costs.
For ship type choice there seems to be no reason not to use Logit models. Although both
Logit and Probit models seem viable for route choice, we hesitate to recommend the use of
Probit models because we feel that the estimation of Logit models is more a routine task than
that of Probit models. Logit type models have the advantage that they are seen to be more
robust with respect to irregularities in the data and can be calibrated using standard software.
In the absence of firm data on which to base the choice, the explanatory variables listed in
the literature were adopted for inclusion in the model specification.
28
Specification of the ship type and route choice model VO.5
4
21-03-01 10:36
Some characteristics of the system to be modelled
Having surveyed the models described in the literature in the previous sections, we now turn
towards a scan of the characteristics of the inland shipping system that is to be modelled. The
aim of this scan is to look for features in the inland navigation market that need to be
considered with the modelling approaches discussed above.
This survey had to be based on aggregate data as no disaggregate data was available.
Special attention was paid to the following points:
(1) the degree to which the models can reproduce the current market situation
(2) the nature of the relationship between cost incurred by a ship's operator, and cost
perceived by the shipper, and
(3) whether shipment size can be derived from the capacity of the available ships and
consignment size
4.1
Model/ing widely different markets
The inclusion of this paragraph was prompted by misperception among consortium members
regarding the nature of the models proposed, and especially the following points:
1. the use of a single model type (RUM-based models) to capture the essential behaviour of
widely different markets, and
2. the role of statistical analysis and parameter estimation in model development.
Quantitative models are always based on a statistical analysis of the available data. Since the
project calls for this specifications to be completed before any data was available, the
statistical analysis must be carried out after the model specification has been completed and
the data has been assembled.
As a consequence, a certain class of models will be selected for ship type choice (RUM
based models), for which parameters will have to be estimated on basis of available data.
This parameter estimation exercise will focus on fitting the choice models to the data, and in
this way capturing the behaviour of the markets. In the course of the parameter estimation,
additional, quantitative, information will become available about the quality of the fit
between the models and the data. This is a very valuable diagnostic, the more so since is one
of the few model components that can be calibrated in isolation (i.e. without depending too
much on results of other models).
The interaction between the various model components, notably making certain that the
modelled traffic flows match the observed flows in the base year is a different part of the
work, and is known as the model calibration.
As our working hypothesis is that the market structures will correlate with the goods group, a
complete model will be estimated for each of the goods groups used. Since we have noted
significant geographical differences in the goods stream (e.g. Rhine navigation to Germany
versus home navigation) the models will contain explicit variables to account for the
markets: Rhine navigation to Germany, North-South navigation.
Although we note that the parameter estimation is an essential phase in which the models
sketched above should be adapted to the situation at hand, this process is expected to lead to
relatively minor modifications in the structure of the software system needed to
operationalise the models.
29
Specification of the ship type and route choice model VO.5
4.2
21-03-01 10:36
Breakdown of goods streams
In order to get a feel for the expected weight of modelling by market segment, we present a
rough breakdown of the goods streams in 1996 based on data taken from [Min. Verkeer en
Waterstaat (1997)].
First of all, we note that the total goods flow (in Kilo-tonnes) can be broken down into:
Transit (47%), Inland shipping (34%), and import (19%).
Each of these segments can be broken down further by NSTR-0 goods category as shown in
Tablel,Table2,Table3.
Inland shipping by goods type [Kton] (1996)
Type
Metals + semimanufacture
Ores
Fertiliser
Agricultural
Chemicals
Coal
Other
Foodstuff
Oil + derivatives
Raw minerals + building materials
NSTR
N5
N4
N7
N0
N8
N2
N9
N1
N3
N6
Tonnage Percentage Cum %
650
1% 100%
1262
1%
99%
2%
98%
1655
2%
96%
2195
3%
93%
2534
91%
5%
4463
5%
86%
4551
11%
80%
9752
69%
16%
14478
53%
53%
46875
Table 1: Breakdown of inland goods flow by NSTR-0 category
From these tables it is clear that for inland shipping (at least with respect to the total tonnage
carried) the main goods groups are: NSTR 0: raw minerals and building materials, oil and oil
derivatives, and foodstuffs (including animal fodder), which together account for 80% of the
tonnage.
For transit shipping, oil and oil derivatives, raw minerals and building materials, and coal
account for 76% of the goods flow.
For imports the main goods groups are: raw minerals and building materials, miscellaneous
goods, chemicals, agricultural produce, and oil and oil derivatives account for 83% of the
goods flow.
Type
Transit shipping by goods type [Kton] (1996)
NSTR Tonnage Percentage Cum %
Agricultural
Metals + semimanufacture
Fertiliser
Chemicals
Foodstuff
Other
Coal
Raw minerals + building materials
Oil + derivatives
Ores
N0
N5
N7
N8
N1
N9
N2
N6
N3
N4
1325
1573
3217
6876
7262
8869
12991
16268
30502
33024
121907
1%
1%
3%
6%
6%
7%
11%
13%
25%
27%
100%
99%
98%
95%
89%
83%
76%
65%
52%
27%
Table 2: Breakdown of transit goods flow by NSTR-0 category (1996)
30
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Import by goods type [Kton] (1996)
NSTR Tonnage Percentage Cum %
Fertiliser
Coal
Ores
Metals + semimanufacture
Foodstuff
Oil + derivatives
Agricultural
Chemicals
Other
Raw minerals + building materials
N7
N2
N4
N5
N1
N3
NO
N8
N9
N6
730
851
1789
2057
2546
3916
4219
4463
5578
22030
48179
2%
2%
4%
4%
5%
8%
9%
9%
12%
46%
100%
98%
97%
93%
89%
83%
75%
67%
57%
46%
Table 3: Breakdown of goods flow (import) by NSTR-0 category (1996)
31
Specification of the ship type and route choice model VO.5 21-03-01 10:36
Shipping: inland, transit, import [Kton] (1996)
NSTR Tonnage Percentage C u m %
Type
I 5: Metals + semimanufacture
U 7: Fertiliser
U 2: Coal
I 4: Ores
L 0: Agricultural
L 5: Metals + semimanufacture
I 7: Fertiliser
U 4: Ores
U 5: Metals + semimanufacture
I 0: Agricultural
I 8: Chemicals
U 1 : Foodstuff
L 7: Fertiliser
U 3: Oil + derivatives
U 0: Agricultural
I 2: Coal
U 8: Chemicals
I 9: Other
U 9: Other
L 9: Other
L 1: Foodstuff
L 8: Chemicals
I 1: Foodstuff
L 2: Coal
I 3: Oil + derivatives
L 6: Raw minerals + building materials
U 6: Raw minerals + building materials
L 3: Oil + derivatives
L 4: Ores
I 6: Raw minerals + building materials
NI 5
NU 7
NU 2
NI 4
NL0
NL 5
NI 7
NU 4
NU 5
NI0
NI 8
NU 1
NL 7
NU 3
NU0
NI 2
NU 8
NI 9
NU 9
NL8
NL1
NI 9
NI 1
NL 2
NI 3
NL 6
NU 6
NL 3
NL 4
NI 6
650
730
851
1262
1325
1573
1655
1789
2057
2195
2534
2546
3217
3916
4219
4463
4463
4551
5578
6876
7262
8869
9752
12991
14478
16268
22030
30502
33024
46875
258501
0%
0%
0%
0%
1%
1%
1%
1%
1%
1%
1%
1%
1%
2%
2%
2%
2%
2%
2%
3%
3%
3%
4%
5%
6%
6%
9%
12%
13%
18%
100%
100%
99%
99%
99%
98%
98%
97%
96%
95%
95%
94%
93%
91%
90%
88%
86%
85%
83%
81%
78%
75%
72%
68%
63%
58%
51%
43%
31%
18%
Table 4: breakdown by goods type and O/D relationship (1996)
4.3
Modelling implications of peculiarities and market structure
In several discussions within the consortium, concern was expressed regarding the need for
special treatment of particular market segments.
On basis of their share of the amount of goods shipped and / or their expected deviation from
"normal" market conditions or other modelling difficulties, the following aspects and
markets have been highlighted for attention:
•
Ability to sustain losses
•
Container transport
•
Sand and gravel transport
•
Rhine versus non-Rhine navigation
•
North-South trade (Belgium and France)
•
Load factors
32
Specification of the ship type and route choice model VO.5
21-03-01 10:36
4.3.1 Ability to sustain losses and the market mechanism
As noted in [de Wit et al. (1996)], the inland shipping market suffers from structural overcapacity, which has a strong downward effect on freight prices. This situation has endured
quite a long time without a new market equilibrium setting in.
The authors of [de Wit et al. (1996)] explain this as follows: the relative size of the cost
components differ by ship size, as shown in Figure 9.
Cost components by ship size
<n
a>
o
Q.
E
o
o
«•*
(0
o
o
"o
'35
Ijo
a>
CC
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
Sfuel
D other
EJ kapital
D wages
350
600
1200
1600
2500
Ship size [tonnes]
Figure 9: Cost components by ship-size
Given that the smallest ships are most often privately owned and operated, such owneroperators live on their ships, often have low capital costs, set their own salary and can
therefore decide to reduce or forego that salary. This is not feasible with employed personnel,
so that private owner/operators of small ships can sustain themselves for long periods below
ordinary cost levels.
Negative supply curves
A further peculiarity of the transport market that is noted in [de Wit et al. (1996)], are the
negative supply curves. Shipowner-operators, having a one-man business, are dependent on
their shipping activities for their income. If freight prices drop, he will be forced to work
longer hours to make up for the loss in income. This results in the counterintuitive
phenomenon that individual owner-operators tend work longer hours when tariffs are low.
Example
An example provided by NEA's "varende berichtgeving" shows a boat trip from Rotterdam
to Hamburg which had to wait 5.5 days in Hamburg before unloading, and receiving a
compensation for the idle time far less than the charge for sailing days.
The cost for waiting is lower than the sailing cost, but was not known to the shipper
beforehand. For this reason, the unloading cost component should not have influenced the
ship type decision. The example also shows that the wage for this particular ship's crew is
extremely low (below the minimum wage), and does not seem to be in line with the way in
which it is calculated in §5.3.1.
It was argued that individual ship-owners are invited to bid for shipping consignments
instead of there being a fixed price structure. Furthermore it was noted that in many cases we
33
Specification of the ship type and route choice model VO.5
21-03-01 10:36
are dealing with owner-operators who own a single ship and live on it. If the mortgage on
their ships has been paid off, and the ship has been written off, such operators are able to
offer extremely low charges.
Modelling implications
The above gives rise to some concerns regarding the relationship between the cost price and
freight price that emerges from the negotiation between the skipper and the shipper (shipping
office or direct contact). As a result, the peculiarities noted here have led to some scepticism
as to whether transport costs will seriously affect ship type choice.
It is possible that the way cost is calculated in §5.3.1 is higher than the cost perceived by the
shipper for extensive periods of time. Therefore its explanatory power in the ship type choice
is not self-explanatory.
As we do not yet have direct statistical evidence on the explanatory power of the cost price
in ship type selection, we will stand by the hypothesis that in the long run cost price is a
significant explanatory variable for ship type choice.
We will specify a model structure that can, without modifications, deal with either costsensitive or cost-insensitive relationships between ship type and operating cost as perceived
by the ship's operator. The only differences would be in the coefficients.
The model structure as proposed has the merit that if statistically significant relationships
exist between the operating cost and the cost perceived by the shipper, the model is in a good
position to incorporate such relationships. Our position is that in the absence of real data, the
calibration of the choice model is the place to determine the existence or non-existence of
such relationships.
We therefore propose to
1. wait for the estimation of the model coefficients (the model calibration) to confirm or
refute the hypothesis that the utility components are indeed those specified in §5.3, and
take appropriate action at that time.
2. decouple the ship type choice model from the route choice model to allow for different
choice mechanisms in ship type selection and route choice selection
4.3.2 Containers
The container transport market is reported to have several characteristics which complicate
modelling:
•
Container transport has grown sharply in the past 5 years, and is a now very lively
market, both in terms of growth and in terms of volatility of origins and destinations.
•
By consequence the structure of the container demand is not well represented in the
base-year of 1992, and at the current pace of growth will be difficult to predict. In any
event, the matrices provided by the TEM might not provide sufficient basis on which to
base predictions.
•
The demand pattern as specified by the O/D table is likely to change significantly, both
in volume and in distribution if major shippers decide to use shipping-based transport
(e.g. Heineken).
•
New container terminals are reported to appear frequently, and existing container
terminals are reported to fall into disuse if insufficient demand materialises
The rapid growth of containerised transport, and the deficiënt representation of container
transport in the base year makes it difficult for the current model structure (a pivot-point
model) to capture this growth from base year to forecast year. The reason is that growth
34
Specification of the ship type and route choice model VO.5
21-03-01 10:36
factors become very large, and many relationships currently exist which are not represented
in the base year (1992) matrix.
The fact that individual containers represent only a small fraction of the amount of goods
carried in a container ship makes that in container transport many O/D relationships tend to
be bundled. This bundling has consequences for transport in that container ships must (like
public transport services) visit a number of ports at which they load and unload containers,
so that individual containers are not necessarily transported via the shortest or fastest route.
This is counter to the structure of the assignment model (which searches for the least-cost
route between origin and destination).
4.3.3 Sand and gravel
The O/D pattern of sand and gravel shipments are reported to be highly sensitive to the
changes in location of sandpits, and the location of major infrastructural projects, both of
which are subject to change. The total volume shipped however is considerable.
4.3.4 Navigation on the Rhine
Navigation on the Rhine is characterised by the following:
•
Free competition
•
Large goods flows
• Inland navigation of all classes can use the Rhine
Especially the fact that the goods flows between Rotterdam and the German hinterland are
quite large compared to other goods flows means that both the shipment and consignment
sizes are larger than on other relationships. This means that navigation on the Rhine should
be modelled independently..
4.3.5 North-South navigation
A large part of the North-South navigation seems to be between Rotterdam and Antwerp. As
with the Rhine navigation, it seems best to model this relationship separately from other
relationships.
A special segment of North-South navigation consists of inland shipping between The
Netherlands and Belgium or France. Due to the size of the canals in France and Belgium,
only small ships (category I: 250 - 400 tonnes) can navigate there. This needs to be taken
into account in the network (and the resulting L.O.S. data), to prevent a mismatch between
models and reality.
4.3.6 Load factors
Shown in Table 5 is a breakdown of trips, shipments and transported load by vehicle
category based on data taken from [CBS (1996)]. The average number of shipments per trip
was obtained by dividing the number of shipments by the number of trips. The average
triplength is estimated by dividing the number of ton-kilometres by the transported load.
Dividing the transported load by the number of vessel kilometres gives an estimate of the
average shipment size. Finally an estimate of the average load factor is obtained by dividing
the average shipment size by the mean of the load capacity bins
35
Specification of the ship type and route choice model VO.5 21-03-01 10:36
We see that the number of shipments per trip is larger than 1, could mean that multiple
shipments are carried together on the same trip.
Quantity
Unit
Trips
Shipments
Vessel km
Load capcity
Load tonkm
Transported load
Load tonkm
[1000 km]
[tonnes* 1000]
[min km]
[tonnes * 1000]
[min tonkm]
Total
137153
206548
9612
130270
9086
88416
6846
21-250
8731
12090
389
1371
60
882
44
250-400
16972
22767
1038
5250
328
3163
221
Shipments/trip
Triplength
[km]
Shipment size [tonnes* 1000]
Load factor
[%]
1.5
77
712
72%
1.4
50
113
57%
1.3
70
213
66%
Tonnage class
400-650
650-1000 1000-1500 1500-3000
17938
29346
29213
32139
47160
48898
43298
27951
1724
1334
2652
2266
15426
24182
38425
35918
1394
1863
2123
2613
13270
22429
18140
23082
1215
1693
1543
1676
1.6
92
458
87%
1.7
75
747
91%
1.3
85
895
72%
1.6
73
1256
56%
Table 5 : Shipping characteristics (1996), data taken from CBS (1996).
Although these statistics are clearly at a very aggregate level, so that no definitive
conclusions should be drawn, the table suggests a number of interesting working hypotheses.
In particular seasonal effects are hidden.
First of all, the average number of shipments per trip seems to be about 1.5. This would
mean that that generating a separate trip for every shipment, will cause traffic volumes to be
over-estimated by 50%.
Secondly, On basis of the load factors shown in Table 5, the average load factor seems to be
about 72%, implying that a model that distributes consignments over ships while loading
them to 100% is unlikely to be correct.
In principle neither of these effects should lead to problems because they will be present in
both the base year and the forecast year, and should therefore cancel out when growth factors
are calculated.
36
3000+
2814
4384
209
9698
705
7450
454
1.6
61
2172
72%
Specification of the ship type and route choice model VO.5 21-03-01 10:36
4.4
Modelling route choice
Conceming route choice, the opinion was voiced that realistic route choice possibilities are
negligible given the tree-like structure of the inland waterways network, and should therefore
not be modelled. There is e.g. only one Rhine, and all inland navigation between Rotterdam
and Germany (the largest relationship by far) must use it. Some route choice is possible (e.g.
via the Lek of via the Waal), but that is limited.
mêêmm»
Figure 10: European waterway network (reproduced from www.inlandshipping.com)
The main inland waterways of The Netherlands are shown in Figure 11. The sparsity of the
main waterways network (and the resulting scarcity of route choice) are clearly visible.
Nevertheless, a certain amount of route choice is present, notably in the area just east of
Rotterdam. Route altematives between Rotterdam and Germany are admittedly scarce, but
on other relationships, viable route altematives may exist.
In principle there is always the trade-off between the quickest and the shortest route. The
role of the BVMS as a strategie traffic model means that it should offer at least the
possibility of evaluating the effect of policy measures on traffic load through re-routing. If no
trade-off between time and distance exists, this will become evident during the calibration.
For this purpose, route costs will be calculated per ship type for the best route available to a
particular ship type. In this way the level of accessibility of destinations to ship types is
accounted for in the ship type choice models.
Where route choice does occur, the match between counts and modelled flows will be
affected; correctly modelling the route choice should improve the calibration results.
37
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Vaarwegen,
Pf arr stird re prog ra mm a
Pknstudie
ffi
Verwegen
Stedelijke gebieden
Figure 11: Main waterways in The Netherlands (copied from [Min. V en W (1998)])
38
Specification of the ship type and route choice model VO.5
21-03-01 10:36
A further question is whether the availability of altemative routes should be allowed to
influence the ship type choice, thus necessitating an integrated choice between route and
ship type.
On balance we should not assume this to be the case, because:
•
Estimating a route choice model on basis of observed route choice behaviour needs a
database that contains the explanatory variables for both used and unused altematives.
Whilst the values of the explanatory variables of the chosen altematives can be derived
from IVS observations, the values for non-chosen altematives must be obtained in more
indirect ways, so that considerable effort will be needed to build such a database.
•
the delays at locks may be expected to be small relative to the total travel time (which is
not influenced by traffic flow), so that differences in time and cost between loaded and
unloaded networks should not be expected to be large enough to influence the ship type
choice
•
integrating route-choice and ship type choice significantly complicates the model
structure.
Therefore route choice will in first instance be separated from ship type choice. Route choice
will be present in the assignment model, where it is responsible for modelling route spread.
4.5
Summary and conclusions
The results of our investigation of the inland shipping can be summarised as follows:
•
After consideration of several aspects of the inland shipping model, we feel that the
original model structure can and should be adhered to
•
The lack of route choice possibilities in the network has led us to de-emphasise the direct
link between the attractiveness of routes and ship type choice on basis of freight price.
Route choice will be an element of the assignment module
•
The role of the cost factors in the ship type choice model is not self-evident, but must
await confirmation from the data
•
the size of the goods flows varies strongly with goods type and geographic relationship,
and therefore propose to incorporate such effects in the models
•
large goods flows of sand and gravel may move around in unpredictable ways according
to the location of infrastructural projects, and the locations of sand pits. Unfortunately,
no way of predicting where such flows will take place seems to be available
•
in the current base year (1992) container shipments are under-represented. However, the
contribution of container ships to the total traffic flow is low, and is likely to remain so
for some years to come
•
If the average number of shipments per trip is indeed 1.5 (as suggested by Table 5), then
assigning each shipment to its own ship will over-predict traffic flows. Due to the fact
that we are using a pivot point method, we expect this effect to be neutralised when
growth factors are calculated.
39
Specification of the ship type and route choice model VO.5
5
21-03-01 10:36
Synthesis and model specification
In this section a model specification will be proposed for the ship choice in the inland
shipping model on basis of the existing specification and a synthesis of the insights obtained
from the literature and from the investigation of the inland shipping market itself.
5.1
Revised structure of the traffic production module
A revised model structure of the three modules of the Traffic Generation Model is shown in
Figure 12. The difference between the structure and the one shown in Figure 2 is that a
feedback loop from the ship movement list to the Cost Model has been added. Also the path
choice has been made explicit.
The reasons for this addition are:
(1) to ensure that the demand forecast by the ship-choice model can be constrained by an
upper limit on the number of available ships per type, and
(2) to ensure that the distribution of shipment types across ship types reflects the
(generalised) cost of using that particular ship type (e.g. influence of low water on shiptype choice, competition for certain ship types).
This is ensured by letting shipments compete for ship types through the feedback of a an
extra cost component per ship type. As noted in the functional specification, a feedback loop
is needed from the traffic assignment model to the ship choice model. This feedback loop is
also present, but during the iterations to find the optimum ship allocation costs from the
traffic assignment model (shown as "Level Of Service" in the top-right corner) are kept
constant.
Shown on top are the yearly freight demand matrix, which gives the demand T in tonnes for
each combination of r (origin), s (destination), and g (goods type) and the Level Of Service
d (distance) and t (travel time) for each combination (r,s,y,p,nt) of origin, destination, ship
type v, path p and ship load nt.
The freight demand matrix enters the shipment size model, and is converted into a list of
shipments for the analysis period (typically 1 week), taking account of season and goods
type, and perhaps the O/D relationship. This is a very important step, because the shipment
sizes determine (a) the economie viability of various ship sizes and (b) the total number of
ships needed (note that shipments cannot always be mixed), and (c) the traffic load per
season.
The ship choice model is then applied to each of the individual shipments, giving the
probability for each of the ships (y) that can carry the goods type (g). Immediately
afterwards, the probabilities are converted into the ship demand list, i.e. a list of ships needed
to carry the goods specified in the shipment list.
The ship choice probabilities and the shipment tonnes list enter the ship allocation model,
which determines which ships will be used to carry the goods specified on the shipment list.
This model is needed because shipment size may either exceed the capacity of a ship, in
which cases more than 1 ship must be used, or a shipment may consist of a single container,
in which case multiple shipments will end up in a single container ship.
As the analysis period is long enough for the ships to complete their journey and to start a
second one, the overall model structure specified in the Masterplan calls for a model of the
empty trips. The complete list of ship movements that needs to be assigned to the network
consists of both full ships and empty ships. Therefore an empty-ship model is needed. This
model takes the ship demand list, and produces the empty ship list. Both lists together
constitute the ship-movement list M.
40
Specification of the ship type and route choice model VO.5
21-03-01 10:36
The ship movement list M feed back into a cost model. The cost model calculates all cost
components related to endogenous model variables, such as travel time resulting from a
particular level of traffic flow, demand per ship type, and (optionally) from constraints on
fleet size.
A user-optimal solution is sought to the ship choice problem. The existence of such a
solution is assumed on basis that the problem can be formulated as an equilibrium
assignment on a network, in which ship type choice is represented by route choice.
Error! Not a valid link.
Figure 12: The BVMS Traffic Generation Model
5.2
The shipment size model
In the current model system, shipment size is modelled by applying a fixed shipment size
distribution to the yearly demand. This state of affairs has led to a demand for improved
shipment size modelling, which specifically should take account of the effect of shipping
cost, fleet composition, and nature of the goods flow on shipment size.
On theoretical grounds, one could logically expect a process in which manufacturers first
decide on the size of a consignment of goods that they want to ship, and afterwards split this
consignment up into shipments on basis of shipping cost and available shipping possibilities.
Shipping cost is thought to depend primarily on ship type.
We will define consignment size as the amount of goods that a shipper simultaneously wants
to transport from origin to destination. This consignment may or may not fit in a single ship.
If the consignment size is too large for a single ship, it will be divided into shipments.
Shipments are the amount of goods that are shipped in a single ship.
A model which starts with consignments, and models how consignments are split up into
shipments would reflect the effect of shipping costs and fleet composition.
5.2.1 Consignment size modelling: criticism
A proposal to use consignment size as the primary explanatory variable has been discussed
within the consortium, and has received the following criticism:
1. Shipment size is observed, but consignment size is not: we have been informed that
consignment size data is not available.
2. Unobserved considerations regarding the production process of the receiver may well
outweigh pure transport cost when the consignment size is determined. (e.g. coal
powered power plants may not be able store the entire shipment of a seagoing vessel).
3. The market tends to work as follows: a shipping agency or a shipper offers a cargo at a
certain fixed price. Ship operators either accept or don't accept, but have very little
power to negotiate price. The shipper pays the fixed price, regardless of the size of the
ship that transports the cargo.
In addition, the following questions were raised:
(a) Do shipment sizes often exceed the capacity of individual ships (i.e. are consignment
sizes not also tailored to particular ship's capacity as well)
(b) Does consignment splitting occur in practice? (i.e. are loads that can be transported by a
single large ship is ever distributed across smaller ships), and
41
Specification of the ship type and route choice model VO.5
21-03-01 10:36
5.2.2 Possible solutions
A number of possible solutions were considered to deal with the criticism voiced.
1. Use observed shipment size
Another possibility would be to draw shipment sizes directly from a distribution of observed
shipment sizes. This is basically the way it is modelled now, and would have the advantage
that all quantities are observable. It would also have the disadvantage of loosing all
sensitivity to changes in transport cost and fleet composition.
2. Unobserved consignment size
If consignment size is an unobserved variable, we can substitute a proxy. A tentative
definition of a proxy for consignment size would be the weekly total on an r - s relationship
per goods category was proposed, which should be identifïable. Consignment size would
then have to be broken up into shipments.
3. Use modelled shipment size
An altemative would be to construct a linear model for shipment size based on explanatory
variables such as goods type, annual goods flow, transport cost as a function of shipment size
and distance. The shipments obtained in this way would then enter a ship type choice model
to determine which ship type is most likely to be used to transport the shipment.
We propose to use solution no. 3 in the BVMS, and model the shipment size directly in a
way which is sensitive to cost effects.
5.2.3 Model specification for a shipment size model
Based on the models shown in [Abdelwahab et al. (1992)], we propose to use a linear model
for shipment size that is sensitive to transportation cost, and to obtain the shipment sizes
required for simulation from this model by sampling from the error term.
The linear model would take the following form:
ntrsg=pog+$X
+ ersg
(25)
where ntrsg is the shipment size for goods type g between origin r and s in season z, X are
explanatory variables, and Pg and pare parameters to be calibrated, and ersg is an error
term with a known distribution. In this model P° is the average shipment size for goods type
g, and px is used to capture the interaction effects between goods type, distance, cost, and
perhaps origin and destination on shipment size.
In the model specification as originally proposed, £rSj? is a density function over consignment
size classes. In this case a suitable set of classes will have to be devised per goods type,
perhaps allowing for geographical variations. This model is applied by drawing a sample
from £ and calculating the consignment size.
In first instance the model parameters p can be set to zero so that only the constant and the
error term remain.
The explanatory variables should include:
•
goods type
•
yearly volume per origin-destination pair
•
distance
•
transport cost per tonne as a function of shipment size
42
Specification of the ship type and route choice model VO.5
21-03-01 10:36
This model would have to be estimated during the calibration phase, during which the
significance of the explanatory variables will become clear.
5.2.4 The possibility of multiple peaks in the shipment size distribution
If shipment size closely matches ships capacity, then we should expect shipment size to have
a profile a profile as shown in expect in Figure 13 below. Whether the distribution of
shipment size follows this type of distribution remains to be seen, as the relevant data could
not be obtained when the question arose.
If the shipment size distribution has multiple peaks, the use of a model as in (25) in itself
cannot be relied on to provide the correct distribution. On the other hand, the model in (25)
seems suitable to model the relationship between explanatory variables and the location of
individual peaks.
Spread within
shipment size
per ship's class
Capacity of
ship's class
Frequency
of
occurrence
Capacity of ship type a
Shipment size
Capacity of ship type b
Figure 13: Possible distribution of shipment size
This suggests the following way of dealing with multiple peaks:
1. Determine if there are peaks in the shipment size distribution (for each of the goods
groups)
2. Model the amount of cargo for each of the peaks, e.g. using a logit model
3. Model the location and the width of the individual peaks using a model as in (25)
To model the way in which the yearly amount of goods shipped is converted into the
shipment list (all ship movements per day) we need to know if the shipment size varies
significantly within each goods category. As this would lead to considerable complications,
it was decided to request additional data (specified in appendix B) to support design of the
model system for this particular phenomenon.
Shipment size
If the shipment size closely matches the ship's sizes, we know that ships are always loaded
to capacity. If not, then the modelled shipment size should be made to match the observed
distribution. This is illustrated in the figure below.
43
Specification of the ship type and route choice model VO.5
21-03-01 10:36
If the histogram of the shipment size shows peaks, these will probably indicate the ship sizes
of ship's categories. If the total variance of shipment size is large, apparently people choose
between different ship categories, and a break-up of consignments should probably be
modelled.
Furthermore, if the spread of the percentage to which ships are loaded is large, then ships are
not loaded to 100%, and this distribution should be reproduced in the shipment generation
module.
Amount of goods shipped: consignment size
If the amount of goods shipped per month per relationship does not vary much across the
year, the consignment size does not vary much, there is a constant stream of goods, which is
probably parcelled out in ship-sized amounts. In such cases, there will probably be little
scope for ship type choice, and drawing shipment sizes seems as good as any other option.
If on the other hand the amount of goods shipped per relationship per month is significantly
larger than the capacity of a single ship, and if the amount of goods shipped through varies a
lot throughout the year, this probably means that consignment size should be modelled, and
ships are chosen on basis of their cost.
Spatial variation of shipment size
Shipment size will probably vary strongly by yearly amount shipped, which is expected to be
closely correlated with the O/D relationship, so that a breakdown by O/D relationship is
needed.
5.2.5 Converting yearly totals to simulation-period shipments
For the simulation to function, the yearly freight demand totals provided by the TEM matrix
must be converted to weekly or daily and even hourly shipments.
The yearly freight transports show considerable seasonal fluctuation, e.g. agricultural
products. Simply dividing the yearly freight total by the number of working days in the year
will result in an unrealistically flat demand, which disregards seasonal variations. This aspect
is considered to be important as the seasonal fluctuations of freight transport demand result
in fluctuations in traffic intensity.
For this reason it was decided to model seasonal fluctuations in the transportation demand
model. To maintain consistency with observed data, we will impose the constraint that the
distribution of shipment-size and seasonal amount of the modelled freight demand resembles
that of the real freight demand as closely as possible.
44
Specification of the ship type and route choice model VO.5
21-03-01 10:36
1600
•o
4)
Q.
Q.
A
1400
1200
/
!E
M
(0
•o
o
o
1000
O)
°
600
c
3
O
<
/
800
400
\
i—
\
200
•<f «P /
/
\ \
/
h
f/z\
II
-il
•
HK
/
- Monthly
- 3-month avg
- Seasonal_avg
Yearly_average
/
£ ^ 4 # é» £ & <è &°
Month
Figure 14: Possible yearly and seasonal distribution of tonnage shipped for a goods group
Lacking factual information, the amount of goods shipped for a goods group g, might vary as
illustrated in Figure 14. The diamonds show the development of the monthly amount of
goods shipped, the squares show the corresponding 3-monthly seasonal average, the circles
show the seasonal average (May, June, July, August, and September counting as the summer
season), and the flat line shows the yearly average.
If the true variation in amount of goods shipped in goods group g shows this pattern, then the
BVMS model should probably take account of this type of variation in order to reproduce the
a correct seasonal distribution of goods type shipped. That is if the total volume of the goods
group is sufficiently high. Judging from Table 4 on page 32, we feel that attention needs to
be paid to the NSTR-0 categories: mineral oil, coal, and foodstuffs.
For the moment we will assume that the three-month seasonal average will be used; we
expect this to be sufficiently accurate.
We propose first to convert the yearly totals to monthly totals using monthly fractions, and to
use these to obtain the 3-month seasonal averages in case the seasons should be selected in a
different way than by aggregating the months 1-3, 4-6, 6-8, 9-12 into seasons. We note that
if the distribution is bimodal it might be better to use monthly factors than to try to capture
this variation in a linear model.
p. _
; percentage of goods flow in month m for goods type g between origin region F and
destination region J.
Is (m) : indicator function that determines which month m fall in which seasons 5
PTk. m : percentage of goods flow of goods type g between origin region r and destination
region ï in month m that falls in risk class k
Py'j gmk: shipment size distribution for goods flow of goods type g between origin region
F and destination region J in month m that falls in risk class k
45
Specification of the ship type and route choice model VO.5
21-03-01 10:36
46
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Modelling ship type and route choice
The first function of the ship type choice model is to determine the probability of a shipper
choosing ship type y for a given shipment.
In §4.3.3 of the functional specifications (see [Van der Zijpp et al. (1999)]) we find
indications that the ship type model should at least be sensitive to: the type of ship, the load
factor and the route. After some discussion in the consortium, it was decided to loosen the
linkage between route and ship type as will be discussed below.
If, as proposed in §4.3.3 of the functional specifications, the entire shipment is allocated to
the combination of ship and route with the least cost, the LP approach proposed in
[Khoshyaran (2000)] is appropriate. However, as noted in §3.8.2, such models have
significant drawbacks which can be circumvented by using RUM models.
At this point we can list the following altematives, roughly in order of increasing theoretical
elegance:
1. Use LP models for least-cost routing.
2. Use the MNL model for simultaneous ship choice and route choice, knowing this to be
theoretically incorrect.
3. Use the MNL model for ship choice only, and send the shipment via the shortest route
on the loaded network, and mix flows in the assignment.
4. Use a C-logit model (essentially an MNL model with a correction for route overlap) to
model route spreading, and always select the least-cost ship for a shipment.
5. Separate route-choice from ship type choice by using an MNL model for ship type
choice, and a C-logit model for route choice.
6. Experiment with a tree-logit nesting structure to somehow combine the route choice and
ship type choice models.
7. Use a C-logit model for simultaneous ship type and route choice.
8. Combine a C-logit model with a nested logit model for simultaneous ship type and route
choice
9. Use a Probit model for simultaneous ship type and route choice.
10. Use a Hypemetwork to model the combined route and ship type choice, and use the
Paired Combinatorial Logit (PCL) model currently under development as part of ongoing Ph.D. research at Delft University on route-choice in Hypernetworks (see
[Lindveld, 2000]).
Option 1 seems the worst option because it has neither route spreading nor ship type choice
spreading.
Option 2 is feasible from an implementation point of view, but when multiple routes overlap
significantly, this approach leads to incorrect results. This problem can be circumvented by
allowing a maximum of two routes per ship type. Given the sparseness of the network this
might not present too big a drawback, but this can only be ascertained by examining route
choice data. Even then the assignment routines would have to ensure that these two routes
are "sufficiently different" to give any sort of guarantee that the route spread is realistic.
Option 3 is feasible, but requires a complication in the assignment (a sort of dynamic
equilibrium assignment would be needed).
Option 4 is feasible, but requires the assignment module to come up with the k-shortest
paths, and to calculate the amount of similarity between the routes.
47
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Option 5 is feasible, but has the disadvantage that a correct linkage between the route choice
and the ship choice model will have to be determined at the calibration phase, thus
introducing a research component into the calibration phase. It will also doublé the work
needed on choice modelling in the project before the extent of the variation in choice
behaviour has been assessed.
Option 6 would also introducé a research component into the project at the calibration phase,
and still has problems with route overlap due to the variability of the common unobserved
error terms.
Option 7 is feasible, but requires the calculation of route-overlap.
Option 8 is feasible, and may be a good solution from a theoretical point of view. The
drawback is the estimation of a nested logit model, which is more involved that estimation of
a MNL model and requires specialised software (e.g. Hague Consulting Group's ALOGIT).
Option 9 is feasible, and a good solution from a theoretical point of view. However the use
of a Probit model is regarded as more problematic than the use of Logit models, both in
estimation and in application (run-time).
Option 10 is the best solution from a theoretical point of view, but has severe practical
drawbacks. Currently no commercial software package is available for estimation of this
type of model. Estimators are in the research phase and are expected to take about 4 months
to become operational, and will then be research tools rather than end-user products. There is
little practical experience with the PCL model, including its run-time.
5.2.6 Intermezzo: possible use of nested logit models
In this section we will briefly consider a model structure that can:
•
Deal with differences in the decision procedure between ship type choice and route
choice
•
Empirically test whether a linkage is needed
The nested logit model can be schematically represented as in Figure 15.
Shiptype choice
Route choice
Figure 15: Nested logit model for mode and route choice
The upper level choice can be regarded as a multinomial logit model which contains with the
maximum expected utility over all routes open to that particular ship from the route-choice
level through a logsum.
The nested logit model rests on a number of hypotheses (among which a certain correlation
structure between altematives), which we will not review here. The verifiable hypotheses of
this model are (among others) that the logsum from the routes is a significant ingrediënt of
48
Specification of the ship type and route choice model VO.5 21-03-01 10:36
the ship type choice level (t-ratio), and that with proper scaling its coëfficiënt is between 0
and 1.
Although the estimation of nested logit models is more specialised and time-consuming than
that of multinomial logit models, it offers the advantage that it can be used to:
•
Provide a measure of separation between the route choice and ship type choice models
•
test whether the link between route choice and ship type choice is significant
5.2.7 Model proposed for ship type choice
In accordance with the overall structure of the project, we will assume free markets, and as
discussed in §3.8.2, a RUM-based model will be proposed for the ship type choice model.
For our application a multinomial logit model seems best, because it is easiest to use and to
estimate.
On balance we propose to use option 5 (separation between ship type choice model and route
choice model) for the following reasons:
•
It can be estimated using standard software (except for the p. parameter), and the
estimation should be quick and robust
•
It can serve as a "null hypothesis" model: improvements are likely to require more
effort, and should be postponed until it is clear that they are needed.
If the model in option 5 can be estimated we suggest to try option 8 to see if it offers
improvement.
As the consensus in the consortium is that route-choice does not influence ship type choice,
the route spread will not be handled in the ship type choice model, but in the assignment
models.
Having said this, the level of utility per ship type depends on the characteristics of the best
route available to that ship type. For this reason we propose to determine the best route per
ship type (e.g. the quickest route) and calculate the utility of a ship type on basis of this best
route. In this way the ship type choice model will take account of selective route availability,
without calculating route spread.
The probability of choosing ship type y, given origin r, destination s, goods type g, risk class
k using path p when the shipment size is nt tonnes is:
p
(n{)=
ex.p{V s g y k p n I )
^^r,s,r g,y.k.p,n,^
( 2 6 )
where:
Vr! g >• k p nt '•
tne
systematic part of the utility function
Possible consequences ofnon-free markets
For non-free markets (e.g. when several ships are owned by an agency or even the shipper), a
linear-programming (LP) model may be a better description of the way choices are made. An
example is given in the study by [Ieda et a/.(1999)], in which a mix of system-optimum and
user-optimum models was needed to obtain a satisfactory fit. During the calibration it may
turn out that for certain market segments a system-optimal solution (e.g. obtained from an
LP model) fits the data best. If and when this happens, a decision will be needed whether to
adopt an LP model.
49
Specification of the ship type and route choice model VO.5
21-03-01 10:36
The decision makers
Following the functional specification (Van der Zijpp et al. (1999)), the decision makers
with respect to the ship type are assumed to be the shippers ("verladers").
Although we are aware that in many instances the shipper simply offers a cargo at a fixed
price, and all that remains to be done is for a ship to accept this offer, we will hold on to this
model assumption. The reason being that larger ships are expected to be less likely to accept
cargoes that are more suitable to small ships from a cost point of view. So regardless of who
is the actual decision maker, we may assume that we can model the decision as if the shipper
makes it.
Shipment size is also assumed to be determined by the shipper, who is assumed to have his
eye on a particular ship type in choosing the shipment size. The model will give the
probability that a certain shipment will choose a particular ship type ("ship type" includes
ship type and size) and route. The decision still rests with the shipper, but is conditional on
shipment size. The shipment size model is discussed in §5.2.
5.2.8 The route choice model
To obtain a proper route spreading in the traffic assignment, a route choice model is needed.
The decision maker with respect to route choice is assumed to be the ship's captain, and not
the shipper. We will again use a RUM-based model, and propose to use a C-logit model for
the route choice model.
As the consensus in the consortium is that route-choice does not influence ship type choice,
the route spread will not be handled in the ship type choice model, but in the assignment
models. Nevertheless, we will specify the route choice model here.
The choice probability of choosing route p, given origin r, destination s, goods type g, risk
class k using ship type y when the shipment size is nt tonnes is:
^r,s,,y,k.P,n,-P0cF;)
F
""*>*'>
{ )
J,exP(Vr,s,g,,k,,nl-P0CF»)
The commonality factors CF" (see §3.8.4) should relate to the entire systematic utility
(time, cost, and distance), and not just to distance alone. For simplicity the utility can be
based on travel time alone, which is available within the assignment model.
50
Specification of the ship type and route choice model VO.5
5.3
21-03-01 10:36
The utility function for the ship choice model
In this section a utility function will be proposed for shipment of a single consignment n
consisting of nt tonnes of goods of type g from r to s, using ship type v with risk
classification k . The combination of r,s,y,nt,k results in feasible path p":
pn=pn{x,s,yXrA)
(28)
The utility function will be assumed to be linear in parameters, i.e.
V
r,s,g,y,k,p,nt
= V RgyXn
£j rl
I
r.s.g.y.k ,p,nt
with pp the parameters, and X"sg
yk pnt
the explanatory variables.
The utility function parameters have to be estimated separately by goods type (see also
[Bolis and Maggi (1999)]).
In the course of the parameter estimation (model calibration), it may turn out that variables
have to be dropped, combined or added, or that non-linear transformations are needed in the
utility functions. From the point of view of the calibration however such changes are
relatively minor, and can be dealt with as they arise.
Judging from other examples of freight mode-choice models in the literature, the following
variables are expected to play a role in the utility function:
•
Time
•
Distance
•
Cost
We note that in the cost calculation proposed in [Kantoor binnenvaart (2000)], a distinction
is made into fixed an variable costs. Variable costs (such as fuel, oil, port dues, commission)
must be met immediately and cannot be economised on. Fixed costs on the other hand do
usually do not have to be met immediately so that the ship's operator has some leeway to
defer them or to economise on them, or even to finance them using the capital represented by
the ship. For this reason we propose to enter fixed and variable costs separately into the
utility function.
Based on the functional specification and examples from the literature, we propose the
following utility function:
vTJ.t.y.P« = PS + Pfc;::;%,p,nt + PÏC^P
+ P!C:^PM + P!dr^p
(29)
with $1, pf, pi, PI, p4 the model parameters.
This utility is dependent on origin, destination, goods type, ship type, path taken, and the size
of the consignment.
The components of the utility function are:
• Distance
• Travel time
• Fixed cost
• Variable cost
•
as specified below.
51
Specification of the ship type and route choice model VO.5
21-03-01 10:36
5.3.1 Journey cost and link cost functions
The stages of a consignment transported by ship can be schematically depicted as shown in
Figure 16.
1. First there may be a lead time between the moment a cargo is ready for shipping, and a
ship is available (1).
2. Next a there may be a delay before a berth is free, and the ship is actually moored (2).
3. After that the cargo has to be loaded (3).
4. The ship is assumed to travel at free-flow speed all the time, covering the distance
between origin r and destination s (4).
5. Along the way there may be delays due to locks and bridges (5).
6. When the ship arrivés at its destination there may be a delay before the ship can be
moored (6),
6
7
Bridge / lock delays
Free-flow travel time
4
Space
1 2 3
-•—• —
tO
Iime
Time
tl
7. unloading takes place (7).
Figure 16: Phases in the joumey of ships1 cargo
The time and cost components are listed in Figure 5; all times are for a given origin,
destination, ship type, goods type, and path.
52
Specification of the ship type and route choice model VO.5
Additional Cost components
notes
Time, cost
components
phase
Jead
r,s,g.y,p,nt
notice time
2
jberth
^-»
r,s,g,y,p.nt '
2
berthing time, port charge
f ship
3
Jood
r,g,y,nt '
loading time, loading cost
f ship
•>.v.3
s->handling
^rgy
5
6
r ship
-'v.1
^ wait
*r,s,g,y,p,nf
delay time due to locks
and bridges
f ship
Jy.ï
fberth
s.g.y.p.nt
berthing time
r ship
JyJ
fUnload
s.g.y.nt
unloading time
r ship
Jy.i
c
W
1
7
Ships'
cost,
Stock cost
r ship
J y,o
Sailing time, travel cost
sail
r,s,g,y.p,nf
l
b
a
1
4
21-03-01 10:36
wages,
Figure 17 : Time and cost components of a joumey
Stock cost accrues during the entire time from the moment that a cargo is ready for shipping
until the moment that it has been unloaded. Ships cost f*%p and wages accrue during the
entire period that a ship is occupied with the shipment. Special charges apply while the ship
is sailing f fxip ; slightly different costs accrue when the ship is idling fyh2'p before a lock or a
bridge and while it is moored f*hjp.
Port charges may be due for the use of the quay and
may vary by type and size of ship. Finally there may be charges for loading and unloading,
which may vary by port.
Although it is not clear at this time which costs are non-zero, in principle all such costs are
accounted for in the model specification; they may set to zero during the model calibration.
5.3.2 Cost calculation
Travel time
u>!al
r.s,g.y,p,nt
fPoth
~~ r.s.g,y,p,nt
,
wait
r,s,g,y,p,nt
.idling
'r,s.g,y,p,nt
(30)
Travel time consists of path travel time, loading and unloading time, lead time, and berthing
time.
sail
Sailing time f r,s,g,y,p,nt
.
idling
•
T i m e l o s t w a i t i n g f o r b r i d g e s a n d l o c k s : tt'rJ"g
•
Time for loading, unloading, and any other time spent with the motor off: t™"gyn[
ypnt
Optionally, the model can work with expected empty travel time (derived from empty trip
model) r £ *
53
Specification of the ship type and route choice model VO.5 21-03-01 10:36
The cost component in the utility function is the cost to send the entire shipment with ship
type y via route p. The cost components of sending a single ship are: transport cost, handling
cost, stock cost, and ship competition cost:
s~i
s~*transport
r.s.i.y.p.* ~L'r,s.g,y,p,nt
, f handling
+
^r.s.g.y.nt
. s^ Stock
+
^r.s.g.y.p.nt
+
. s~>penalty
/oi \
^ rsgy '
.
Transport cost: C~ r t ,,„, = Cf
•
Handling cost: C^ling = C^d"ng + C?gfmg
W )
+ f™iUngt^p + f^'t^
+ f^'t^'
(cost for loading and unloading goods type g from ship type y)
•
Stock
cost
^Stock
_ n
*~'r.s.g,y,p.nt ~
(value
t *
n l
C
of shipment
* time
* hourly
interest
percentage)
*ftotal
# rh
^g
'r,s,g.y,p,nt J
%j needed
•
Ship type competition penalty Cp'"alty = ƒ,,
Ny'
Optionally the cost of picking up new cargo could be entered into the utility function; this
cost should be calculated on basis of the follow-up trip predicted by the empty trip model. At
the moment there is some doubt about whether this would actually increase the accuracy of
the model. In any event this cost should have a separate parameter.
s~<retum
rsailing_empt\fsailing_empty
^r,.s.,.P.n,-Js.y
5.4
"Vv
('1.'}\
'
P
^
The ship type choice module
Having selected a MNL model for ship type choice, in this section we will proceed to define
how the ship type model will be operationalised in the ship type choice module.
The structure of the ship type choice module is shown in Figure 18. First a choice set is
generated consisting of all ship types that can in principle be used to transport goods of type
g from r to s.. As the number of ship types is limited, the choice set will have a limited size.
For each of the ship types in the choice set a utility is calculated, these are used to calculate
the ship type probabilities when a shipment of nt tonnes of goods type g has to be sent from r
to s.
The ship choice model reflects the behaviour of the decision maker (shippers) in the market
in which they operate. For markets with free competition, the ship choice model will take the
form of a discrete-choice random utility model in which, in which the are free to choose an
optimum ship.
54
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Ship choice model
Fleet requirements
n(y)
Fleet data (y)
Shipment list
l(r,s.g.k.nt)
Level of service by path
lOS(r.s,k.p)
Positive load factors
f(r.s.9.y)
Utilities
U(r.s,g.y.nt)
I
Ship choice probabilities
P(r,s.g.l<.P.ntty)
Figure 18: Ship type choice model
5.4.1 The cost feedback loop
We usually assume that there are enough ships of every category to handle the total demand.
However, one of the design requirements is that it should be possible to restrict the
availability of the fleet. This is modelled as a constraint on the number of available ships per
type, which in turn is reflected in the model by adding a penalty to the cost of a ship for
which the demand exceeds the supply.
Another issue is that there may be temporary shortages of particular ship types; this is
modelled through an artificial component of the shipping cost per ship type. Note that this
may also provide an opportunity to model the cost associated with switching between type of
cargo (e.g. cleaning for bulk carriers).
To ensure that an optimal assignment of ship types to shipments occurs in the presence of a
constraint on the number of ships, an artificial cost is added to ship types for which the
demand exceeds the supply. By iterating the ship type choice model with the penalty cost,
consistency can be achieved between supply and demand per ship type.
5.4.2 Choice sets and choice set generation
The choice set that shippers face in the ship-choice model is thought to consist of ship types
with which to carry a complete shipment (the shipment sizecoding for ship type also covers
ship size). The draught of a ship is determined by a combination of ship type and cargo size.
55
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Each of the possible route altematives has a length, a travel time, and ship-size restrictions
such as maximum depth, maximum length, maximum width, and maximum height. Due to
these restrictions, some routes may not be accessible to certain ships, or only when the load
is less than a certain threshold value.
For this reason the length, travel time, and cost of a route in depend on the dimensions of the
ship and the load, so that the cost of a route depends on ship type and load. The choice
between ship types is modelled on basis of cost, distance, and travel tine. As the shipment
size is fixed, the altematives consist of ship types. The ship type choice altematives consists
of a list of all ships that are suitable for the type of cargo at hand and sail from origin to
destination with their maximum load factor for that trip.
Error! Not a valid link.
Figure 19: Ship type choice set generation
The choice set is determined for each combination of origin r, destination 5 for path p, goods
type g , and risk category k by selecting those ships from the shiptype altematives that can
carry the entire shipment. The ship types that are suited to carry goods type g are short-listed
in "suitable ship types".
Next the shiptype choice altematives are calculated as shown in Figure 20.
The level of service between 5 and r the following is looked up from the L.O.S. tables:
• maximum risk category Maxk
• maximum permissible length of a ship Maxl
• maximum permissible length of a ship Maxw
• maximum permissible draught of a ship Maxd
The properties of each ship type on the list of suitable ship types are checked against the path
restrictions: Maxk , Maxl, Maxw , Maxd , giving the second shortlist of permissible ship types.
For permissible ship type y, a load factor (pp y is calculated, based on the ship's capacity and
the minimum depth along the path.
56
Specification of the ship type and route choice model VO.5
Fleet data (y)
Suitable ship types
21-03-01 10:36
Level of service by path
LOS(r,s.k.p.y)
Calculate max load factor
/
Permissible ship types
Shiptype choice altematives
(y.i%)
Ivfeximum shipment size
Figure 20: Generation of shiptype choice altematives
The shiptype altematives now consist of a list of all ship types y that are compatible with
goods type g and can carry the entire shipment of nt tonnes of goods between r and s along
path p. This list serves as input into the ship choice model.
5.5 The ship allocation model
The purpose of the ship allocation model is to translate the ship choice probabilities
calculated in the ship choice model into actual ship movements.
We will denote the ship type as y, and the amount of goods to be transported as nt. The
probabilities of choosing ship type y given goods type g, shipment size nt, origin r,
destination s and path p are denoted asP grs (nt). The list of movements of loaded ships is
denoted as
L(r,s,g,y,k,p,nt).
The ship movements are obtained by drawing a ship type according to the ship type
probabilities Pgn(nt) obtained from the ship type choice model.
57
Specification of the ship type and route choice model VO.5
21-03-01 10:36
5.6 Comments on the empty-trip model
Although the empty-ship model does not form part of the work for the ship type choice
model, a short review of the model status seems indicated.
The empty-trip model (see Figure 2: Traffic production module) is responsible for re-routing
empty ships to their most likely second origin. An extensive study into the subject can be
found in [Bovenkerk (2000)].
Notwithstanding the fact that the study was possible only because of the availability of a
special datasource (the IVS), the study notes several items of concern regarding the raw data
and implies a few more:
•
The monitoring system has certain "holes", which prevent it from covering certain major
relationships
•
The dataset contains numerous incomplete records (see the tables in appendices IX and
X of [Bovenkerk (2000)]), so that some form of data imputation is necessary. The study
notes that the data imputation procedure could be improved.
Due to the amount of dataprocessing needed to préparé the raw data for estimation, the
absence of a proper transportation network, and long model estimation times, a number of
shortcuts were inevitable, among these:
•
Use of the crow-fly distance as a proxy for network distance and travel time (absence of
influence of locks and bridges and detour factors)
•
Seasonal factors, ship type, and goods type last transported could not be taken into
account
•
the report recommends a closer link between empty trips and their preceding full trips
•
treatment of foreign destinations in the same way as national destination; the report notes
that differentiation between e.g. destination in the German hinterland and home
destinations may improve results.
•
The models do not distinguish between long and short trips; the report however notes
that there is a strong possibility that such aspects influence the attractiveness of trips for
ship captains
The models show considerable spread between observations and predictions (see appendix
XVI of [Bovenkerk (2000)]), even when plotted on a double-logarithmic scale. Of course a
substantial part of the unexplained variance is probably due to the need for imputation of
incomplete data. Without in any way detracting from the study, it seems that the empty-trip
models need to be refined before they can be entered into the production system.
Several practical avenues of research are suggested in the report:
•
Improvement of the data imputation
•
Use of a network-based L.O.S. instead of using crow-fly distances
In addition we would like to propose an additional avenue of research:
•
disaggregation of the models by market (i.e. goods type).
From a theoretical point of view it may be expected that the use of ship type correlates with
the market (goods type), and that different markets show different behaviour with respect to
the pattern of empty-trips. The fact that (see [Bovenkerk (2000)], table 16) the model for
tankers (ship type 2) is seen to result in a much better fit than that of other ship types (which
serve multiple markets) points in this direction.
58
Specification of the ship type and route choice model VO.5 21-03-01 10:36
Note that in the empty-trip model, the decision makers are the ship-operators, not the freightforwarders. When the ships' captain is the owner-operator, he is also the decision maker; in
other cases the fleet-owner is the decision maker. Although most of the ships in inland
shipping fleet are operated by the owner, in certain markets they may not be. This may make
a significant difference in the way in which the decisions can best be modelled.
5.7
Comments on the model structure
In view of the goal of the BVMS model (which is to be a policy sensitive model), it seems
best to design the model to be as policy-sensitive as can be reasonably expected while
retaining
a workable model structure.
"o
The estimation of the discrete-choice models will reveal the extent and nature of the policy
sensitivity. Therefore we submit that investigating the relationship between shipment size
and possible explanatory variables is needed to allow for the possibility of improving the
BVMS beyond the capabilities of existing models.
The model types proposed in the specification outline in this report can be estimated and
applied regardless of whether e.g. shipment size can be explained from readily available
data. Even if the relationship found in the data should tum out to be weak, the choice model
will be able to accommodate it, albeit with less efficiency than models that are insensitive to
policy measures. This however is not regarded as a significant disadvantage at this stage.
In the absence of firm data on which to base the choice, the explanatory variables listed in
the literature were adopted for inclusion in the model specification.
5.8
Notes for the calibration phase
As it is not possible to access the data before completing the model specification, some
thought is needed about possible problems and their diagnosis during the calibration and
fine-tuning phase of the ship choice model when data is available. A critical review of
assumptions that went into the model specification may aid the speedy diagnosis and
correction of such problems.
Strictly speaking, all hypotheses underlying the choice of the model can be questioned;
among these:
•
the validity of the shipment-size model (little is known about the distribution of
shipment sizes by goods type, O/D relationship, and season and interaction between
shipment size and ship type intended by the shipper)
•
assumptions about the nature of the market (the free-competition hypothesis !; the
BVMS distinguishes only by goods type; weights of aspects and e.g. V.O.T. may differ
among combinations of shippers and receivers) NEA informs us that ship type choice is
not purely based on cost minimisation, but has an unobserved component.
•
identification of the decision makers for ship choice (each individual shipment assumed
to have an individual shipper as decision maker; so no long-term contracts and no fleetowners)
•
how vessels may combine shipments (the first approximation is that each shipment
secures one ship for its exclusive use)
•
whether the correction from the C-logit model is sufficient; whether the value of the
parameter ji in the C-logit model is critical
•
identification of the utility function
•
economie variables seen as the only relevant variables
59
Specification of the ship type and route choice model VO.5 21-03-01 10:36
•
travel time delays are incurred only on links, and not when loading or unloading
ships.
•
all ships are state-less (no effects attributed to the choice of remain ovemight (RON)
sites)
• unbiased measurement of the relevant variables (especially cost and consignment size)
•
•
no allowance for hidden or mis-specified costs. As real transportation costs are
commercially very sensitive, and therefore information on them is scarce.
No allowance for bias introduced by basing the model estimation on the IVS.
•
There are indications certain discrepancies exist between the databases extracted
from the IVS and the data supplied by e.g. the CBS. This could cause bias in the
models, and will be an issue during the calibration phase.
•
Judging from the report by [Bovenkerk (2000)] and a quick scan of the IVS, a
considerable percentage (about 40%) of the IVS records are incomplete.
Fortunately the remaining number of records seems adequate to support model
estimation, however if incompleteness of records is somehow correlated with
type of vessel, type of goods or consignment size this will cause a bias in the
database which will perforce be present in the models as well.
These considerations are of a theoretical nature because the models were drawn up in the
expectation that the hypotheses listed above are valid. This expectation will be confirmed or
refuted as the models are calibrated. In the mean time, efforts at model improvement can best
be postponed until the least accurate model component has been identified.
60
Specification of the ship type and route choice model VO.5 21-03-01 10:36
6 Data requirements
In this chapter we will list which of the tables in listed [Van der Heijden, M. (2000)] are
needed. As we have been repeatedly given to understand no data is available on consignment
size (as opposed to shipment size).
6.1
Fleet related data
Table 2.1: complete
Table 2.2: complete
Table 2.3: complete
Table 2.4: complete
Table 2.5: complete (only K_vast, K_wachten, K_stilliggen, K_varen_vol, K_varen_leeg are
used by the ship type choice model; these items may be calculated by the user on
basis of the other items in this table).
Table 2.6: complete
6.2
Demand related data
Table 3.12. This table should be derivable from table (I).
Table 3.13 (if a single large (50-classes or more) system is set up, the endpoints of the
shipment size classes should be selected in such a way that the distributions obtained from
tables (I), (II), and (III) van be represented in this class system.)
Table 3.15
6.2.1 Additional tables
Tables (I), (II), (III) as specified in Appendix B (§11); these tables will be based on the IVS.
On basis of these tables, it can be decided if table 3.13 needs to be dependent on goods
group.
A table with the mean value in [euro/tonne] for each goods group.
6.3
Data for model estimation
What is needed to estimate a choice model for ship choice is a table of observed goods
movements L(r,s,S,g,k, y, dist, time, Cost) for the chosen altemative and a number of nonchosen altematives (e.g. different ship types using the same route) comprising:
•
Origin: r (aggregated to distinguish between the most important O/D relationships.)
•
Destination: s (aggregated to distinguish between the most important O/D relationships.)
•
Season: S
•
Goods type: g
•
Shipment size: nt [tonnes]
•
Ship type: y
•
Indication of chosen altemative: i
61
Specification of the ship type and route choice model VO.5 21-03-01 10:36
•
Per altemative (r,s,g)
•
Length of the route: dist [km]
•
Time, [hrs] subdivided into:
•
•
Sailing time
•
Idling (locks, bridges)
•
Waiting time (loading, unloading, waiting)
Cost: subdivided into
•
Transport cost
•
Cost of empty return
•
Handling cost
•
Stock cost
A table of observed ship movements with the same set-up, but now containing route
altematives would be best to estimate a route choice model. Since this may be impossible,
the route choice model can be estimated on the dataset for ship type choice.
6.4 Data use input and output by module
6.4.1 Traffic production module
a) Input
i) LOS(r,s,k,p)
(1) Dist (r,s,k,p)
(2) Time
(a) C' ;,g.y,p.i
[hr]
(b) CL, P . n , M
(c) C>
\p.i
[hr]
(3) Cost
(a) C ™ * , C^dling [eur] : handling cost at origin and destination (if any)
(4) Constants
ii) Fleet data: Y
(1) Shiptype y (+ contents of table 2.5 [Van der Heiden (2000)])
(a) Length [m]
(b) Width [m]
(c) Max_Height [m]
(d) Draught empty [m]
(e) Draught full [m]
(f) Draught / load table
(g) Maximum cruise speed [km/hr]
(2) Vervoerbaar (table 2.2 [Van der Heiden (2000)])
iii) TEM freight matrix
(1) T(r,s,g,nt) [tonnes/year]
iv) Shipment distributions
(1) Monthly distribution Pfj,m,g
62
Specification of the ship type and route choice model VO.5 21-03-01 10:36
(2) Season indicator function Is (m)
(3) Risk class distribution P?*?>m^
(4) Daily shipment size distribution: /Vj,s,m.*
b) Output
i) Ship movement list
(1) L(r,s,g,k,nt,y)
c) Interna! stores
i) Utilities
^ '
r,s,g,y,p,nt
ii) Fleet requirements
(1) N(y)
iii) Empty trips
(1) N(r,s,y)
iv) Ship choice probabilities
(]\
\ S
p
r.s,g,k,p,nt,\
v) Shipment list
(1) l(r,s,g,k,nt)
vi) Ship demand list
(1) l(r,s,g,k,nt,y)
vii) Shiptype choice altematives
(1) (y, lf(y))
d) Submodels
i) Shipment size model
ii) Ship choice model
iii) Empty trip model
iv) Ship allocation model
v) Concatenation and summation of demand lists
6.4.2 Shipment size model
a) Input
i) Fleet data (Y)
ii) LOS(r,s,k,p)
iii) Shipment distributions
iv) TEMcells
b) Output
i) Positive load factors
ii) Shipment list
c) Internal stores
i) Maximum shipment size
ii) Monthly demand
iii) Daily demand characteristics
iv) Seasonal demand
v) Seasonal demand by risk category
d) Submodels
i) Choice set generation
ii) Model daily demand distribution
iii) Calculate_Monthly_demand
iv) Calculate_seasonal_demand
v) Split_by_risk_factor
63
Specification of the ship type and route choice model VO.5
21-03-01 10:36
vi) Draw from daily demand
6.4.3 Ship choice model
a) Input
i) Fleet requirements
ii) Fleet data (Y)
iii) Shipments list
iv) Level of service by path
v) Positive load factors
b) Output
i) Utilities
ii) Ship choice probabilities
c) Interna! stores
i) d) Submodels
i) Utility calculation
ii) Choice probability calculation
2) Empty trip model
a) Input
i) Ship demand list
ii) Utilities
b) Output
i) Empty trips
c) Interna! stores
i) d) Submodels
i) 3) Concatenate demand lists
a) Input
i)
b) Output
i)
c) Internal stores
i)
d) Submodels
i)
4) Ship allocation model
a) Input
i) Ship choice probabilities P(r,s,g,k,p,nt,y)
b) Output
i) Ship demand list
c) Internal stores
i) d) Submodels
i) 64
Specification of the ship type and route choice model VO.5
21-03-01 10:36
5) Shipment size model
a) Input
i)
b) Output
i)
c) Internal stores
i)
d) Submodels
i)
6.5
Suggestions for data collection and data cleaning
As the IVS will probably play a central role in the estimation of the choice models, we
propose that an effort is made to obtain the best possible IVS dataset for a recent year, and
clean it according to the suggestions with respect to data imputation in [Bovenkerk (2000)].
Although in NEA's estimate the imputation of IVS variables should not be necessary for
records pertaining to non-empty trips, this should probably be checked as NEA has reported
problems in deriving tables (I), (II), and (III) (as defined in Appendix B: additional tables
requested on page 73) from the IVS dataset.
The IVS dataset will be needed to estimate the empty-trip model so that imputation of the
missing fields is needed in any event.
In addition the holes in the IVS coverage should be listed, and an estimate should be made of
which O/D relationships are affected and to which extent.
For the estimation of choice models, the IVS dataset should be enriched with information on
ship type and route choice altematives.
Finally the dataset should be converted into a flat ASCII dataset that is suitable for standard
estimation packages for choice models.
65
Specification of the ship type and route choice model VO.5 21-03-01 10:36
7 Summary and conclusions
This report presents version 0.5 of the model specification; in several cases design decisions
were taken which may have to be revised on confrontation with the data. The original
architecture of the model system is mostly intact, but a number of difficulties were
encountered in specifying the models to be used. In discussions that followed the first draft
of this report, a number of modelling difficulties were identified. This report also outlines the
need for raw data (see section 6: data requirements) in sufficient detail for the data
processing to begin.
7.1 Modelling difficulties identified
One of the main difficulties revolves around the miscommunication regarding whether
consignment size (latent) is to be used in the models or shipment size (observed). On basis of
comments on the first draft of this report regarding the non-availability of consignment size,
the modelling was revised to use shipment size instead but in such a way as to be sensitive to
developments in transport cost and fleet composition.
The second difficulty revolves around the interaction between route choice and ship type
choice. Although the presence of this interaction is clear from a qualitative theoretical point
of view, it is debatable whether this interaction is significant from a quantitative point of
view. Therefore the interaction between route choice and ship type choice was dropped in
this version of the model specifications.
The third difficulty is a consequence of the recent decision to work with shipment size rather
than consignment size, and revolves around the question of how to model shipment size. This
issue is new, and awaits the availability of data.
A fourth issue is the lack of certainty regarding the role of transportation cost in ship type
choice. As noted in §4.3.1, small shipowner/operators may be able work below cost price for
extended periods of time. Due to the way the market functions this can dilute the relationship
between cost price and shipping charges, and therefore the explanatory power of cost price
on ship type. The extent of this dilution can only be assessed after estimation of
corresponding model parameters, but is not expected to have an impact on model structure.
7.1.1 Minor modelling difficulties identified
Progress has been made with the modelling and an overall model specification has emerged.
However a number of important modelling details remain which preclude finalisation of the
model specifications to the extent that substantial resources can be committed on coding the
model system. These issues can only be resolved on basis of the analysis of real data.
We mention:
•
The identification of the variables that determine shipment size
•
The distribution of shipment size (uni-modal or multi-modal)
•
The identification of the variables that determine ship type choice
7.2 Models proposed
The choice models proposed follow the BVMS model structure as outlined in §2.
After consideration of the available altematives, the choice models proposed are listed in
Table 6.
66
Specification of the ship type and route choice model VO.5
Model
Described in
Ship type choice
5.2.7,5.3, 5.4
Route choice
5.2.8
Shipment size
5.2.3
21-03-01 10:36
Table 6 : Choice models proposed for ship type, route choice, and shipment size
67
Specification of the ship type and route choice model VO.5
21-03-01 10:36
8 Symbols used
C
: cost of goods type g per tonne
Capy
: the capacity of ship of type y
CFp
: the commonality factor if route p in choice situation n
Chyase
: basic cost for ship of type y
dv (q) : depth as a function of load for ship type y
(p}
: the minimum shipment size for ship type y and goods type g
(p
: the load factor for ship of type y on route p
j-saiimg
. h o u r i v 5^^ c o s t s for s hip of type y (sailing)
jrutimg
. hourly ship costs for ship of type y (waiting with motor tumed on)
fywa"
: hourly ship costs for ship of type y (waiting with motor tumed off)
g
: goods group
k
: risk category (number of "kegels")
L{r,s,g,y,k,p,nt):
list of ship movements
Maxk
Maxl
Maxw
Maxd
: maximum risk category (maximum number of "kegels")
: maximum permissible length of a ship
: maximum permissible width of a ship
: maximum permissible draught of a ship
n
nt
Nv
: individual shipment
: number of tonnes in shipment
: number of ships extended ship category y
p
: path, route
r
: origin
5
: destination
y
: generalised ship type (covers all combinations of ship category and class)
68
Specification of the ship type and route choice model VO.5 21-03-01 10:36
9 References
Abdelwahab, W., Sargious, M. (1992) Modelling the demand for freight transport. A new
approach. Journal of transport economics and policy. 26(1), 49-70, 1992.
Abdelwahab, W.M. (1998) Elasticities of mode choice probabilities and market elasticities
of demand: evidence from a simultaneous mode choice / shipment-size freight transport
model. Transpn. Res. E. Vol. 34, No. 4, pp. 257-266. 1998.
Ben-Akiva, M., Lerman, S. (1985) Discrete choice analysis: Theory and application to
travel demand. The MIT press, Cambridge, MA., USA.
Bolis, S., Maggi, R. (1999) Adaptive stated preference analysis of shippers' transport and
logistics choice. 8lh WCTR proceedings. Vol. 3, pp. 185-198.
Bovenkerk, M.H.G. (2000) Leegvaart binnen het BinnenVaartModelSysteem. TNO rapport
Inro/LOG 2000-20. TNO Inro.
Cascetta, E., Nuzzolo, A., Russo, F., Vitetta, A. (1996) A modified logit route choice model
overcoming path overlapping problems specification and some calibration results for
interurban networks. Proceedings of the IS 111 conference, Lyon, France.
CBS (1996) Statistiek van het binnenlands goederenvervoer, 1996. CBS Voorburg / Heerlen.
Dargay, J.M. (1993) Demand elasticities: a comment. Journal of transport economics and
policy. Vol. 27, pp. 87-90.
Ieda, Hitoshi, Ryuichi Shibasaki, Satoki Naito, Daisuke Mishima (1999) Model development
for East Asian container shipping considering multifarious use of vessels and ports. 81"
WCTR proceedings. Vol. 3, pp.213-226.
Goodwin, P.B. (1992) A review of new demand elasticities with special reference to short
and long run effects of price changes. Journal of transport economics and policy. 26(2), 155169. Companion paper: Oum et al. (1992).
Gray, R. (1982) Behavioural approaches to freight transport modal choice. Transport
reviews, 1982, vol. 2, No. 2, 161-184.
Harker, P.T., Friesz, T.L. (1986a) prediction of intercity freight flows I: theory. Transpn.
Res.-B, Vol. 20B, No. 2, pp. 139-153.
Harker, P.T., Friesz, T.L. (1986b) prediction of intercity freight flows II: mathematical
formulations. Transpn. Res.-B, Vol. 20B, No. 2, pp. 155-174.
Jourquin, B., Beuthe, M., Geerts, J., Koul a Ndjang' Ha (1999) Intermodality and
substitution of modes for freight transportation: computation of price-elasticities through a
geographic multimodal transportation network analysis. Nectar conference, Delft, October
1999.
Kantoor Binnenvaart (2000) Kostprijsprogramma.
URL:
http://www.kantoorbinnenvaart.org/prijs.html.
Khoshyaran-Lebaque, M. (2000) A freight traffic modelling approach for the waterway
network in the Netherlands. TU. Delft, report nr. VK 2000-005.
Lindveld, Ch.D.R. (2000) Progress report on the Hypemetwork project. DUT Memo in
progress.
Ministerie van Verkeer en Waterstaat, DG Rijkswaterstaat
basisgegevens (1997) Jaarrapport scheepvaartgegevens 1996.
AVV,
Hoofdafdeling
Ministerie van Verkeer en Waterstaat. Meerjarenprogramma Infrastructuur en Transport
(MIT).(1998).
69
Specification of the ship type and route choice model VO.5
21-03-01 10:36
Norojono, O., Young, W. (????) A stated preference freight mode choice model. PTRC.
Nuzzolo, A., Russo, F. (1998) A logistic pproach for freight modal choice model. PTRC
conference 1998; Seminar E: Transportation planning methods.
Oum, T.H., Waters, W.G., Yong, J.S. (1992) Concepts of price elasticities of transport
demand and recent empirical estimates. Journal of transport economics and policy. 26(2),
139-154. Companion paper: Goodwin (1992).
Rabo (2000) Markstudie binnenvaart; verkorte samenvatting.
http://www.rabobank.nl/algemeen/algemeen_nav.asp?node_id=86096&Page=ll
Roberts, P.O., Ben-Akiva, M., Terziev, M.N., Chiang, Y. (1977) Development of a policy
sensitive model for freight demand. Phase I report. MIT center for transportation studies.
CTS report number 77-11. April, 1977.
Van der Heijden, M. (2000)
. TNO memo 25 juli 2000 by Matthieu van der Heijden.
V.d.Zijpp, N.J., Lindveld, K, Dijker, T. (1999) Functionele specificatie van modelsysteem
binnenvaart versie 0.2: identificatie in- en uitvoer.
De Wit, J., van Gent, H. (1996) Economie en transport. Lemma, Utrecht.
Zlatoper, T.J., Austrian, Z. (1989) Freight transportation demand: a survey of recent
econometrie studies. Transportation 16: 27-46, 1989.
70
Specification of the ship type and route choice model VO.5
21-03-01 10:36
10 Appendix A: table of input data items for ship type route
choice model
Description
Symbol
P!,pg,P!,pg,p4
model coefficients
Capy
ship's capacity
ships load factor
<PP.y
dy(q)
depth as a function of load for
ship type y
Ny
number of available ships
Units
Cat
•
Remarks
-
DB
To be estimated per goods type g
[tonne]
DB
-
R
Calculated by assignment module
DB
-
DB
Units
Cat
•
Table 7: Data items
Symbol
Max
P.k
Max
P.i
Maxpw
Max
P,d
Description
maximum risk category on
path p
—
R
Calculated by assignment module
maximum permissible length
on path p
[m]
R
Calculated by assignment module
maximum permissible width
on path p
[m]
R
Calculated by assignment module
maximum
permissible
draught on path p
[m]
R
Calculated by assignment module
R
Calculated by assignment module
commonality factor of routes
CF
i r
Remarks
- r.s,g.y.p
travel distance
[km]
R
Calculated by assignment module
j sail
r,s,g ,y,p,nt
sailing time
[hr]
R
Calculated by assignment module
t wait
1
waiting time
[hr]
R
Calculated by assignment module
Aoad 1 unload
r.s.g.y.nt
loading/unloading time
[hr]
DB
(if available)
Jead
r.s.g.y.p.nt
lead time
[hr]
DB
(if available)
.berth
r.s,g,y,p,nt
berthing time
[hr]
DB
(if available)
Units
Cat
d
r,s.p
r.s.g.y.p.nt
Table 8: Level of service variables
Symbol
Description
Remarks
71
Specification of the ship type and route choice model VO.5
21-03-01 10:36
•
r sailing
Jy
Sailing cost (full)
[Eur/hr]
DB
r idling
ƒV
Ship's cost when idling (with
running engines)
[Eur/hr]
DB
r waiting
JV
Ship's cost when waiting
(with engines off)
[Eur/hr]
DB
Table 2.5 (Note: cost per hour
instead of per km)
Jv
Ship's cost
(empty)
[Eur/hr]
DB
Table 2.5 (Note: cost per hour
instead of per km)
C
handling cost
[Eur/tonne]
DB
(if available)
handling cost
[Eur/tonne]
DB
(if available)
Cost of cargo
[Eur/tonne]
DB
Not yet specified
r sailing _empty
when
sailing
Table 2.5 (Note: cost per hour
instead of per km)
Table 2.5 (Note: cost per hour
instead of per km)
Table 9 : Cost components
72
Specification of the ship type and route choice model VO.5
21-03-01 10:36
11 Appendix B: additional tables requested
Additional data tables were requested to support design decisions, as detailed below. The
class numbers used in tables (I) and table (II) are to be determined by the 5, 10, 20, 30, 40,
50, 60, 70, 80, 90, and 95 percentile points of the goods distribution per goods group g. The
values of these percentile points should be given as a separate table.
Table (I)
For each of the 27 BVMS goods groups a frequency table of the shipment sizes and ship load
percentages over a year, with the following records: (g,m,r,c,n,p), with:
• g: goods type (the 27 categories defined in the BVMS)
• m : month
• r : relationship (NL->D, D -»NL, NL->B, B->NL, NL_prov <- -> NL_prov), where
NL_prov is the province
• c: class number (a suitable class structure needs to be defined with 11 classes)
• n: number of observations in this class
• p: the percentage to which the ship was loaded (shipment_size / ships_capacity)
This would lead to at most 27 * 12 * 11 * (4 + 12 * 12) = 521 All records for 12 provinces,
but probably a lot less due to the sparsenes of the O/D table.
Table (II)
For each BVMS goods group a frequency table of the total amount of goods sent, with the
following records: (g,m,r,c,n)
• with g: goods type (the 27 categories defined in the BVMS)
• m : month
• r : relationship (NL^D, D ->NL, NL->B, B->NL, NL_prov <r -> NL_prov), where
NL_prov is the province
• c: class number (a suitable class structure needs to be defined with 11 classes)
• n: the number of observations in this class
This would lead to at most 27 * 12 * 11 * (4 + 12 * 12) = 521412 records for 12 provinces,
but probably a lot less due to the sparsenes of the O/D table.
Table (III)
A table containing records (g,m,r,X):
• with g: goods type (the 27 categories defined in the BVMS)
• m : month
• r : relationship (NL->D, D ->NL, NL->B, B->NL, NL_corop->NL_corop), where
NL_corop is the corp zone
• X : a list of the following items in tonnes:
1.
total amount shipped in this month,
2.
mean of shipment sizes in this month,
3.
minimum of shipment sizes in this month,
4.
maximum of shipment sizes in this month
5.
standard deviation of shipment sizes in this month
6.
median of shipment sizes in this month
This would lead to 27 * 12 * (4 + 569) = 185652 records for the 569 inter-corop
relationships distinguished in the "Jaarrapport Goederenvervoer 1997").
73
Functional Specification Modelsystem Inland
shipping Version 0.5:
Specification of the assignment and simulation model
Transportation Planning and Traffic Engineering Section
Faculty of Civil Engineering and Geosciences
Commissioned by:
Status:
Date:
TNO-Inro / Adviesdienst Verkeer an Vervoer
Concept
1 November 2000
Authors:
S. Catalano
N.J. van der Zijpp
K. Lindveld
1
INTRODUCTION
1
2
THE FRAMEWORK FOR THE ASSIGNMENT MODULE
2
3
ROUTE ENUMERATION MODULE
4
4
ROUTE COST COMPUTATION MODULE
7
5
DYNAMIC ASSIGNMENT MODULE
9
5.1
5.2
5.2.1
5.2.2
5.2.3
6
7
ROUTE SELECTION MODEL
DYNAMIC NETWORK LOADING MODEL
Link travel time
Movable bridge model
Lock model
10
10
Il
16
18
INPUT AND OUTPUT DESCRIPTION
20
6.1.1
6.1.2
20
21
Input data
Output data
REFERENCES
23
Specification of the assignment and simulation model
1
Introduction
This report deals with the BinnenVaart Model Systeem (BVMS). The model
structure of the BVMS is specified in [1]. Focus of this report is the functional
specification of the assignment model. The assignment model is the process to
simulate the interaction between the travel demand and the infrastructure supply.
Basic inputs for the assignment models are:
• trip list, i.e. list of ships with their origin and destination;
• network, namely links and their property.
The ship choice model defined in [2] determines the trip list.
The purpose of the assignment model is to load the trips onto the network, to obtain
reasonable link travel times and to estimate travel costs of a trip from an origin to a
destination (Figure 1).
The structured of this report is as follows. The framework for the assignment model
is described in chapter 2. Chapter 3 deals with the route enumeration module and
chapter 4 with the route cost computation module. Dynamic assignment module,
route selection and the dynamic network model are described in chapter 5. Chapter 6
describes the input and output data of the assignment model.
Trip Data
Assignment
Network
specification
Figure 1:
Modelling framework of the assignment model.
Connection
quality
Specification of the assignment and simulation model
2
The framework for the assignment module
In this chapter the framework for the dynamic assignment module is described. First
we consider the diagram depicted in Figure 2. This figure illustrates the interaction
between the ship choice and the dynamic assignment module in the BVMS
framework.
At the beginning a complete route set is generated by considering the network
specification and the route costs are computed by taking into account the free flow
travel time. The ship choice module generates the trip list by considering the route
set and their initial costs. After that the assignment module is applied and an iterative
process is carried out in order to obtain reasonable route costs and an optimum trip
data set. The iterative process consists of the interaction between the ship choice and
the assignment model for a given number of iterations. As shown in Figure 2 the
assignment and the ship choice modules affect each other. In fact during the iterative
process the ship choice module generates the trip list by taking into account the route
costs updated by the assignment module. On the other hand the assignment module
generates the route costs by considering the trip list provided by the ship choice
module.
Route
Enumeration
Route set
_L
Goods
list
Free flow
travel time
Route cost
computation
Ship
Choice
module
Route cost
Trip data
per
ship type
_L
Network
specification :
Figure 2:
Dynamic
Assignement
module
The interaction between the ship choice and the assignment module in
the BVMS framework.
Specification of the assignment and simulation model
The interaction between the assignment and the ship choice module for a time period
AT is shown in Figure 3. Let be AT=IAt and At is the running time for the
assignment model. At the beginning a route set is generated and the route costs are
determined by considering the free flow travel time. Then the ship choice module is
applied and a trip list is determined. After that the dynamic assignment module is
carried out and the interaction between the route choice model and the dynamic
network loading model is iterated for the time period At.
The time period At may represent one day (from 0.00 to 24.00) or one week (from
Monday to Sunday) or one year. It depends on the performance of the assignment
module: how many times the assignment module can be carried out without spending
too much time. At the end of that time period the execution of the assignment
module stops and a feedback is returned to the ship choice model. The feedback
consists of the route costs updated by the assignment model. In order to determine a
new trip list, the ship choice model is called again by taking into account the new
input data. Then the assignment module is iterated until the next period At elapses
and a new feedback for the ship choice module is computed. This process is iterated
for the full time period AT.
At
Route
set
Ship
choice
module
_2AL
•
~>
Assignment
module
r
Route
cost
jtt
Assignment
module
"^
Assignment
module
Figure 3:
Iterative process for the ship choice and the assignment module
interaction.
Specification of the assignment and simulation model
3
Route enumeration module
In this chapter the route enumeration module will be described. The input of the
module is the network specification. As discussed in chapter 2 the complete route set
is generated only once at the beginning of the simulation. The complete route
enumeration is probably a feasible approach because of the sparseness of the BVMS
network. As the BVMS network has not specified yet the algorithm for the route
enumeration cannot be described in this phase.
Figure 4 depicts a route from O to D with three movable bridges with a fixed part.
Dotted links represent the fixed part of the bridges and solid links represent the
movable part of the bridge. The fixed part of the first bridge has a height of 3 metres,
the second one a height of 4 metres and the third one a height of 5 metres. A ship that
has a height less then the bridge height can pass through the fixed part of the bridge
without waiting.
Bridge 1
Figure 4:
Bridge 2
Bridge 3
A route from O to D with three bridges: bridge 1 is 3 metres in height,
bridge 2 is 4 metres in height and bridge 3 is 5 metres in height.
The number of feasible routes from O to D depends on the type of ship travelling
along that route. In the network depicted in figure 4 the number of routes depends on
the ship height. In fact if the ship height is less than 3 metres the ship can pass
through all bridges without waiting. In this case the route from O to D is the
sequence of dotted links in addiction to the link from O to the first bridge and from
the third bridge to D (see route 1 in Figure 5).
Route 1
Route 2
O.
-.D
• D
Route 3
Route 4
Figure 5:
• D
All routes from O to D: the first route is for ship less than 3 metres in
height, the second one is for ship greater than 3 metres and less than
4 metres in height, the third one is for ship greater than 4 metres and
less than 5 metres in height and the last one is for ship greater than 5
in height.
Specification of the assignment and simulation model
If the ship height is greater then 3 metres and less than 4 metres the ship cannot pass
through the first bridge but can pass through the other bridges.
If the ship height is greater then 4 metres and less than 5 metres the ship cannot pass
through the first and second bridge but can pass through the third bridge.
If the ship height is greater then 5 metres the ship cannot pass through all bridges.
All routes from O to D are depicted in Figure 5.
In order to enumerate all routes and avoid a large number of routes we propose to
implement parallel routes as one single route. In the example depicted in Figure 4
only one route is considered from O to D. In this case each height of the fixed part of
the bridge is associated with the route in order to calculate the travel time of the route
for each ship type (see chapter 4).
The route enumeration allows computing optimal routes efficiently. An efficiënt
route representation is important in any assignment method. In fact routes are used
when the shortest path has to be determined.
A route can be represented as a sequence of links. If the number of links is m and the
number of routes is n the route set can be stored in a 0/1 matrix (m*n). The rows of
the matrix represent the network links and the columns the routes (links*routes). If
the route j contains the link i then the element (i, j) of the matrix is 1 otherwise 0. In
such representation, routes are independent of each other but link repetitions can
occur because a link may be used by a large number of routes. In order to avoid link
repetitions a more compact representation of the route set can be obtained by
considering separated route.
<V
c
Figure 6:
Network with two routes from O to D: 0-A-B-D and 0-A-C-D
A separated route is a portion of a route in which each node has exactly two incident
links except the start and/or the end node of the separated route.
Figure 6 shows a network with two routes from the origin O to the destination D; the
two routes share the separated route O-A. Figure 7 shows all separated routes in the
network.
SR2
O _
SR1
A
^v.D
_ ^
SR3
Figure 7:
Network with three separated routes from O to D: SRI = O-A, SR2 =
A-D and SR3 = A-D
Specification of the assignment and simulation model
Therefore all routes can be represented through a 0/1 matrix where rows are
separated routes (SR) and columns are routes (SR*route). If the route j contains the
separated routes i then the element (i, j) of the matrix is 1 otherwise 0. The separated
routes can be also represented through a 0/1 matrix where rows are network links and
columns are separated routes (link*SR). If the separated route j contains the link i
then the element (i, f) of the matrix is 1 otherwise 0. In Figure 8 it is shown that the
matrix (link*route) can be determined as the product of the matrix (link*SR) and
(SR*route).
1 2 . .
Route
1 2 . .
SR
1 2 . .
1
2
Route
1
2
*
—
SR
Link
Figure 8:
Link
Route and separated route representation through 0/1 matrix.
The output of the route enumeration module is the route set.
In chapter 4 route characteristics and route cost computation will be described.
Specification of the assignment and simulation model
4 Route cost computation module
As discussed in chapter 2 the ship choice model assigns goods to ships and generates
the trip list by using the route costs determined by the assignment module. In this
chapter the route cost computation module is described.
The input of the route cost computation module is the route set determined by the
route enumeration. Each route belonging to the route set is distinguished by some
limitations:
1. height is the maximum ship height allowed. It is determined by considering the
minimum height of fixed bridges present along the route.
2. length is the maximum ship length allowed. It is determined by considering the
minimum between the minimum locks length present along the route and the
maximum ship length allowed in the harbour present along the route;
3. width is the maximum ship width allowed. It is determined by considering the
minimum width of the waterways and locks present along the route;
4. depth is the maximum ship depth allowed. It is determined by considering the
minimum depth of the water along the route depending on the seasons.
Moreover routes can have limitations on dangerous goods. The heights of movable
bridge and the width and length of lock chambers are associated with each route. The
characteristics of the routes belonging to the route set are distance, travel time,
waiting time and cost. The travel times and costs structure is specified in [2]. The
route costs depend on the ship costs and also on the waiting time. The waiting time is
the time lost waiting for bridges and locks. If a route contains a movable bridge its
height can be a bottleneck for ships travelling along that route. If a route contains a
lock the length and the width of their chambers can be a bottleneck for ships
travelling along that route.
The waiting time changes during the iterative process because it depends on the
number of ships travelling over the network. The waiting time along a route depends
also on the ship type travelling along that route.
The waiting time of the route depicted in Figure 4 (chapter 3) depends on the ship
height. If a ship travels along that route and its height is less than 3 metres the route
cost is calculated by considering no waiting time. If the ship height is greater than 3
metres and less than 4 metres the route cost is calculated by considering waiting time
only for the first bridge. If the height is greater than 4 metres and less than 5 metres
the route cost is calculated by considering waiting time for the first and second
bridge. Finally if the ship height is greater than 5 metres the route cost is calculated
by considering waiting time for all bridges.
In this case the route costs provided by the assignment module to the ship choice
module are the minimum travel times. In addition to the minimum travel costs the
waiting time for all bottlenecks present along that route are provided. Let we suppose
the waiting time of the route shown in Figure 4 (chapter 3) is w; for the first bridge,
W2 for the second one and ws for the third one. The cost is the travel time of the route
and for each bridge a pair of waiting time and bridge height:
Specification of the assignment and simulation model
1. (wj, 3) for the bridge 1 the waiting time is wj if the ship height is greater than 3
metres otherwise is 0;
2. (w2, 4) for the bridge 1 the waiting time is w2 if the ship height is greater than 4
metres otherwise is 0;
3. (ws, 5) for the bridge 1 the waiting time is w3 if the ship height is greater than 5
metres otherwise is 0;
If a route contains n movable bridges with different heights and m lock chambers
with different width and length the waiting time is associated with each bridge height
and with each width and length of the lock chamber.
Specification of the assignment and simulation model
5
Dynamic assignment module
In this chapter the dynamic assignment module will be described. Figure 3 shows the
zoomed in of the assignment module from Figure 2. The input of the assignment
module is the network specification and the trip list generated by the ship choice
module. As depicted in Figure 3 the assignment model consists of three modules:
first a departure time is associated with each ship trip, then the route of each
departing ship is selected and finally ships are moved over the links of their routes.
The interaction between the route selection and the Dynamic Network Loading
(DNL) is iterated for a given period of time. During this process for each departing
ship the best route where the ship can travel according to the ship attributes and the
route limitations is selected. The DNL updates the link travel times according to the
travel time and waiting time of the ships travelling along the routes. At the end of
this process the route costs for the ship choice model are determined.
In the next sections the route selection and the dynamic network loading model are
described.
Trip data
per ship type
Dynamic Assignement
module
Add departure time
to each trip
per ship type
Network
specification
Route
selection
Dynamic Network
Loading
Figure 9:
The interaction between the route choice and the DNL model in the
assignment framework (zoomed in from Figure 2).
Specification of the assignment and simulation model
5.1 Route selection model
The route selection rules are important for determining outputs of the assignment
module. The selection of the best route along which a ship can travel is determined
based on the prevailing network conditions at the departure time. First of all for each
departing ship all feasible routes are selected. As discussed in chapter 4 each route
belonging to the route set is distinguished by some restrictions such as height, length,
width and depth.
A feasible route for a ship is a route in which the aforementioned attributes are not
constraints for the ship attributes. After selecting all feasible routes the shortest route
is determined according to the link travel times. In the simulation model the shortest
route selection is based on the instantaneous travel time. This means that the best
route is determined by considering the travel times that result if the prevailing travel
times of all route links at the departure time remain constant during the ship trip.
5.2 Dynamic network loading model
As discussed in chapter 1 the aim of the assignment model is to assign ships onto the
network and to calculate the travel costs for all routes. The modelling approach used
for the assignment model is a microscopic event-based simulation. The data flow
diagram of the simulation model is depicted in Figure 10.
At the beginning a specific departure time is associated with each trip; the trip is
inserted in the event list with its origin and its destination. After that an event is
extracted from the list and processed. This process is carried out until either the event
list is empty (i.e. all ships arrive at their destinations) or the running time (At see
chapter 2) of the assignment module elapses. An event can refer to a departing ship
or a moving ship. If the event refers to a departing ship the shortest path is selected,
the ship is moved over the first link of the best route and a new event is generated. If
the event refers to a moving ship over a link then the link travel time is updated in
according to the ship travel time. After that the ship is moved over the next link of its
route and a new event is generated. If the ship arrivés at its destination no event is
generated. At the end of this process the route costs are provided to the ship choice
model.
10
Specification of the assignment and simulation model
Event list
Add departure time
to each trip
per ship type
Trip data
per ship type
Gene rate
event
Select
an event
No
No
Figure 10:
Data flow diagram of the dynamic network loading model (zoomed in
from
Figure 9).
5.2.1 Link travel time
Link travel times are updated according to the ship travel times. Link types of the
BVMS network are waterways, bridges and locks. The travel time of each ship
depends on the waiting time that occurs when ship has to pass through a bottleneck.
In the BVMS network a bottleneck occurs when there are queues for passing through
a bridge or a lock. Link travel times can be updated when ships arrive at the end of
the link. If a link contains a bottleneck link travel times are updated when ships pass
through it. In this case the route with the bottleneck can be selected until the waiting
time of the bottleneck are not updated. In order to avoid the selection of a route with
not updated waiting time link travel times should be updated when ships are waiting.
For the first version of the simulation model link travel times can be updated when
ships arrive at the end of the link. In a later stage the more complex method will be
n
Specification of the assignment and simulation model
considered. In the next sections the travel delay for ships travelling along each type
of link, the bridge and the lock model are described.
5.2.1.1
Ship travelling along a waterway
The majority of network links are waterways. The travel time (7) spent by a ship
travelling along a waterway is equal to the length (L) of the waterway divided by the
speed (5) of the ship. The speed of the ship depends on the water flow. In fact if the
ship is travelling in the same direction of the water flow its speed should be increased
for a quantity ö) that depends on the water flow. If the ship is travelling in the
opposite direction of the water flow its speed should be decreased for a quantity o~2
that we can approximately assume equal to ö). Let set 07 = G2- o.
Therefore the travel time T of a waterway is equal to:
• L/(S+G) if the ship is travelling in the same direction of water
flow
• LJ(S-a) if the ship is travelling in the opposite direction of water flow and S>o
(1)
(2)
If we assume that a waterway has an unlimited storage capacity for ships the travel
delay for each ship does not depend on the number of ships on the link.
A travel delay can occur in a waterway if we consider that the travel time of the
waterway can also depend on the width of the waterway. Depending on the waterway
width one of the following cases may occur.
1. The waterway has four lanes, two for each direction. The width of the waterway
is enough to allow the travelling and the overtaking in both directions. In this
case regardless of the number of ships travelling in the opposite direction the
travel time is equal to (1) or (2). Figure 11 depicts an example: two ships A and
B are travelling in the same direction (with B behind of A) and ta, tb are the travel
time of A and B with tb < ta (B is faster than A). In this case B arrivés at the end
of the link before A, ta and tb will be the travel time of A and B because the
overtaking is always allowed.
B
A, ta
(b)
(a)
Figure 11:
B,tb
A waterway with four lanes. (a) Ship B can overtake A because it is
faster than A. (b) Ship B arrivés at the end of the link before A.
2. The waterway has three lanes one for each direction and one for the overtaking.
The width of the waterway is enough to allow the travelling in both directions but
the overtaking is possible only if there are no ships travelling in the overtaking
lane. In this case the travel time depends on the number of ships in the overtaking
12
Specification of the assignment and simulation model
line. The travel time should be equal to T+A where A is a function of the number
of ships travelling in the overtaking lane their position and speed.
3. The waterway has two lanes one for each direction. The width of the waterway is
enough to allow travelling in both directions but the overtaking is possible only if
there are no ships travelling in the opposite direction. In this case the travel time
depends on the number of ships travelling in the opposite direction. The travel
time should be equal to T+Z where Z is a function of the number of ships
travelling in the opposite direction their position and speed.
4. The waterway has one lane. The width of the waterway is not enough to allow
travelling in both directions and the overtaking is never possible. In this case
there is a bottleneck and a waiting time can occur when ships are travelling in
both directions. The travel time depends on the number of ships travelling in both
directions.
In the simulation model we will take into account that the travel time of a waterway
depends on the water flow. In the first version of the simulation model we will
assume that all waterways allow the overtaking in both direction (first case). In the
second version of the simulation model the first and the second case will be
considered. In the final version of the model we will take into account all four cases.
5.2.1.2
Ship travelling through a bridge
In the BVMS network the following type of bridges are identified:
1. fixed bridge;
2. movable bridge with a fixed part;
3. movable bridge without fixed part.
The bridge height cannot be a limitation for a ship approaching to a fixed bridge. In
fact as discussed in § 5.1 the route is selected by considering the attributes of the
route such as the minimum height of the route. If the ship height is greater than the
bridge height the ship cannot pass through the fixed bridge. Therefore this route is
not feasible and cannot be chosen for that ship. For this reason a ship approaching
through a fixed bridge can pass the bridge without waiting time. In this case the ship
travel time is equal to the time spent by a ship travelling along a waterway.
Movable bridges represent a capacity limitation. Ships that exceed the bridge height
can pass only if the bridge is up, usually one direction at a time. If a ship is
approaching to a movable bridge with a fixed part the ship height has to be compared
to the bridge height. We assume that the bridge height of the fixed part is the same to
the bridge height when it is down. If the ship can pass through the bridge we assume
that the ship can travel under the fixed part of the bridge without waiting time. In this
case the ship travel time is equal to the time spent by a ship travelling along a
waterway. If the ship height is greater of the bridge height the ship has to wait until
the bridge goes up. In this case the waiting time is calculated during the simulation
by taking into account:
• the state of the bridge when the ship is approaching to it (e.g. if the bridge is up
when the ship arrivés the waiting time is null);
• the number of ships in the waiting queues;
• the time necessary to move the bridge and the operated period of the bridge.
13
Specification of the assignment and simulation model
If a ship is approaching to a movable bridge without a fixed part and its height is less
than the bridge height the ship can pass only if no ships are in the waiting queues.
This case is more complex than the previous ones and for sake of simplicity it is not
taken into account during the simulation.
Figure 12 shows the state diagram of a ship travelling through a movable bridge with
a fixed part.
Ship arrivés
Is ship height
greater than
bridge height?
No
Enter Waiting
Queue
Ship can pass
through the bridge
Leave Waiting
Queue
Figure 12:
5.2.1.3
Yes
Waiting for
permission
State diagram for a ship travelling to a movable bridge with a fixed
part.
Ship travelling through a lock
In the BVMS network the following type of locks are identified:
1. lock with one chamber;
2. lock with more chambers.
A lock represents a limited capacity because it can store only a limited number of
ships at a time and it takes some time to serve these ships. The number of ships
allowed in the lock depends on the sizes of the ships. Only one direction can be
served at a time.
If a ship is approaching to a lock with one chamber the ship can pass through the
lock without waiting only if:
• the lock gates are opened in the side of the arriving ship;
• there are no ships in the waiting queue;
• there are ships in the waiting queue and all ships can enter into the lock chamber.
14
Specification of the assignment and simulation model
In other cases the ship has to enter in the waiting queue, to wait until the lock
provides the permission to enter, to enter into the lock, to wait for the water level
changing and finally to leave the lock. In this case the waiting time is calculated
during the simulation by taking into account:
• the number of ships in the waiting queues;
• the time necessary to change water level, open/close gates, etc.
A lock with more chambers can have parallel or sequential chambers. For sake of
simplicity in the simulation model only locks with parallel chambers are taken into
account. This case is equal to the previous one except for the selection of the
chamber where the ship can enter. In fact in this case when a ship arrivés at a lock
the most suitable chamber ('kolk') for the ship has to be chosen.
Figure 13 shows the state diagram of a ship travelling through a lock with parallel
chambers.
Ship arrivés
Enter into
the lock
Choose the most
suitable 'Kolk'
Enter Waiting
Queue
Leave Waiting
Queue
Waiting for
permission
J7
Waiting for
finishing lockage
Figure 13:
\ Leave the lock
Wait time
to leave the lock
State diagram for a ship travelling to a lock with parallel chambers.
15
Specification of the assignment and simulation model
5.2.2 Movable bridge model
The diagram in Figure 15 describes the operation of a single movable bridge with a
fixed part. Two queues Ql and Q2 are associated with the bridge. They represent the
waiting queues for the ships waiting in direction 1 and direction 2 (Figure 14). The
bridge is allowed to go up only during a certain period defined by the Operated
Period (OP). When the bridge goes down has to wait a given time before going up,
i.e. the bridge has to be temporarily closed (tmp closed).
The bridge remains down until no ships are waiting, time is not in the OP and it is
not temporarily closed. When ships arrive and the bridge can go up it goes up for one
side because only one queue can be served at a time. The bridge goes up either for
Ql (Q2) side if there is no ship waiting in Q2 (Ql) or for the queue that contains the
ship arrived first if both queues are not empty.
Let be QSide the queue served first. When the bridge is up it is allowed to stay up for
a certain time period defined as the maximum open time. All ships waiting in QSide
can pass through the bridge until the elapsed time is less than the maximum open
time. If the QSide is empty and there is time available to reverse the bridge the ships
waiting in the opposite side are served. This process is carried out until the bridge
has to go down because either the time available for the operated period is elapsed or
there is no ship in the waiting queues.
Direction 2
Direction 1
Figure 14:
Movable bridge with two associated queues. Ships A and B are
waiting in the directionl (Ql) and ship C is waiting in the direction 2
(Q2).
16
Specification of the assignment and simulation model
OP is Operated Period
I
Bridge is down
Ship arrivés
No
Set QSide=Q2
Set QSide=Q1
Wait time
to go up
Bridge is up
for the QSide
Wait until the
ship passes
h=i-
Yes
Wait time
to go down
Set QSide = QOtherSide
Figure 15:
Give permission
to the first ship
in the QSide
State diagram ofa single movable bridge with a fixed part.
17
Specification of the assignment and simulation model
5.2.3 Lock model
The diagram in Figure 17 describes the operation of a lock with a single chamber.
Two queues Ql and Q2 are associated with the lock. They represent the waiting
queues for the ships waiting in direction 1 and direction 2 (Figure 16). Ships can pass
through the lock only during a certain period defined by the Operated Period (OP).
The lock rests until no ship is waiting and the time is not in the OP. When ships
arrive and the time is in OP the lock determines the side to be opened because only
one queue can be served at a time. When the lock rests we assume that the gates are
opened for one direction. Let be QSide the queue in the direction where the gates are
opened during the lock rest. QSide is either Ql or Q2 depending of the last lockage.
The lock selects the Ql (Q2) side if there is no ship waiting in Q2 (Ql), in this case
if the selected side is opposite to QSide the lock has to change the water level.
Otherwise if both queues are not empty ships waiting in the queue QSide (i.e. in the
direction where the gates are already opened) are served first.
All ships waiting in QSide can enter into the lock until the lock is full. Then the gates
are closed, the water level is changed and the gates of the opposite side are opened.
After that the ships into the lock can leave it and the lock goes to rest.
Direction 1
Direction 2
•
A
Figure 16:
<
B
Lock with two associated queues. Ships A and B are waiting in the
directionl (Ql) and ship C is waiting in the direction 2 (Q2). Ships A
and B can enter into the lock because gates are opened in their
direction.
18
Specification of the assignment and simulation model
rWait time to:
- close doors
- change water level
- open doors
Figure 17:
State diagram ofa lock with a single chamber.
19
Specification of the assignment and simulation model
6 Input and output description
The input and output data of the assignment model are specified in [3]. In this
chapter we present some input data that have been modified.
6.1.1 Input data
As depicted in figure 1 the input of the assignment model are a list of trips and the
network data. Each trip has the attributes of the Table 1.
origin and destination of the trip
ship class and ship type used for the trip
category of goods transported by the ship
Dangerous goods transported by the ship
number of 'kegels'
It indicates if the cargo is containerised or not
container indication
the amount of cargo loaded
Description of trip attributes.
Table 1
As discussed in chapter 2 at the beginning of the simulation a departure time is
associated with each trip. In order to generate a departure time a distribution of
departure times for one day is taken into account. The proportion of traffic departing
at a certain time (during the day from 0.00 to 24.00 hours) for each ship class is
another input of the assignment model.
Network data consist of nodes, links and their properties. The origins and
destinations of the trips are nodes. A link can be a waterway, a bridge or a lock.
The data input for the link attributes are described in Table 2.
length of the link
height of the link;
It is equal to °° if the link is a waterway;
It is equal to the bridge height if the link represents a
fixed bridge;
It is the height of the fixed part of the bridge if the link
represents a movable bridge with a fixed part.
It depends on the season; for each season there is a
depth of the link
depth associated to the link
Width allowed to the ship travelling along the link
maximum width
maximum number of 'kegel' Number of 'kegels' that a ship can transport along a
link
Speed allowed to a loaded ship
maximum speed
Speed allowed to an unloaded ship
maximum speed
Length of ship that can make an U-turn on the link
maximum length
It is the number of ships that can travelling per hour in
capacity of the link
the link
A waterway, a fixed or a movable bridge and a lock
type of the link
with one or more chambers
Description of link attributes.
Table 2
20
Specification of the assignment and simulation model
It indicates if the overtaking is allowed
or not in the waterway (see § 5.2.1.1);
It indicates the speed of the water flow, it
water flow speed
can be positive or negative depending on
the direction of the water flow (see §
5.2.1.1);
Table 3
Description of waterway attributes.
overtaking
A waterway has the link attributes and the attributes described in Table 3.
A fixed bridge is a link with the height equals to the bridge height. As we discussed
in § 5.2.1.2 only a movable bridge with fixed part is taken into account in the
simulation model. A movable bridge has the link attributes and the attributes
described in Table 4.
A lock has the link attributes and the attributes described in Table 5.
It indicates when the bridge is allowed to
go up and to block the road traffic over
the bridge;
It indicates the height when the bridge is
up;
operated time
maximum height
time needed to the bridge to go up;
number of directions allowed to pass
through the bridge;
time needed to the ship to traverse the
bridge when the ship had to wait;
time needed to the ship to traverse the
bridge when the ship did not have to
wait;
time needed to the bridge to reverse
allowed direction under the bridge;
maximum time allowed to block road
traffic over the bridge;
minimum required period between two
operated periods.
Table 4
Description of bridge attributes.
6.1.2 Output data
The assignment model predicts for each link and ship class the travel time spent by
the ship to travel that link and the number of ships travelling on that link. The model
predicts also for each ship class and OD pair the cost for travelling from O to D
along a specifïc route. The output data of the assignment model are specified in [3].
21
Specification of the assignment and simulation model
It indicates when the lock is active and
can change the water level;
operated time
number of chambers of a lock
for each chamber of the lock;
width of the chamber
for each chamber of the lock;
length of the chamber
for each chamber of the lock;
time needed to change water level
time needed to the lock to open and to
close the gates;
time needed to the ship to go into the
lock when the ship had to wait;
time needed to the ship to go into the
lock when the ship did not have to wait;
time needed to the ship to leave the lock;
time between two consecutive ships
leaving the lock.
Table 5
Description of lock attributes.
22
Specification of the assignment and simulation model
7
References
[1] Zijpp, N.J. van der, K. Lindveld, T. Dijker, Functionele specificatie
Modelsysteem Inland shipping versie 2.0: Identificatie in- en OUTPUT, i.o.v. TNOInro/AVV, 4 October 1999
[2] Lindveld, CH.D.R. Functional Specification of the BVMS Version 0.5:
Specification of the ship type and route choice model —Draft— TNO-Inro/AVV,
2000
[3] Zijpp, NJ. van der, K. Lindveld, Functional Specification Modelsystem Inland
Shipping Version 0.2: Identification Input and Output, and Database Definition,
TNO-Inro/AVV, 1999
23
ESRI Nederland
RAPPORTAGE 'USER INTERFACE' - FASE 2
Binnenvaart Modelsysteem
Opdrachtgever
RWS/AVV
Opdrachtnemer
ESRI Nederland B.V.
Contactpersoon
H. Uitenboogaart
Auteur
Datum
Versie
Status
Bert Vermeij
21 februari 2001
0.1 (build2)
Concept
Versie: 0.1
Rapponage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 1 van 19
ESRI Nederland
Versie-overzicht
;;
Versie IDatiÉii&ft.fil Reden aanpassing ^#|:tt?£/ l
0.0.1
19 februari
Initieel
L.W.V.
0.1
21 februari
Concept
L.W.V.
Distributielijst
Datum •ïKt' tT[ Fersom
21 februari
Versie: 0.1
Organisatie
H. Uitenboogaart
TNO Inro
M. van der Goot
ESRI Nederland
L. Schaminee
ESRI Nederland
B. Vermeij
ESRI Nederland
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 2 van 19
ESRI Nederland
INHOUDSOPGAVE
1
INLEIDING
4
2
CASEBEHEER
5
3
4
2.1
Doel casebeheer
5
2.2
Definities en afspraken
5
2.3
Database en casebeheer
6
2.4
Werkwijze modelberekening
6
2.5
Structuur user interface casebeheer
7
2.6
Functionaliteit casebeheer
8
2.7
Aanmaken cases en varianten
8
2.8
Instellen parameters
10
DATABASE
13
3.1
Van database fase 1 naar database fase 2
13
3.2
Netwerk
13
3.3
Netwerkeisen rekenmodel
13
3.4
Beschikbare data
14
3.5
Datamodel Arclnfo
15
3.6
Modellering BVMS netwerk in Arclnfo
16
3.7
Oplossen discrepanties ViN - rekenmodel
16
3.8
Aanlevering Netwerk
17
INTEGRATIE MATHLAB REKENMODULES
18
4.1
MathLab en Arclnfo
18
4.2
Aansturing MathLab
18
4.3
Presentatie MathLab resultaten
18
Versie: 0.1
Rapportage'User Interface'- Fase 2
Binnenvaart Modelsysteem
pagina 3 van 19
ESRI Nederland
1
Inleiding
In het BVMS consortium is ESRI Nederland verantwoordelijk voor de ontwikkeling van de user
interface en de database. Omdat het Binnenvaart Modelsysteem een belangrijke geografische
component kent, is in fase 1 besloten om een GIS omgeving (Arclnfo) als basis te gebruiken voor
zowel de user interface als de database.
Om redenen van efficiency en beheersbaarheid zijn de werkzaamheden aan de database en de
interface in fase 2 op te splitsen in drie sporen:
• Casebeheer
• Integratie rekenmodules
• Database
Het spoor casebeheer omvat het behren van de modelberekeningen, waaronder begrepen het
instellen van de invoerparameters voor de modelberekeningen. Een tweede cluster van
werkzaamheden betreft het opbouwen en inrichten van de database op basis van de specificaties
volgens het 'Memo Databeschikbaarheid'. Binnen dit cluster is met name veel tijd besteed aan
het op orde krijgen van het netwerk, als drager van de database en het model.
Als laatste cluster is er de integratie van de rekenmodules -nu nog in MathLab- in de interface.
Deze drie sporen hebben vanzelfsprekend nauwe onderlinge relaties. Sommige relaties zijn nu al
aanwezig, bijvoorbeeld bij het instellen van de invoerparameters, waar bepaalde variabelen in de
database aangepast worden. Andere relaties kunnen pas in de volgende fase gerealiseerd worden.
De rekenmodules in MathLab werken op basis van een beperkte (MathLab) testdatabase en niet
op de Arclnfo database.
In deze rapportage wordt per onderdeel gerapporteerd over de resultaten.
Voor de presentatie van uitvoerresultaten wordt in de huidige versie van de BVMS software
gebruik gemaakt van de standaardfuncties van Arclnfo. Op basis van de gegevens in de database
stelt de gebruiker kaarten, lijsten of grafieken samen. Het is de bedoeling om in de definitieve
versie van BVMS diverse voorgedefinieerde outputproducten op te nemen. Het is het meest
zinvol om hierin te investeren als de database en de Tekensoftware (vrijwel) hun definitieve vorm
hebben bereikt.
Er is een aantal voorbeelden van outputproducten in deze rapportage opgenomen.
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 4 van 19
ESRI Nederland
2
2.1
Casebeheer
Doel casebeheer
Het casesbeheer is een van de kernfuncties van de user-interface. Het doel van deze functie is het
kunnen definiëren van modelruns en het omgaan met de in- en uitvoer van modelberekening.
Bij de ontwikkeling van dit deel van de interface is de door AVV gehanteerde werkwijze bij het
maken van een modelberekening als uitgangspunt genomen.
2.2
Definities en afspraken
De begrippen "variant", "case", "project", "scenario" worden binnen het BVMS project
veelvuldig door elkaar gebruikt. Met alle begrippen wordt wel een combinatie van invoer en
uitvoer bedoeld. Voor het bouwen van een heldere user interface is allereerst helderheid over de
terminologie vereist.
Ook is het noodzakelijk om duidelijkheid te krijgen over welke combinaties van in- en uitvoer er
binnen het BVMS moeten worden onderscheiden en welke naamgeving wij voor al deze
onderscheiden combinaties hanteren.
De invoer voor een BVMS-run kan als volgt worden geclassificeerd:
1. invoer die door de gebruiker niet gewijzigd hoeft te worden, zoals bijvoorbeeld de
goederenstromen in het basisjaar. Deze gegevens liggen vast in een deel van de database waar
de gebruiker in principe geen toegang toe heeft.
2. modelparameters die tijdens de calibratie door de TUD zijn vastgesteld en die door de
gebruiker niet gewijzigd mogen worden, daar anders de validiteit van de modelresultaten
bedreigt wordt. Ook deze gegevens liggen vast in een deel van de database waar de gebruiker
in principe geen toegang toe heeft.
3. gegevens die exogene ontwikkelingen beschrijven waar geen invloed op kan worden
uitgeoefend door maatregelen te nemen ten aanzien van de binnenvaart of het
binnenvaartnetwerk, zoals de gegevens uit de CPB-scenario's. Deze exogene gegevens
kunnen door de gebruiker gewijzigd worden, bijvoorbeeld door een ander CPB-scenario te
kiezen. Gemakshalve zullen wij voor de verzameling exogene gegevens ook de naam
scenario gebruiken.
4. gegevens die mogelijke oplossingen en/of maatregelen beschrijven waartoe de overheid zou
kunnen besluiten, bijvoorbeeld het uitbreiden van sluiscapaciteit, het verdiepen van een
vaarweg of het aanleggen van een nieuwe containerterminal. Deze endogene gegevens zijn
ook te wijzigen door de gebruiker en vormen samen een deel van de database die wij variant
zullen noemen.
Het is relevant om onderscheid te maken tussen exogene en endogene gegevens (punt 3 en 4
respectievelijk), omdat de gebruiker in staat moet zijn om oplossingen te kunnen evalueren tegen
de achtergrond van verschillende scenario's voor exogene ontwikkelingen. Deze evaluaties
kunnen dus gemaakt worden door varianten te combineren met scenario's voor een gegeven vaste
set van invoergegevens en modelparameters (punt 1 en 2).
De user-interface zal dus passende functionaliteit moeten bieden om de relevant exogene en
endogene variabelen in te kunnen stellen.
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 5 van 19
ESRI Nederland
2.3
Database en casebeheer
De verzameling van vaste gegevens (punt 1 en 2) zijn samen met standaardinstellingen voor de
exogene en endogene variabelen vastgelegd in een basisjaar. Het model is gecalibreerd voor
deze verzameling gegevens, vandaar dat het basisjaar door de gebruiker nooit gewijzigd mag
worden.
In specifieke situaties is het denkbaar om de basissituatie te kunnen wijzigen. Bijvoorbeeld als
een containerterminal wordt toegevoegd, waardoor een BVMS-zone in twee stukken moet
worden opgesplitst. Daartoe is het projectbasis]aar, geïntroduceerd, zijnde de basisgegevens
(punt 1 en 2) die voor een specifiek project zijn aangepast. In veel gevallen zal dit
projectbasisjaar gelijk kunnen zijn aan het gewone basisjaar, maar het laat de mogelijkheid van
structuurwijzigingen open zonder dat de database van het basisjaar wordt gewijzigd. De gegevens
uit het projectbasisjaar, tezamen met alle scenario's en varianten die voor een project beschouwd
zijn, worden in de database vastgelegd als een project.
Samengevat bestaat de database uit de volgende onderdelen:
1. Basisjaar, het basisjaar betreft de in- en uitvoer van het jaar (voor het huidige BVMS is dit
1992) waarop het uiteindelijke binnenvaart model gekalibreerd is.
2. Projectbasisjaar; Het basisjaar dat voor een project gebruikt zal worden. In veel gevallen zal
dit projectbasisjaar gelijk zijn aan het gewone basisjaar, maar het is mogelijk dat er
bijvoorbeeld een andere zone-indeling wordt gehanteerd. Door gebruik te maken van een
project-basisjaar worden structuurwijzigingen toegelaten zonder dat de kern van de database
(het basisjaar) wordt gewijzigd.
3. Scenario; een scenario betreft een vertaling van de exogene variabelen van het basisjaar op
grond van mogelijke exogene ontwikkelingen (bijvoorbeeld op basis van de verwachte
economische groei)
4. Variant; een planvariant of kortweg een variant betreft een aanpassing van de endogene
variabelen van het basisjaar als reactie op mogelijke exogene ontwikkelingen (zoals
vastgelegd in een scenario).
5. Project; het project betreft een groepering van in- en uitvoer gebaseerd op een bepaalde
beleidsvraag. Dit is de combinatie van één projectbasisjaar met een verzameling bijbehorende
scenario's en varianten.
2.4
Werkwijze modelberekening
Een modelberekening loopt in grote lijnen als volgt.
1. Er is een basissituatie, basisjaar genoemd. Op dit moment is 1992 het basisjaar.
2. Vervolgens is er een beleidsvraag. Daarvoor start Adviesdienst Verkeer en Vervoer een
project.
3. Bij een project hebben we te maken met twee soorten 'variabele parameters'. Exogene
factoren, bijvoorbeeld economische groei en meer directe veranderingen in het
scheepvaartgebeuren, bijvoorbeeld verbreding van een waterweg (= vergroting
capaciteit), vergroting van een sluis, andere schepen waardoor ander belading, afsluiten
van een vaarweg voor schepen met bepaalde goederen (gevaarlijke stoffen) etc. Dit
noemen we endogene factoren. In een project zitten altijd beide (als er niets verandert is
de verandering 0).
4. In een modelberekening start men altijd met de exogene groei. Dit noemt men een
scenario.
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 6 van 19
ESRI Nederland
5. Vervolgens wordt er gesleuteld aan inputparameters uit de scheepvaart. Dit kunnen zowel
veranderingen aan geografische objecten zijn (vaarweg, sluis, brug) als aan nietgeografische (belading). Dit noemen we een variant.
6. Een slag door het hele model (dus combinatie scenario + variant) noemen we een case.
Een project bestaat dus altijd uit een combinatie van een of meer varianten en scenario's. Een
combinatie van een bepaald scenario met een variant noemen we een case.
De output voor het projectbasisjaar wordt bij het projectbasisjaar bewaard, de output voor een
prognosejaar wordt bij elke combinatie van scenario en plan variant vastgelegd. Let wel: elk
scenario heeft betrekking op slechts één prognosejaar! Indien de gebruiker informatie wil hebben
over een ander prognosejaar, moet hij een nieuw scenario aanmaken. In BVMS zal dit niet
overbodig arbeidsintensief zijn, bijvoorbeeld door het kopiëren en wijzigen van scenario's goed te
faciliteren.
2.5
Structuur user interface casebeheer
De structuur van de user interface voor het casebeheer komt overeen met de structuur van de
database. Elk project heeft één projectbasisjaar, afgeleid van (en vaak gewoon gelijk aan) het
basisjaar 1992. Exogene ontwikkelingen tot aan één prognosejaar zijn weergegeven in een
scenario en endogene ontwikkelingen in een variant.
Er is gekozen om de user interface te bouwen met de metafoor van 'mappen', dus als de
Windows Expolorer. Gebruikers zijn immers gewend om hun informatie op computers in mappen
te beheren.
Er is per project een map, met daarin één of meer mappen met verschillende scenario's en per
scenario een of meer mappen met varianten. In de map scenario komen ook de delta's
(verwijzingen, beschrijvingen) van de exogene factoren, in de map variant de delta's van de
endogene factoren.
Hieronder is de structuur van de database / interface weergegeven.
ÊjD Cataiog
5-{jj> C:\TNO
: B O BasisGeodatabase
: ; 3 Q BasisBVMS.mdb
i i 2 9CopyofBasisBVMS.mdb
i É - O Code
; B Q Demo
! : 3 CD Nieuw Project.bvms
\ ;
B - Q Nieuw Scenario.seen
i :
È " € 3 Nieuwe Variant var
: i
EE-Q Scenario.mdb
;
\ l
3 9 Basis.mdb
Toelichting:
In de map BasisGeodatabase zien we het basisjaar (BasisBVMS). De map 'Demo'
bevat een nieuw project, met binnen dat project een scenario en varianten.
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 7 van 19
ESRI Nederland
In principe moeten binnen een project alle beschikbare varianten met alle scenario's
gecombineerd kunnen worden. In BVMS zal aangegeven worden voor welke combinaties
resultaten aanwezig zijn. Daarnaast kan de gebruiker aangeven voor welke combinaties
berekeningen moeten worden uitgevoerd. In bovenstaande figuur worden de door de gebruiker
geselecteerde, maar nog niet doorgerekende varianten, weergegeven door middel van een "cross
mark" in de desbetreffende "checkbox". Door de gebruiker geselecteerde doorgerekende
varianten worden weergegeven door middel van een "vinkje".
In onderstaande figuur is dat uitgewerkt.
m Basisjaar 1992
-f- fia Project 1
-f- la Project ..
e
Mi Project N
Project Basisjaar
Variant 1
Scenario 1
Scenario.,
Scenario N
2.6
r
F
F
Variant..
F
F
Variant N
r
F
Functionaliteit casebeheer
Casebeheer moet voorzien in de volgende functies:
• Aanmaken cases, eventueel door het kopieren van eerder doorgerekende cases.
• Instellen parameters -de delta (• ).
• Documenteren case (wie, wanneer, waarom)
2.7
Aanmaken cases en varianten
Door op een map te klikken met de rechter muistoets verschijnt een keuzelijst met
verschillende functies. Deze lijst is 'context gevoelig'. Met de functie New kan een
nieuw project, een nieuw scenario of een nieuwe variant worden gemaakt.
Versie: Ö.l
Rapportage'User Interface'- Fase 2
Binnenvaart Modelsysteem
pagina 8 van 19
ESRI Nederland
63 Catalog
Name
è-Q$ CATNO
!
B-£2
BasisGeodatabase
\
\
S - Q BasisBVMS.mdb
;
:
SjQ
CopyofBasisBVMS.mdb
\ É - Q Code
! a-Q M: _
_-0p5S£' vanant
Dfl+C
I Ei D Sr % CORJ»
$--CÖ D a t a b g p aSte
3 - - ^ Geocc ^ ^
...., S£ , .
•?>' Delete
+ 1 J ^ Inteim
É • • & Searc
Rename
Refresh
Vloot wijzigen
>
Folder
Vraag wijzigen
•
Personal Geodatabase
Netweik vwjagen
•
Layer...
^
Search...
Gtoup Layef
(^
Propertfes...
Shapefile...
Coverege Reiaap"is.hip Oass.:
Arclnfo Workspace
dBASE Table
INFO table...
Coverage...
Na het maken van een nieuw project / variant komt een scherm op om deze te documenteren.
Naam variant
JNieuweVaiiant
Metadata:
Eigenaar variant
JBert Vermeji
Betrokkenen
jMarlies van der Goot & Luuk Schaminee
Reden
JTest voor klankbordgroep vergadering
Datum
J30-11-00
OK
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
Cancel
pagina 9 van 19
ESRI Nederland
2.8
Instellen parameters
Interfaces / schennen voor het instellen van de exogene en endogene parameters, dus het
aanmaken veranderingen maken eveneens deel uit van het casebeheer. De belangrijkste variabele
parameters kunnen door de gebruiker van het model veranderd worden. Een deel van de overige
variabelen kan niet gewijzigd worden, een ander deel alleen door de beheerder ('super user') met
de basisfuncties van Arclnfo. In het memo 'databeschikbaarheid' is aangegeven welke variabelen
door middel van de casebeheer interface door de eindgebruiker ingesteld kunnen worden.
Het oproepen van de parameters die men wil instellen gaat ook via de rechter muisknop. Ga op de
betreffende variant staan, klik de rechter muistoets en er komt een keuzelijst op met onder meer
de variabelen die men kan / wil wijzigen.
g j Catalog
3 - { ^ C:\TNO
I E-C3 BasisGeodatabase
I i É - Q BasisBVMS.mdb
\ \ Sf3CopyofBasisBVMS.mdb
| ® CU Code
\ E - ü Demo
! ! E CD Nieuw Project.bvms
i i
5B-'~3 Nieuw?
-~~~-~
| \
È - 9 Basis.m
Copféer varianï
\ i - D MXDs
i l Copy
\ a - C l Shapefiles
.g| ? ^
È - Q g Database Connectie
s.~"""
É-I3& Geocoding Service: ^ fièlete
S - ^ Internet Servers
Renarne
È - - 0 Search Results
Belresh
^
Name
" j Scenario.mdb
Dri+C
Qf!+V
Vbotw^en
•
Folder
Vraag wflzigen
>
Personal Geodatabase
Netwerk wqzigen
•
Layer...
Search...
R|» Properties...
G.roup Layer
Shapefile...
Cover^ge Relabcf%hip Oass..
Arclnfo Workspace
^BASE Table
INFO table...
Coverage...
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 10 van 19
ESRI Nederland
Allereerst kan de gebruiker kiezen of hij gegevens wil wijzigen over de vloot, over de vraag (HBmatrices) of aan het netwerk. Kies daarna binnen de opgegeven groep de gewenste variabele en er
verschijnt een bijpassend invulscherm.
Hieronder is als voorbeeld een scherm voor het wijzigen van de transportvraag van / naar een
bepaalde zone, waarbij eventueel met behulp van GIS functies, via de kaart de betreffende
herkomst / bestemmingszone te kiezen is.
MM
^ W i j z i g BVMS zone-zone matrix, binnenvaart
Goederengroep
ZÏ
Herkomst {laadplaats):
Geenselectie
Zoom In
zi
ik
Bestemming {losplaats):
Geenselectie
i
i
4r
^t
-Wijzigingen Extra_tonnen:
Zoom Uit
*-• ., - J
——
C HB-combinade
C Alle herkomsten voor één bestemming
%
C Alle bestemmingen van één herkomst
%
r Wijzigingen Percentage gecontaineriseerd vervoer:
! C HB-combinatie
•f
C" Alle herkomslen voor één bestemming
X
C Alle bestemmingen van één herkomst
%
OK
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 11 van 19
ESRI Nederland
Voor een te kiezen goederengroep, en één , meerdere of alle H-B relaties kan vervolgens het
volume worden aangepast. Tevens is het mogelijk het percentage van de totale stroom dat
gecontaineriseerd is aan te passen.
Het wijzigen van het netwerk, dus van de netwerkschakles (vaarwegen, bruggen, sluizen) en /of
van de kenmerken van schakels gebeurt met de basisfunctionaliteit van Arclnfo. Met de GIS
functies wordt het gewenst deel van het netwerk grafisch geselecteerd of maakt de gebruiker een
selectie op basis van een of meer attributen. De kaart geeft visuele ondersteuning bij het kiezen
van de juiste netwerkcomponenten.
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 12 van 19
ESRI Nederland
3
3.1
Database
Van database fase 1 naar database fase 2
In fase 2 is een fundamentele stap gezet in de ontwikkeling van de database. Het al meermalen
gememoreerde memo 'Databeschikbaarheid' is daar de belangrijkste neerslag van.
De database zoals die in fase 1 in Arclnfo is opgezet is in lijn gebracht met dit memo, hetgeen in
de praktijk neerkwam op een volledige re-design van de database.
De database is geïmplementeerd conform de laatste versie van het memo en kan nu gevuld
worden.
Er is in fase 2 veel energie gestoken in het netwerk. Het netwerk is de basis, de kapstok van het
model en derhalve ook van de database.
3.2
Netwerk
Bij het modelleren van het BVMS netwerk in Arclnfo is rekening gehouden met de volgende
randvoorwaarden:
• De netwerkeisen van het rekenmodel -^ op welke wijze moet het netwerk gemodelleerd zijn
volgens de rekenspecificaties van de TUD;
• De beschikbare data -> is alle data beschikbaar en in welke structuur;
• Het datamodel van Arclnfo -> de interne opbouw van netwerkdata in de Arclnfo software.
3.3
Netwerkeisen rekenmodel
Door de TU zijn de netwerk-kenmerken voor het rekenmodel in zestien tabellen gespecificeerd.
Beschrijving database tabellen netwerkspecificatie
Inhoud
Tabel
bevaarbare verbinding tussen knopen
1.1. schakels
geografische posities
1.2. knopen
lijst die aangeeft welke geografische posities als herkomst fungeren
1.3. herkomsten
lijst die aangeeft welke geografische posities als bestemming fungeren
1.4. bestemmingen
Verzameling van aaneengesloten schakels (vaarwegvakken) die samen een vaarweg vormen. In
1.5. vaarwegen
gebruik voor presentatie-doeleinden
schakel die tevens een stuk vaarweg is
1.6. Vaarwegvakken
schakel die tevens een kolk is
1.7. Kolken
een sluiscomplex is een verzameling bij elkaar horende kolken op één geografische locatie
1.8. Sluiscomplexen
schakel die onder een brug doorgaat
1.9. bruggen
Tabel met bedieningsregime van een sluis of brug per seizoen en dagtype
1.10. bedieningsperioden
Tabel met definitie van bedieningsregimes
1.11. bedieningsregimes
achtergrondbelasting op een schakel t.g.v. recreatieverkeer
1.12. voorbelasting
stroomsnelheid op een schakel per seizoen en frequentieklasse
1.13. seizoensstroomsnelheden
vaardiepte op een schakel per seizoen en frequentieklasse
1.14. seizoensdiepte
frequentieverdeling van de vaarwegdiepte (waterstand) per seizoen, voor het hele netwerk
1.15. frequentie_diepte
Identificatie van telpunten; koppeling met schakels
1.16. telpunt
De tabellen met netwerkspecificaties bevatten elementen die het fysieke vaarwegennetwerk
vormen en aanvullende specifieke kenmerken van bepaalde netwerkelementen.
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 13 van 19
ESRI Nederland
Fysieke netwerkelementen zijn:
•
Vaarwegvakken
•
•
•
Kolken (in sluiscomplexen)
Bruggen
Laad/losplaatsen (herkomsten / bestemmingen)
Vaarwegvakken, kolken en bruggen worden schakels genoemd. Elke schakel heeft een bepaalde
lengte en loopt van knoop naar knoop. Een knoop is een 'geografische positie' waar tenminste
één kenmerk van een schakel wijzigt. Anders gezegd, op een knoop gaat een schakel over in een
andere schakel.
Een reeks aaneengesloten schakels vormt een vaarweg. Een sluiscomplex bestaat uit één of meer
kolken.
Herkomst en bestemming zijn de 'voedingspunten' (laad / losplaatsen) vanuit de zones van de
HB-matrix naar het netwerk. Per HB-zone is er één laad/losplaats.
Op / langs het vaarwegnetwerk liggen telpunten. Deze maken geen deel uit van het rekennetwerk
van het BVMS.
De elementen:
• Bedieningsperiode
• Bedieningsregimes
• Voorbelasting
• Seizoenstroomsnelheden
• Seizoensdiepten
• Frequentie -diepte
dienen om kenmerken van netwerkcomponenten te specificeren.
3.4
Beschikbare data
De databron voor de netwerkgegevens is het ViN (database vaarwegen in Nederland).
Het ViN omvat de volgende objecten:
• Vaarwegvakken
• Bruggen
• Sluizen
• Overige kunstwerken
• LaadAosplaatsen
Naast de opmerkingen m.b.t. de beschikbaarheid van gegevens in de notitie
'Databeschikbaarheid' zijn er voor wat betreft het netwerk een aantal specifieke discrepanties.
1. Vaarwegvakken ViN komen niet overeen met eisen rekennetwerk m.b.t. vaarwegvakken in
die zin dat er geen opsplitsing is van de vaarweg bij bruggen, sluizen etc. Slechts in een
beperkt aantal situaties komt deze opsplitsing wel voor.
Situatie in ViN database:
vaarweg A
O
brug
vaarweg A
Gewenste situatie:
vaarwegvak A
Versie: 0.1
\> J
vaarwegvak B
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 14 van 19
ESRI Nederland
2. Lineaire elementen. In de definitie van de TU is elke fysieke netwerkcomponent (met
uitzondering van de laad/losplaatsen) in principe een lineair element. Een vaarwegvak, een
sluiskolk of een brug hebben allemaal een 'lengte' (Lees: een attribuut waarmee de
passeertijd wordt gerepresenteerd). Bruggen en sluizen zijn in ViN opgenomen als
puntobjecten.
3. Laad / losplaatsen. Liggen deels wel op het netwerk en deels niet. Voor de laad/losplaatsen
die in het model fungeren als herkomst / bestemming is dit wel vereist.
4. Laad / losplaatsen niet geïdentificeerd als herkomst / bestemming.
Nadere toelichting
Het ViN bestaat uit vaarwegen, gerepresenteerd als segmenten verbonden door knopen op de
plaatsen waar vaarwegen kruisen. Verdere locationele informatie is opgeslagen als puntlocaties,
dit zijn sluizen, bruggen, opstapplaatsen en andere kunstwerken.
Het voor de modelberekeningen vereiste vaarwegennetwerk maakt echter alleen gebruik van
segmenten en niet van puntlocaties. Dit houdt in dat alle kunstwerken ook als segment dienen te
zijn opgeslagen. Een sluis of brug moet dus gepresenteerd worden als segment met een lengte en
integraal onderdeel zijn van het vaarwegennetwerk. Dat wil zeggen, dat de vaarwegen
onderbroken worden, daar waar een brug, sluis e.d. zich bevinden. Ook op de plaatsen waar
attributen wijzigen vraagt het rekennetwerk om een knoop.
Voorbeeld benodigd netwerk
o====o
o
o
= =
« «
o«««o
o
o
= knoop (kruising vaarwegen of overgang vaarwegelement)
= vaarweg
= brug
- sluis
Verder is voor alle segmenten de maximale breedte en maximale diepte en voor bruggen de
maximale hoogte vereist.
3.5
Datamodel Arclnfo
Arclnfo kent twee samenhangende representaties van een lineair netwerk:
• geometrisch netwerk (set geografische objecten -features- in een lineair systeem)
• logisch netwerk (netwerk schema, bestaande uit edge en junction elementen waarmee
alleen de netlogica wordt beschreven)
Geometrisch netwerk:
Een geometrisch netwerk is dus een systeem van edge-features en junction-features. Een edge
heeft twee junctions, een junction kan verbonden zijn met een willekeurig aantal edges.
Logisch netwerk:
Verzameling van verbonden edges en junctions. Logisch netwerk heeft geen coördinaten.
Hoofdfunctie is opslaan en beheren van de netwerklogica (connectivity).
Netwerk elementen worden opgeslagen in edge table en junction table, in de bijbehorende
connectivity table wordt vastgelegd hoe de netwerkelementen met elkaar verbonden zijn.
Edges en junctions hebben geen coördinaten; zijn dus geen features.
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 15 van 19
ESRI Nederland
Er is 1:1 of 1 :n relatie tussen netwerk features in het geometrisch netwerk (geografische
representatie van het netwerk) en netwerk elementen in het logische netwerk (netlogica).
Netwerkcomponenten Arclnfo
• simple edge: één edge in logisch netwerk
• simple junction: één node in logisch netwerk
• complex edge: willekeurig aantal edges in logisch netwerk (keten)
• complex junction: verzameling junctions en edges in logisch netwerk
Voor simple edge en simple junction features geldt dat er een één op één overeenkomst is tussen
een feature in een geometrisch netwerk en element in het logisch netwerk.
Complex edges maken het mogelijk om te grote / ongwenste 'fragementatie' van geografische
netwerk features te voorkomen. Complex edges staan toe dat 'dynamisch' op willekeurige
plaatsen junctions worden geplaatst op een edge, zonder nieuwe fysieke edges te hoeven maken.
Complex junction wordt gebruikt om 'netwerken binnen netwerken' te modelleren (bijvoorbeeld
een schakelstation in een leidingnet).
Voor het verder definiëren van de netwerklogica kunnen edges en junctions voorzien worden van
gewichten. (Kosten, weerstand om door edge of junction te stromen). Gewichten / weerstanden
worden opgeslagen met het logische netwerk.
3.6
Modellering BVMS netwerk in Arclnfo
Bij het modelleren van het vaarwegennetwerk in Arclnfo is zoveel mogelijk uitgegaan van de
beschikbare data in ViN, binnen de structuren van Arclnfo.
Dit impliceert:
• definiëren van een Arclnfo netwerk
o geometrisch is het netwerk zoveel mogelijk gebaseerd op ViN
o de gegevens die te maken hebben met de modeleisen worden vastgelegd in het
logisch netwerk (kenmerken als doorvaartijd, stroomsnelheid e.d.)
• vaarwegvakken zijn edge feature (simple edge)
• bruggen en sluizen zijn edge feature (simple edge)
• laad/losplaatsen zijn junction feature (simple junction)
• vaarweg is object (geen geometrie, alleen attributen)
• schakel is object van type vaarwegvak, sluis of brug
• kolk is object (sluis - kolk is 1 : n)
• overige kenmerken als seizoendiepte, voorbelasting zijn eveneens objecten.
Vanuit het Arclnfo netwerk wordt een rekendatabase aangeleverd aan de QQQ rekenmodule. In
deze rekendatabase worden de Arclnfo features en objecten vertaald naar een structuur die voor
het rekenwerk het best past.
3.7
Oplossen discrepanties ViN - rekenmodel
De gesignaleerde discrepanties tussen ViN en de BVMS-database worden als volgt opgelost.
1. Vaarwegvakken
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 16 van 19
ESRI Nederland
Definiëren Arclnfo netwerk. Vaarwegvakken, bruggen etc. als edge feature.
Laden vaarwegen uit ViN ('vaartraject.shp') naar vaarwegvakken
Laden bruggen etc. uit ViN. 'Lineaire kenmerken' als lengte maar ook doorvaartijden etc.
daarbij opnemen.
2. Laad/losplaatsen op netwerk.
In principe hoeven alleen de laad / losplaatsen die herkomst / bestemming (voedingspunt
HB-zone) zijn fysiek op het netwerk te liggen. Handmatig editen.
Adviesdienst Verkeer en Vervoer moet aangeven welke ViN laad / losplaats herkomst /
bestemming zijn. Door NEA is een voorlopige lijst aangeleverd.
3.8
Aanlevering Netwerk
AVV werkt op het moment van schrijven van dit rapport (medio februari 2001) aan het
aanleveren van een netwerk conform deze specificaties. Het netwerk wordt opgebouwd uit de
NWB-V database.
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 17 van 19
ESRI Nederland
4 Integratie MathLab rekenmodules
4.1
MathLab en Arclnfo
Er is in MathLab een prototype van het uiteindelijk te bouwen rekenmodel gemaakt. Dit
prototype is primair bedoeld om de opgestelde modelspecifïcaties te toetsen. MathLab maakt
geen gebruik van de 'echte' BVMS database (in Arclnfo) maar van een beperkte testdatabase.
Deze testdatabase bevat onder meer een klein netwerk en een aantal H-B matrices tussen de zones
in het netwerk.
Zolang er nog geen 'echte' modelsoftware is, maar wordt gewerkt met MathLab prototypes is het
koppelen met het netwerk en de andere variabelen uit BVMS database nog niet opportuun.
De integratie van de MathLab rekenmodules bestaat in fase 2 derhalve uit de volgende elementen:
•
•
4.2
Aansturing van het MathLab model vanuit de Arclnfo interface
Presentatie MathLab modelresultaten in Arclnfo
Aansturing MathLab
Het aansturen gebeurt met behulp van een ddl die in Arclnfo wordt gehangen.
Vanuit Arclnfo kan het model dan gestart worden.
De MathLab software toont de voortgang van de berekening met een progress bar. Het is
mogelijk de berekening onderwijl te stoppen.
Invoegen: screenshot MathLab en progress
MathLab schrijft de resultaten in tabellen, die vervolgens in de Arclnfo database ingelezen
worden.
4.3
Presentatie MathLab resultaten
In Arclnfo worden de door MathLab gegenereerde resultaten gevisualiseerd. Daarvoor wordt
gebruik gemaakt van de tabellen:
BaseNode, ForeCastNode (de knopen / voedingspunten op het netwerk in X,Y coördinaten)
BaseLink en ForeCastLink (de netwerkschakels tussen de knopen)
BaseDemand en ForeCastDemand (de vraag)
BaseLinkLoad en ForeCastLinkLoad (de belasting op het netwerk)
Arclnfo genereert uit de tabellen BaseNode en BaseLink (en ForeCastNode en ForeCastLink) een
netwerk. Door de LinkLoad te koppelen aan de schakels kan de belasting op het netwerk getoond
worden.
Als voorbeeld van voorgedefinieerde output maakt Arclnfo een vergelijking van de LinkLoad in
het basisjaar en het prognosejaar en toont deze in de vorm van een verschilkaart. In de
verschilkaart worden de geclassificeerde verschillen in de belasting op de vaarwegsegmenten in
een oplopende kleurenreeks gevisualiseerd.
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 18 van 19
ESRI Nederland
Invoegen: screenshot verschilkaart
Naast deze standaardkaart kunnen uit de database naar wens allerlei kaarten samengesteld
worden.
Dat de sporen 'modelontwikkeling' en 'database' met elkaar zijn afgestemd kan worden
geillustreerd door in de kaart ook andere gegevens te tonen. Onderstaand voorbeeld toont de
verschilkaart in combinatie met het volledige BVMS netwerk.
Invoegen: screenshot verschilkaart in combinatie met BVMS netwerk
Versie: 0.1
Rapportage 'User Interface' - Fase 2
Binnenvaart Modelsysteem
pagina 19 van 19
QQQ Delft - Rap92
Softwarespecificatie
Toedelingsmodule BVMS Fase 2
Alle rechten voorbehouden.
Niets uit deze uitgave mag worden
vermenigvuldigd en/of openbaar
gemaakt door middel van druk,
fotokopie, microfilm of op welke
andere wijze dan ook, zonder
voorafgaande toestemming van
QQQ Delft
©2001 QQQ Delft
QQQ Delft
Kluyverweg 2a
2629 HT Delft
T: 015-2682581
F: 015-2682591
W: http://www.qqq.nl
18 januari 2001
Auteurs:
ir. J.K. de Haan,
ir. G.F. Zegwaard
1.
INLEIDING
3
2.
TOEDELINGSMODULE
4
3.
KOPPELINGEN TUSSEN MODULES
5
3.1
Koppeling met simulatiemodel
3.1.1
ReisRoute
3.1.2
ReisLinkStartTijd en ReisLinkEindTijd
3.2
Koppeling met database
3.2.1
ScheepsKlasse informatie
3.2.2
Netwerk informatie
3.2.3
Algemene informatie
5
5
5
5
5
5
6
A.
DATAFLOW DIAGRAMMEN
7
B.
DATADEFINITIE
B.l.
B.2.
B.3.
C.
Cl.
C.2.
C.3.
C.4.
C.5.
Variabelen
Indices
Enumeratiewaarden
IMPLEMENTATIE
Hoofdmodules
Toedelingsmodule
Simulatiemodel
Externe informatie
Overige modules
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
13
13
17
18
19
19
19
19
20
20
1.
Inleiding
Dit document beschrijft de softwarespecifïcaties van de simulatie toedelingsmodule een
onderdeel van BVMS. De toedelingsmodule kan opgesplitst worden in drie deelmodules: de
routeselectie module, het simulatiemodel en een module die de gemiddelde reisduur bepaald.
Het simulatiemodel wordt op een gedetailleerder niveau beschreven "Softwarespecificatie van
het simulatie-framework".
Hoofdstuk 2 van dit document geeft een tekstuele beschrijving van de toedelingsmodule.
Hoofdstuk 3 gaat in op de koppeling tussen de verschillende (sub)modules. Appendix A geeft
een gedetailleerde beschrijving van de toedelingsmodule in dataflow diagrammen. Appendix B
beschrijft de datadefmitie en appendix C geeft een beschrijving van de implementatie aan de
hand van de verschillende modules.
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
2.
Toedelingsmodule
Dit hoofdstuk geeft een korte beschrijving van de toedelingsmodule. Voor een meer
gedetailleerde specificatie in de vorm van dataflow diagrammen wordt verwezen naar appendix
A. Een beschrijving van de huidige implementatie van de toedelingsmodule is te vinden in
appendix C.
De toedelingsmodule bepaalt aan de hand van alle gegenereerde reizen wat de netwerkbelasting
is. De toedelingsmodule krijgt deze reizen als invoer vanuit de scheepskeuze module en alle
mogelijke routes vanuit de route enumeratie module. Daarnaast wordt statische informatie, zoals
scheepsklasse informatie, netwerk informatie en algemene informatie, verkregen vanuit een
externe database. Als uitvoer levert de toedelingsmodule gemiddelde reislengtes en -wachttijden
per scheepskeuzeperiode van herkomst/bestemming combinaties aan de scheepskeuze module.
;
2.
.\
Route
j
enumeratie
\^
y
mogelijke routes
i.
Scheepskeuze
'
Scheepsklasse
informatie
reizen
T
~4
Toedelings
module
*--—
•
.>
*
gemiddelde reislengtes
gemiddelde reiswachttijden
Algemene
informatie
-'
Netwerk
informatie
De scheepskeuze module en de route enumeratie module zijn in deze fase nog niet
gespecificeerd en bestaan in de huidige implementatie uit eenvoudige objecten die informatie
direct uit een invoer database lezen. Voor meer informatie over de implementatie wordt
verwezen naar appendix C.
De toedelingsmodule kan globaal worden opgedeeld in drie onderdelen: een routeselectie
module, het simulatiemodel en een module die de gemiddelde reisduur bepaald. Het
belangrijkste onderdeel hierin is het simulatiemodel dat uitgebreid wordt beschreven in
"Softwarespecificatie van het simulatie-framework". De routeselectie module kiest een route uit
de door de route enumeratie module aangereikte reeks van kandidaat-routes. De module die de
gemiddelde reisduur bepaald, doet dit aan de hand van alle reistijden die door het
simulatiemodel bepaald zijn.
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
3.
Koppelingen tussen modules
Dit hoofdstuk beschrijft de koppelingen tussen de deelmodules van de toedelingsmodule en de
koppeling met de database.
3.1
Koppeling met simulatiemodel
Het simulatiemodel is gekoppeld met de routeselectie module en de module die de gemiddelde
reisduur bepaald. In de dataflow diagrammen (zie appendix 0) worden deze koppelingen
aangeduid met ReisRoute, ReisLinkStartTijd en ReisLinkEindTijd.
3.1.1 ReisRoute
Op het moment dat het simulatiemodel een nieuwe route nodig heeft (een schip ontvangt een
BM_INIT bericht), vraagt het simulatiemodel aan de routeselectie module een nieuwe route op.
De routeselectie module geeft in dit geval niet de route per link terug, maar als object in één
keer. Deze route objecten worden tijdens de initialisatie aangemaakt door de routeenumeratie
module en bevatten zowel linknummers als pointers naar de bijbehorende Collection in de
simulatiemodule en een richting.
3.1.2 ReisLinkStartTijd en ReisLinkEindTijd
Om de gemiddelde reisduur te kunnen bepalen (zie appendix 0 module 4.3) en om de snelste
route te selecteren (zie appendix 0 module 4.1), zijn de start- en eindtijden van alle links die
gepasseerd worden tijdens een reis nodig. Op het moment dat een schip een link binnenkomt
wordt de ReisLinkStartTijd opgeslagen. Bij het verlaten van een link wordt ook de
ReisLinkEindTijd opgeslagen en wordt het verschil (passeertijd) doorgegeven aan de
routeselectie. Om de snelste route te bepalen zijn immers niet zozeer deze beide tijden van
belang als wel het verschil tussen de twee. De routeselectie bewaart vervolgens de totalen per
link in het netwerk. Module 4.3 maakt in de huidige versie nog geen gebruik van een dergelijk
mechanisme maar vraagt alle ReisLinkStartTijden en ReisLinkEindTijden op, op het moment
dat de gemiddelde reisduur bepaald wordt.
3.2
Koppeling met database
Tijdens de initialisatie worden de gegevens uit de database ingelezen in een CScheepsKlasse,
een CNetwerk en een CAlgemeen object. De toedelingsmodule verkrijgt de benodigde gegevens
door middel van operaties op deze objecten. Het simulatiemodel initialiseert objecten (Bruggen,
Vaarwegen, Sluizen en Schepen) met een pointer direct naar de ingelezen datastructuren.
3.2.1 ScheepsKlasse informatie
De scheepsklasse informatie wordt ingelezen uit de ScheepsKlassen tabel en opgeslagen in een
vector van CSchKlasseParams objecten.
3.2.2
Netwerk informatie
De netwerk informatie wordt ingelezen uit de Bruggen, Kolken, LinkMaxDiepte, Links, Sluizen
en Vaarwegen tabellen en opgeslagen in vectoren van CVaarwegParams, CBrugParams,
CSluisParams en CLinkParams. Waarbij CSluisParams een vector van CKolkParams bevat.
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
3.2.3 Algemene informatie
De algemene informatie bestaat vooralsnog uit een enkele variabele (SchKeuzePeriode) die
wordt ingelezen uit de Algemeen tabel.
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
A. Dataflow diagrammen
Sch.klasse
informatie
HBRoutes(bf, h, b, mr. Inr)
ReisHerkomst(bf. r)
ReisBestemming(bf, r)
jTijd(bf, r)
ReisK
^
ReisSeizoen(bf. rf~
ReisSchKlasse(bf, r)
SchKlasseHoogte(sk)
SchKlasseBreedte(sk)
SchKlasseLengte(sk)
SchKlasseDiepte(sk)
LinkMaxBreedte(bf. Ink)
tinkMaxLengtefbf. Ink)
LinkMaxKegels(bf, Ink)
LinkMaxDieptè(bf, Ink. sz)
LinkMaxHoogte(bf,.lnk)
LinkType(bf, Ink)
ReisStar1Tijd(bf, r)
ReisLeegfbf, r)
ReisSchKlassefbf. r)
HBGemReisWachtiijd(bf, skp, h. b. sk)
HBGemReisl_engte(bf, skp, h. b. sk)
ReisStartTijd(bf. r)
ReisHerkomstfbf, r)
ReisBestemmingfbf, r)
ReisSchKlasse(bf, r)
ReisünkStartTijdfbf. r, Inr)
ReisünkEindTijdfbf, r, Inr)
ReisRoute(bf, r, Inr)
ReisRoute(bf, r, Inr)
SchKlasseSne)heid(sk)
SchKlasseSnelheidLeeg(sk)
SchKlassèHoogte(sk)
SchKlasseLengte(sk)
Sch Klasse Breedte(sk)
SchKlasseSnelheid(sk)
SchKlasseSnelheidLeeg(sk)
SchKeuzePeriodeLengte
LinkTypefbf. Ink)
LinkVaarweg(bf. Ink)
VwLengte(bf. vw)
Algemene
informatie
LinkRichting(bf. Ink)
LinkType(bf. Inx)
LinkVaanveg(bf, Ink)
UnkBrug(bf. Ink)
LinkSluis(bf, Ink)
VwLengte(bf, vw)
VwMaxSnelheid(bf. vw)
VwMaxSnelheidLeeg(bf, vw)
VwStroomSnelheid(bf, vw)
BrugHoogte(bf: brg)
BrugStartBediénd(bf, brg)
BrugBod8ediend(bf, brg)
_BJug6penDichtTijd(bf, brg)
BrugPasseerTijdfbf. brg)
BrugOmkeerTijd(bf. brg)
BrugMinDichtTijd(bf, brg)
BrugMaxOpenTijd(bf, brg)
SluisStartBediend(bf. sis)
SluisEindBediend(bf. sis)
SluisOpenDichtTijd(bf. sis)
SluisAantalKolkenfbf, sis)
SluislnTijd(bf. sis)
SluislnTijdWacht(bf. sis)
SluisUitTijdfbf, sis)
SluisOpvolgTijdfbf, sis)
KolkBreedtefbf, sis. knr)
Kolkl_engte(bf, sis. knr)
KolkNivelleerTi|d(bf, sis, knr)
Netwerk
informatie
Scheepsklasse
informatie
betoedeSngsrnodule bepaalt aan de tiamlvaodfegegenweèrde^Mvi^derietwertibelaslingis. Het
belangnlksteonderdeefhienn Is4.2. Dit ondefdeelsimuteert de trips van de schepen en bepaalt zo de
Netwerk
infomnatie
:
belas^>OT'.l^'ne»»»erk..^:::';;;i:-;v':.;;«-;-:i4::^::
•...'i!---i'-'^;;^:;i^.
•
2:•>•-;••
•'•.'•'••.i--:
••»•':''••'•:'•
"
Voor het bepalen van de netwerisbelasting moet een route worden gekozen uit een in Z bepaalde reeks:
^ a f o o p van de simulatie wc»* te o^jmkWelde reisteng» OT
'bepaaM'<^.als*nw*<JM^e«^oor^,^^::':'.:;;'ï:;,;:.::;::;j; ^"'^;:W]".-:f:WX^r>
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
::;
W:
': , •/'•'.
4.1.1. Bepaal mogelijke reis links
* » ƒ . , . « = (•*'*,*«*„, ^ lmht/M
v
"VM
Std
*-nK„ ^lmdblMk^nzt„
rlm
rk
rsk
rsz
sth
stb
sM
std
ReisLinkMogelijk
ReisKegels
ReisSch Klasse
ReisSeizoen
SchKlasseHoogte
SchKlasseBreedte
SchKlasseLengte
SchKlasseDiepte
Imd
Imh
Imb
Iml
Imk
It
*'vastebrug')A
Sch.klasse
informatie
ReisKegetsfbf, r)
ReisSeizoenfbf, r)
ReisSchKlassè(bf, r)
A
SchKlasseHoogte(sk)
SchKlasseBreedte(sk)
SchKlasseLengte(sk)
SchKlasseDiepte(sk)
LinkMaxDiepte
LinkMaxHoogte
LinkMaxBreedte
UnkMaxLengte
LinkMaxKegels
UnkType
ReisHeritomstfbf. r)
linkType(bf, Ink)
LinkMaxfcjoogte(bf, Ink)
LinkMaxBreedte(bf. Ink)
LinkMaxLengtefbf, Ink)
LinkMaxDieptefbf, Ink. sz)
LinkMaxKegels(bf, Ink)
BRoutesibIJLi_mr. Inr;
Netwerit
informatie
ReisRoutes(bf, r. mr, Inr)
ReisStartTijd(bf, r)
ReisLinkMogelijk{bf,r,lnk)
ReisRoutesfbf, r, mr, Inr)
y
4.1.4.
( Bepaal route "
tijden
ReisRoutesTijd(bf, r, mr)
4.1.2. Selecteer alle reis routes
rrS
=
bf,r.mr,li\r
4.1.5.
Bepaal
snelste
route
GemLinkPasseerTijd(bf. Ink, t)
4.1.3.
^
.
rrs
hbrs
rh
rb
Bepaal
gem. link
' passeertijd
""rSbf
,h=rhv,,b=rbll
,,mrMr
ReisRoutes
HBRoutes
ReisHerkomst
ReisBestemming
4.1.4. Bepaal route tijden
X
ReisLinkStartTijd{bf. r, Inr)
ReisUnkHhdTijd(bf, r. Inr)
rrSt
bf,r,mr =2ZêlP'lb/.M=rrsv,
ReisRouté(bf. r, Inr)
Inr
irst
rrs
rst
glpt
ReisRoutesTijd
ReisRoutes
ReisStartTijd
GemLinkPasseerTijd
4.1.3. Bepaal gem. link passeertijd
» r l = \-plnr\rletbfr
II
< t A rrb/rJnr = lnk)\
[rtehwi», ~ rls'b/.r,M
SlPh/jnkj-glpt
rr
rist
riet
rr
bf,M = /"*
anders
E»
n 4. J.wortt per reis de snelste moge^ke route uit de route
IcanoTo^engekozen. Hiervoor wordt m 4.f. f. bepaalt over
welke links gevaren kan worden. In 4.?.4. wordt een : '*;;
prognose gegeven voor de reistijd van elke kaodidaaL Met
behulp van deze gegevens *^W**.&:«È!ÖwlstïS : : S h ' : -ï
moge^ke route bepaald.
;^?;:i,y.y: .*.; •.,W.<KK>f : ^l
h 4. f . 2 worden ter ondersteuning de mogeSJke routes per
herkomst/bestemming omgezet naar c
GemLinkPasseerTijd
ReisRoute
ReisLinkStartTijd
ReisLinkEindTijd
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
ReisUnkMogelijkfbf.r.Ink)
ReisRoutesTijd(bf. r, mr)
ReisRouteMogelijk(bf, r, mr)
4.1.5.2.
Bepaal
snelste
routenr
ReisRoutes(bf, r, mr, Inr)
4.1.5.3. Selecteer snelste route
ReisSnelsteRoutefbf, r)
rrkbf.r.lnr
.
rr
rrs
rsr
4.1.5.3.
Selecteer
snelste
route
_- , jm"> "b/.r.mr,rsr¥„,
rSr
bf,r *
anders
ReisRoute
ReisRoutes
ReisSnelsteRoute
ReisRoutefbf, r, Inr)
4.1.5.1. Bepaal mogelijke routes
rrmb)rmr
rnn
rim
rrs
= Vlnr\rlmb/,rJ„t,my
_,_
ReisRouteMogelijk
ReisLinkMogelijk
ReisRoutes
4.1.5.2. Bepaal snelste routenummer
• m r = fn/jr/-^ r m r = rmn({-nrl\rrstb/rn,rl / O A r r m ¥ r „ r } j A r r m b f r m \
rsr
bf.r
rsr
rrst
rrm
=
first(rnr) rnr * 0
0
anders
ReisSnelsteRoute
ReisRoutesTijd
ReisRouteMogelijk
In4.f.aiwon«ciesn^:«tiogelpfe.i^^gelio^.,t^^
IWcs-«e;oeb^^rnogOT;»rordêr^J:'p/-:'5:;::;?:^
iV£:iS^€;.:ïn->fëW:v%v;:3iffi
Vervol9éns«^ir*^^:tóJodBm«ïmer : van'^
t§o^ heliben WOK» ó^itt géko2en { d e g ^
9^sele<*eera^beteke««;9^.ipu^;Jg;;::fï;;:H;::^
-"^UlZ:.
Vervolgens wordtin -f. 15.3 de daadwateljke routeinformal» doorgegeven aan de hand van het geselecteerde routenummer.
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
0
Netwerk
Informatie
ReisRoute(bf, r, Inr)
Algemene
informatie
LinkTypefbf, Ink)
LinkVaarwegfbf, Ink)
VwLengte(bf, vw)
SchKeuzePeriodeLengte
ReisHerkomst(bf, r)
ReisBestemmihgjbf. r)
ReisSchKlasse(bf, r)
ReisünkEindTijd(bf, r, Inr)
ReisLinkLengtefbf, r, Inr)
HBGemReisLengte(bf. skp. h, b. sk)
\
ReisSchKeuzePeriode(bf. r)
BésHerkomst(bf, r)
ReisLinkStartTijdtbf, r, Inr)
ReisLinkEindTijd(bf, r, Inr)
i
;
4.3.3. "
Bepaal
Gemiddelde
reis
„
wachttijd
SchKlasseSnelheid(sk)
SchKlasseSnelheidLeeg(sk)
4.3.1. Bepaal reis scheepskeuzeperiode
rskpbf, = l + i
rskp
riet
skpl
Scheepsklasse
informatie
'mz\{rlet
bfrlnrY
Inr
skpl
ReisSchKeuzePeriode
ReisLinkEindTijd
SchKeuzePeriodeLengte
In 4.3.1, wordt de scheepskeuzeperiode perretsbepaald. Vervolgens wordt in 4 . 3 2 en O . 3 . respectieve^k de gemiddelde :>;;
reisle>^enigemido>^viacni^ bepaald p e r s ^
'doorgegeven aan het scheepskeuzemodel (1), zodal voorreizenin * volgenoe sctieerjskeuze pen^cle de keuze tussen' :;:: ;:.;;;v:'
sc«ieepslypes;kaÖA»onten:'9ernaalctïyi^;.; -:y
>:vr
' '-•':-i^j •'
. ^ r ^ ' V S ^ V ï ' 1 ••••^^' : 'ï ;i: '^ : "' 1 '"i:':.i>^ i: - ; ; ; !:r :;:
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
10
4.3.2.1. Bepaal reis link lengte
• Ink] = rr.b),rjnr
dl,bf.r.lnr
ril
vwl
It
rr
_ M v .v-i™*^
lt
vMi
-vaarweg'
anders
ReisLrnkLengte
VwLengte
LinkType
ReisRoute
Netwerk
Informatie
ReisHerkomst(bf. r)
ReisBestemming(bf, r)
ReisSchKlassefbf, r)
LinkTypefbf. Ink)
VwLengtefbf. vw)
HBGemReisLengte(bf, skp, h. b. sk)
ReisRoute(bf, r. Inr)
ReisünkLengte(bf, r. Inr)
4.3.2.2.
Middel de
reis lengte
4.3.2.1.
Bepaal reis
link lengte
ReisSchKeuzePeriode(bf. r)
4.3.2.2. Middel de reis lengte
• r l = \\rskpbfr
hbgrlbf,skpMM
- skp A rskbfr = sk A rhb/r - h A rbb/
= average
HBGemReisLengte
ReisLinkLengte
In 4.3.2.1 worden de lengtes van de Snks op de route
varififte>refe.bepaald;.:ln'4&Z2..ji»ordtperreiS:de~». \
.«Dt^l»^ : be|ia3i*etM»0B«'tf:pèr' ; - i '--. •'• •'^•it^X
sctieepskeuzeperipdegerniddeM over deherkomsl f
bestemming/scheepsklasse combinaties.
IK,,.,
•»)
\lnr
hbgrl
ril
ReisLinkLengte<bf, r. Inr)
rskp
rsk
rh
rt>
ReisSchKeuzePeriode
ReisSchKlasse
ReisHerkomst
ReisBestemming
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
11
4.3.3.1. Bepaal reis link wachttijd
rl
riw
riet
rist
ril
rsk
sks
sksl
ReisLeeg
ReisUnkWachttijd
ReisLinkEindTijd
ReisLinkStartTijd
ReisLinkLengte
ReisSchKlasse
SchKlasseSnelheid
SchKlasseSnelheidLeeg
Gemiddelde
Vrei»;le(«te/
ReisHerkomst(bf. r)
ReisBestemming(bf. r)
ReisSchKlassefbf. r)
ReisünkLengte(bf, r, Inr)
HBGemReisWachttijdfbf. skp. h. b. sk)
ReisLinkStartTijd(bf, r, Inr)
ReisünkEindTijd(bf, r, Inr)
4.3.3.1.
Bepaal reis
link
--. wachttijd
4.3.3.2.
Middel
de reis
wachttijd
ReisSchKlassefbf, r)
ReisLeegfbf, r)
ReisLinkWachttijdfbf, r, Inr)
ReisSchKeuzePeridde(bf. r)
SchKlasseSnelheid(sk)
SchKlasseSnelheidLeeg(sk)
* Bepaal rei»
schkeuze-
SchKlasse
infomiatie
4.3.3.2. Middel de reis wachttijd
• r l = \r\rskpb/r
hbgrwb/jkpJtJ,Jk
hbgrw
riw
=skp*
rskbf,
= average
HBGemReisWachttijd
ReisUnkWachttijd
= sk A rhb/r = h A rbbfr
E('fcv ,r\.lnr
rskp
rsk
rh
rt>
)
In 4.3.3. >. worden de wachttijden van de inks op de
route van elke reis bepaaW. De wachttid is het
verschil tussen de vaartjd om de lengte van de Jnk
af te leggen en de tjd die het schip er daadwerkeljk
over gedaan heeft In 4.3.3.Z wordt per reis de totale
•waoJ«^bèpaald;éowdr<lterper;'ï:'!;-"-":S-'';ï --ï^i-i
**epskeuzeperiode gemiddeld over de hertcomst/
bestemming/scheepsklasse combinaties.
ReisSchKeuzePeriode
ReisSchKlasse
ReisHerkomst
ReisBestemming
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
12
(
(
B.
f
(
Datadefinitie
B.1. Variabelen
id
cat
31
invoer
bron
Algemeen
naam
SchKeuzePeriodeLengte
tabelnaam
Algemeen
15
invoer
Netwerkinfo
BrugEindBediend
Bruggen
58
invoer
Netwerkinfo
BrugHoogte
Bruggen
20
invoer
Netwerkinfo
BrugMaxOpenTijd
Bruggen
19
invoer
Netwerkinfo
BrugMinDichtTijd
Bruggen
18
invoer
Netwerkinfo
BrugOmkeerTijd
Bruggen
16
invoer
Netwerkinfo
BrugOpenDichtTijd
Bruggen
17
invoer
Netwerkinfo
BrugPasseerTijd
Bruggen
14
invoer
Netwerkinfo
BrugStartBediend
Bruggen
22
23
24
invoer
invoer
invoer
Netwerkinfo
Netwerkinfo
Netwerkinfo
KolkBreedte
KolkLengte
KolkNivelleerTijd
Kolken
Kolken
Kolken
52
invoer
Netwerkinfo
LinkBrug
Links
5
invoer
Netwerkinfo
LinkMaxBreedte
Links
veldnaam
beschrijving
|indices
SchKeuzePeriodeLengte De lengte van de periode waarop het
scheepskeuzeproces wordt gebaseerd
EindBediend
Het tijdstip op de dag (in bf, brg
sec vanaf 0:00:00)
waarop de bediening van
de brug stopt (repeteert
per 24h)
Hoogte
De maximale hoogte van bf, brg
de schepen die onder de
gesloten brug door
kunnen varen
MaxOpenTïjd
De tijd die een brug
bf, brg
maximaal open mag zijn
voordat hij weer gesloten
moet worden.
MinDichtTijd
De tijd die een brug
bf, brg
minimaal gesloten moet
zijn voordat hij weer
geopend mag worden.
OmkeerTijd
De wachttijd die nodig is bf, brg
voordat schepen vanuit
de tegenovergestelde
richting door de
geopende brug kunnen
varen.
OpenDichtTijd
De tijd die nodig is om
bf, brg
een brug te openen of
sluiten.
PasseerTijd
De tijd die een schip
bf, brg
nodig heeft om de brug
te passeren
StartBediend
Het tijdstip op de dag (in bf, brg
sec vanaf 0:00:00)
waarop de bediening van
de brug begint,
(repeteert per 24h)
Breedte
De breedte van de kolk bf, sis, knr
Lengte
De lengte van de kolk
bf, sis, knr
NivelleerTijd
De tijd die nodig is om
bf, sis, knr
een kolk van nveau te
doen veranderen
index
Verwijzing naar een brug bf, Ink
(indien de link een brug
is)
MaxBreedte
De maximale breedte
bf, Ink
van schepen die over de
enum
ong
eenh.
s
long
s
doublé
m
long
s
long
s
long
s
long
s
long
s
long
s
doublé
doublé
long
m
m
s
type
long
doublé
Brug
m
(
(
f
(
7
invoer
Netwerkinfo
LinkMaxDiepte
LinkMaxDiepte
MaxDiepte
11
invoer
Netwerkinfo
LinkMaxHoogte
Links
MaxHoogte
8
invoer
Netwerkinfo
LinkMaxKegels
Links
MaxKegels
6
invoer
Netwerkinfo
LinkMaxLengte
Links
MaxLengte
51
invoer
Netwerkinfo
LinkRichting
Links
Richting
54
invoer
Netwerkinfo
LinkSluis
Links
index
9
invoer
Netwerkinfo
LinkType
Links
LnkType
53
invoer
Netwerkinfo
LinkVaarweg
Links
index
21
invoer
Netwerkinfo
SluisAantalKolken
60
invoer
Netwerkinfo
SluisEindBediend
Sluizen
EindBediend
25
invoer
Netwerkinfo
SluisInTijd
Sluizen
InTijd
26
invoer
Netwerkinfo
SluisInTijdWacht
Sluizen
InTijdWacht
61
invoer
Netwerkinfo
SluisOpenDichtTijd
Sluizen
OpenDichtTijd
28
invoer
Netwerkinfo
SluisOpvolgTijd
Sluizen
OpvolgTijd
59
invoer
Netwerkinfo
SluisStartBediend
Sluizen
StartBediend
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
ink kunnen
De maximale diepte van Df, Ink, sz
een schip op link
De maximale hoogte op bf, Ink
de link
Het maximaal aantal
bf, Ink
kegels dat een schip
mag hebben op de link
De maximale lengte van bf, Ink
schepen die over de link
kunnen
De richting van de link
bf, Ink
(stroomopwaarts,
stroomafwaarts)
Verwijzing naar een sluis bf, Ink
(indien de link een sluis
is)
Het type van de link
bf, Ink
(vaarweg, brug, etc.)
Verwijzing naar een
bf, Ink
vaarweg (indien de link
een vaarweg is)
Het aantal kolken in een bf, sis
sluis
Het tijdstip op de dag (in bf, sis
sec vanaf 0:00:00)
waarop de bediening van
de sluis stopt (repeteert
per 24h)
De tijd die een schip
bf, sis
nodig heeft om een sluis
binnen te varen indien
het schip niet heeft
hoeven wachten.
De tijd die een schip
bf, sis
nodig heeft om een sluis
binnen te varen indien
het schip wel heeft
hoeven wachten.
De tijd die nodig is om
bf, sis
een sluis te openen of
sluiten.
De wachttijd tussen twee bf, sis
een sluis verlatende
schepen
Het tijdstip op de dag (in bf, sis
sec vanaf 0:00:00)
waarop de bediening van
de sluis begint,
(repeteert per 24h)
doublé
m
doublé
m
long
#
doublé
m
long
Richting
long
Sluis
long
LnkType
long
Vaarweg
long
#
long
s
long
s
long
s
long
s
long
s
long
s
14
(
(
(
27
invoer
Netwerkinfo
SluisUitTijd
Sluizen
UitTijd
10
invoer
Netwerkinfo
VwLengte
Vaarwegen
Lengte
12
invoer
Netwerkinfo
VwMaxSnelheid
Vaarwegen
MaxSnelheid
55
invoer
Netwerkinfo
VwMaxSnelheidLeeg
Vaarwegen
MaxSnelheidLeeg
13
invoer
Netwerkinfo
VwStroomSnelheid
Vaarwegen
Stroomsnelheid
2
invoer
Scheepsinfo
SchKlasseBreedte
ScheepsKlassen Breedte
4
invoer
Scheepsinfo
SchKlasseDiepte
ScheepsKlassen Diepte
1
invoer
Scheepsinfo
SchKlasseHoogte
ScheepsKlassen Hoogte
3
invoer
Scheepsinfo
SchKlasseLengte
ScheepsKlassen Lengte
29
invoer
Scheepsinfo
SchKlasseSnelheid
ScheepsKlassen Snelheid
30
invoer
Scheepsinfo
SchKlasseSnelheidLeeg
ScheepsKlassen SnelheidLeeg
38
RouteEnumerat 2.x
ie
HBRoutes
HBRoutes
Link
37
ScheepsKeuze 1.x
ReisLeeg
Reizen
Leeg
33
ScheepsKeuze 1.x
ReisBestemming
Reizen
Bestemming
32
ScheepsKeuze 1.x
ReisHerkomst
Reizen
Herkomst
35
ScheepsKeuze 1.x
ReisKegels
Reizen
Kegels
40
ScheepsKeuze 1.x
ReisSchKlasse
Reizen
SchKlasse
36
ScheepsKeuze 1.x
ReisSeizoen
Reizen
Seizoen
34
ScheepsKeuze 1.x
ReisStartTijd
Reizen
StartTijd
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
De tijd die een schip
bf, sis
nodig heeft om een sluis
uit te varen
vw, Ink
De lengte van de
vaarweg
vw, Ink
De maximaal
haalbare/toegestane
snelheid op de vaarweg
voor beladen schepen
vw, Ink
De maximaal
haalbare/toegestane
snelheid op de vaarweg
voor lege schepen
De stroomsnelheid op de vw, Ink
vaarweg
Breedte van de schepen st
in een scheepsklasse
Diepgang van de
st
schepen in een
scheepsklasse
Hoogte van de schepen st
in een scheepsklasse
Lengte van de schepen st
in een scheepsklasse
De snelheid van beladen st
schepen in een
scheepsklasse
De snelheid van
st
onbeladen schepen in
een scheepsklasse
De mogelijke routes voor h, b, rnr, Inr
een
herkomst/bestemming
paar, opgeslagen als een
reeks links per h/b/rnr
bf, r
Is het schip beladen of
leeg tijdens de reis
De bestemmingsknoop bf, r
van de reis
De herkomstknoop van bf, r
de reis
bf, r
Het aantal kegels van
een reis
Voor een reis het
bf, r
gekozen scheepsklasse
Seizoen waar het schip bf, r
in start (uitgerekend
vanuit ReisStartTijd)
De starttijd van de reis
bf, r
long
s
doublé
m
doublé
m/s
doublé
m/s
doublé
m/s
doublé
m
doublé
m
doublé
m
doublé
m
doublé
m/s
doublé
m Is
long
Link
bool
long
Knoop
long
Knoop
long
#
long
SchKlasse
long
Seizoen
long
s
15
f
(
41
Toedeling
4.1.1.
ReisLinkMogelijk
42
Toedeling
4.1.2.
ReisRoutes
62
Toedeling
4.1.3.
GemLinkPasseerTijd
44
Toedeling
4.1.4.
ReisRoutesTijd
45
Toedeling
4.1.5.1.
ReisRouteMogelijk
46
Toedeling
4.1.5.2.
ReisSnelsteRoute
47
Toedeling
4.1.5.3.
ReisRoute
64
Toedeling
4.2.
ReisLinkEindTijd
63
Toedeling
4.2.
ReisLinkStartTijd
65
Toedeling
4.3.1.
ReisSchKeuzePeriode
66
Toedeling
4.3.2.1.
ReisLinkLengte
67
Toedeling
4.3.2.2.
HBGemReisLengte
68
Toedeling
4.3.3.1.
ReisLinkWachttijd
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
(
(
bf, r, Ink
DOOl
Geeft aan welke links
gebruikt mogen worden
om over te reizen
}f, r, mr, Inr
ong
Afgeleid vanuit
HBRoutes welke routes
ï mogelijk en niet
mogelijk) er zijn voor een
reis
De gemiddelde tijd die
bf, Ink, t
doublé
schepen nodig hebben
gehad om de link te
aasseren sinds het begin
van de simulatie tot tijd t.
Een prognose voor de
sf, r, rnr
doublé
reistijd voor elk
alternatief in ReisRoutes
Bepaalt op basis van
af, r, rnr
bool
ReisLinkMogelijk welke
routes uit ReisRoutes
mogelijk zijn
De snelste mogelijke
bf, r
long
route
De route die een reis
bf, r, Inr
long
volgt als een reeks links
long
Geeft voor elke link op
bf ,r, Inr
de route van een reis
aan wanneer het schip
de link verliet.
long
Geeft voor elke link op
bf ,r, Inr
de route van een reis
aan wanneer het schip
de link binnenging.
bf,r
long
Bepaald in welke
scheepskeuzeperiode de
reis valt.
De lengte van een link
bf, r, Inr
doublé
op een reis
De gemiddelde
bf, skp, h, b, sk doublé
reislengte over een
scheepskeuzeperiode
De wachttijd van een link bf, r, Inr
doublé
op een reis. De wachttijd
is het verschil tussen de
vaartijd om de lengte van
de link af te leggen en de
tijd die het schip er
daadwerkelijk over
gedaan heeft.
Jnk
s
s
s
RouteNr
Link
s
s
SchKeuzePer
m
m
s
16
(
<
69
Toedeling
4.3.3.2.
B.2. Indices
>d code naam
HBGemReisWachttijd
(
(
De gemiddelde wachttijd bf, skp, h, b, sk doublé
over een
scheepskeuzeperiode.
De wachttijd is het
verschil tussen de
vaartijd om de lengte van
de link af te leggen en de
tijd die het schip er
daadwerkelijk over
gedaan heeft.
beschrijving
min max
1
2
3
4
5
6
7
8
bf
r
h
b
skp
Ink
rnr
Inr
BaseForecast Basisjaar of voorspellingsjaar
Reis
Reisnummer, afhankelijk van BaseForecast
Herkomst
Herkomstknoop
Bestemming
Bestemmingsknoop
SchKlasse
Scheepsklasse
Link
Linknummer, de links zijn gericht dus er zijn steeds twee links die naar een brug/sluis/vaarweg verwijzen
RouteNr
Een volgnummer voor alternatieve routes
LinkNr
Een volgnummer voor alternatieve links binnen een route
1
1
1
1
1
1
1
1
2
nnb
nnb
nnb
nnb
nnb
nnb
nnb
9
10
11
12
ri
sz
skp
t
Richting
Seizoen
SchKeuzePer
Tijd
1
1
1
1
2
nnb
nnb
nnb
13
14
15
16
It
brg
sis
vw
LnkType
Brug
Sluis
Vaarweg
1
1
1
1
4
nnb
nnb
nnb
Richting op een link
Het seizoen in het jaar
Scheepskeuze periode
Een kunstmatige index die het aantal seconden sinds de start van de simulatie weergeeft. Deze index is
vanzelfsprekend nooit geheel gevuld.
LinkType
Een brug (ongerichte link)
Een sluis (ongerichte link)
Een vaarweg (ongerichte link)
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
s
17
(
(
(
(
B.3. Enumeratiewaarden
entry
id
code naam
1
bf
BaseForecast Basisjaar
9
ri
Richting
13
It
LnkType
waarde
1
VoorspelJaar
2
StroomAfwaarts
1
Stroomopwaarts 2
Vaarweg
1
BrugVast
2
BrugBediend
3
Sluis
4
Rap92 - Softwarespecificatie Toedelingsmodule BVMS Fase 2
18 januari 2001
18
C.
Implementatie
Deze appendix geeft een korte beschrijving van elk van de modules van de huidige
implementatie. Een module bestaat uit een source file (*.cpp) en eventueel een header file (*.h).
De modules zijn ingedeeld in een aantal categorieën: hoofdmodules, toedelingsmodule,
simulatiemodel, externe informatie en overige modules.
Cl.
Hoofdmodules
Module
BVMSSiml
ScheepsKeuze
RouteEnumeratie
Beschrijving
Hoofdmodule van waaruit de applicatie wordt opgestart en de
verschillende objecten worden geïnitialiseerd en de simulatie wordt
gestart.
Implementatie van de scheepskeuze module (1).
Implementatie van de route enumeratie module (2).
C.2. Toedelingsmodule
Module
Reisduur
RouteSelectie
SimulatieModel
Beschrijving
Implementatie van de module voor het bepalen van de gemiddelde
reisduur (4.3).
Implementatie van de routeselectie module (4.1).
Implementatie van het simulatiemodel (4.2).
C.3. Simulatiemodel
Module
Brug
CollectedObject
Collection
Kolk
Message
M essage Argument
MessageHandler
Schip
Sender
Sluis
Vaarweg
Wachtrij
Beschrijving
Implementatie van de CBrug class.
CollectedObjects zijn generieke objecten die tijdens een simulatie van de
ene Collection naar de andere verplaatst worden.
Collections zijn generieke objecten die CollectedObjects kunnen bevatten.
De CKolk class is de implementatie van kolken behorende bij sluizen.
Implementatie van berichten die verstuurd worden tussen de objecten
tijdens de simulatie.
Argumenten van de berichten.
Handelt het versturen van berichten af tussen de verschillende objecten.
Implementatie van schepen
Abstracte class van alle objecten die berichten kunnen versturen.
Implementatie van sluizen.
Implementatie van vaarwegen.
Implementatie van wachtrijen van bruggen en kolken.
Rap92 - Softwarespecificatie Toedelingsmodule
BVMS Fase 2
18 januari 2001
19
C.4. Externe informatie
Module
Algemeen
Netwerk
ScheepsKlasse
Beschrijving
Module die gebruikt wordt voor het inlezen en beschikbaar stellen van
algemene informatie.
Module die gebruikt wordt voor het inlezen en beschikbaar stellen van
netwerk informatie.
Module die gebruikt wordt voor het inlezen en beschikbaar stellen van
scheepsklasse informatie.
C.5. Overige modules
Module
Error
Route
StdAfx
Types
Beschrijving
Implementatie van de CError class die gebruikt wordt voor
foutafhandeling.
Implementatie van de CRoute class die gebruikt wordt om routes op te
slaan en door te geven tussen de verschillende modules.
Verplichte standaard module.
Definities van types en enumeraties voor de toedelingsmodule.
Rap92 - Softwarespecificatie Toedelingsmodule
BVMS Fase 2
18 januari 2001
20
QQQ Delft - Rap94
Softwarespecificatie Omkapseling
MATLAB-prototype t.b.v. de Integratie in
BVMS 0.2
Alle rechten voorbehouden.
Niets uit deze uitgave mag worden
vermenigvuldigd en/of openbaar
gemaakt door middel van druk,
fotokopie, microfilm of op welke
andere wijze dan ook, zonder
voorafgaande toestemming van
QQQ Delft
©2001 QQQ Delft
QQQ Delft
Kluyverweg 2a
2629 HT Delft
T: 015-2682581
F: 015-2682591
W: http://www.qqq.nl
18 januari 2001
Auteurs:
ir. J.K. de Haan,
ir. G.F. Zegwaard
1.
INLEIDING
3
2.
SPECIFICATIE INTERFACE REKENMODULE
4
2.1
2.1.1
2.1.2
2.1.3
2.2
2.2.1
2.3
2.4
Calculator Class
Eigenschappen
Methoden
Gebeurtenissen
Error Class
Eigenschappen
STATUS_TYPE enumeratie
Voorbeeld: VB Code
4
4
4
5
5
5
5
6
3.
IMPLEMENTATIE REKENMODULE
7
3.1
BVMS Omgeving
7
3.2
Matlab Application Program Inferface (API)
8
A.
BESCHRIJVING DATABASE
9
A.l.
Invoer tabellen
9
A.2.
Uitvoer tabellen
10
B.
DATADEFINITIE
11
B.1.
B.2.
B.3.
C.
Variabelen
Indices
Enumeratiewaarden
BESTANDEN
11
16
17
18
D.
REGISTRYKEYS
19
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
1.
Inleiding
Dit document beschrijft de inbouw van het MATLAB-prototype van het BVMS Model in Fase
2. Hoofdstuk 2 beschrijft de specificatie van de interface van de rekenmodule zoals deze
gebruikt en aangeroepen kan worden door programmeurs. Hoofdstuk 3 gaat dieper in op de
implementatie van de rekenmodule en zijn omgeving. Appendix A geeft een beschrijving van de
databases die dienen als invoer en uitvoer van de rekenmodule. Appendix B beschrijft de
datadefinitie en legt de koppeling tussen de database en de variabelen zoals deze in de Matlab
files voorkomen. Appendix C geeft een overzicht van alle bestanden die van belang zijn voor
het draaien van de huidige versie van het BVMS Model en appendix D beschrijft tenslotte de
registry keys die door de rekenmodule gebruikt worden om instellingen in op te slaan.
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
2.
Specificatie Interface Rekenmodule
Dit hoofdstuk beschrijft de interfaces van de COM classes gedefinieerd in de
BVMSCalculator05 executable. Dit hoofdstuk is vooral bedoeld om programmeurs die
BVMSCalculator05 gebruiken een gedetailleerde referentie van deze interfaces te verschaffen.
De beschrijving en voorbeelden zijn geschreven in de Visual Basic (VB) formele notatie. Mocht
de lezer kiezen om met een ander platform te werken dan blijft dit hoofdstuk nuttig als
referentiemateriaal aangezien de beschreven classes COM classes zijn en derhalve op elk
platform dat COM ondersteund gebruikt kunnen worden.
2.1
Calculator Class
Een Calculator object kan een output database produceren zoals beschreven in appendix A.
2.1.1
Eigenschappen
Error
Retourneert een Error object. Bevat een S_OK Error object indien er geen fout is
opgetreden. (Alleen lezen).
Message
Retourneert een string met informatie over de huidige stap in de berekening. (Alleen
lezen).
Progress
Geeft een doublé tussen 0.0 en 1.0 terug die aangeeft hoever de berekening gevorderd is.
(Alleen lezen).
Status
Geeft een enumatiewaarde van het type StatusType terug (zie paragraaf 2.3). (Alleen
lezen).
2.1.2
Methoden
Start(strConnectionIn As String, strConnectionOut As String)
Deze methode start de berekening.
Parameters
strConnectionln
strConnectionOut
Beschrijving
Een ADO connectionstring naar de invoer database
Een ADO connectionstring naar de uitvoer database
Stop
Deze methode stopt de berekening.
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
2.1.3
Gebeurtenissen
OnError(Error)
Geeft aan dat er een fout is opgetreden. Zie ook de Error class.
Parameters
Error
Beschrijving
Een error object van het type Error class
OnFinished
Geeft aan dat de berekening succesvol is afgerond.
OnMessageChange(Message)
Geeft aan dat er een nieuw bericht is.
Parameters
Message
Beschrijving
Een string met het nieuwe bericht.
OnProgressChange(Progress)
Geeft aan dat de Progress eigenschap veranderd is.
Parameters
Progress
2.2
Beschrijving
Een doublé met de nieuwe waarde van de Progress
eigenschap.
Error Class
Het Error object representeert een foutbericht en wordt gegenereerd zodra er een fout optreedt in
een Calculator object. Het kan gebruikt worden om informatie over optredende fout te
achterhalen zowel voor foutafhandeling als debuggen.
2.2.1
Eigenschappen
Code
Retourneert een Integer (eigenlijk HRESULT) code corresponderend met de fout die
aanleiding gaf tot het genereren van dit Error object. (Alleen lezen)
Description
Retourneert een String met een korte beschrijving van de fout die is opgetreden (Alleen
lezen).
Message
Retourneert een String met het foutbericht dat bij deze fout hoort. (Alleen lezen).
2.3
STATUS_TYPE enumeratie
STATUS_TYPE wordt teruggeven indien de Status eigenschap van een Calculator object wordt
opgevraagd. De volgende waarden zijn gedefinieerd:
Statusjdle = 1
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
5
Het calculator object is in rust. Dit is de initiële toestand en de toestand nadat een
berekening succesvol is afgerond.
Status_Calculating = 2
Het calculator object is bezig met de berekening. Dit is de toestand nadat de Start
methode is aangeroepen.
Status_Stopping = 3
Het calculator object is bezig de berekening te onderbreken. Dit is de toestand nadat de
Stop methode is aangeroepen.
Status_Error = 4
Het calculator object is gestopt vanwege een fout.
2.4
Voorbeeld: VB Code
Declaratie van het calculator object
Dim WithEvents objCalculator As BVMSCALCULATOR05Lib.Calculator
Creatie van het calculator object
Set objCalculator = New BVMSCALCULATOR05Lib.Calculator
Starten van de berekening
Dim strlnput As String
Dim strOutput As String
strlnput = "Provider=Microsof t. Jet .OLEDB.4 . 0,-Data Source=input .mdb"
strOutput = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=output.mdb"
objCalculator.Start strlnput, strOutput
Stoppen van de berekening
objCalculator.Stop
Voorbeeld van event handlers
Private Sub objCalculator_OnError(ByVal piError As BVMSCALCULATOR02Lib.IError)
MsgBox "Errorcode: Ox" & Hex(piError.Code) & vbNewLine & _
"Error message: " & piError.Message & vbNewLine & _
"Error description: " & piError.Description, _
vbCritical + vbOKOnly, frmMain.Caption
End Sub
Private Sub objCalculator_OnFinished()
MsgBox "OnFinished called", vbOKOnly, frmMain.Caption
End Sub
Private Sub objCalculator_OnMessageChange(ByVal Message As String)
MsgBox Message, vbOKOnly, frmMain.Caption
End Sub
Private Sub objCalculator_OnProgressChange(ByVal Progress As Doublé)
MsgBox Progress, vbOKOnly, frmMain.Caption
End Sub
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
3.
Implementatie Rekenmodule
3.1
BVMS Omgeving
Onderstaand figuur geeft een de rekenmodule in de BVMS omgeving weer. Onder elk
onderdeel is het bijbehorende bestand geschreven van de huidige implementatie. Appendix C
geeft een uitgebreider overzicht van alle benodigde bestanden voor het runnen van de huidige
applicatie.
>
Arclnfo BVMS Systeem
«S.-S*
| |
Invoer database
(Basisln(QQQ).mdb)
K
Uitvoer database
(BasisUit(QQQ).mdb)
73
CD
f
2.
5"
er
o.
Matlab
prognosejaar
(progjaar.exe)
Matlab basisjaar
(basisjaar.exe)
Uivoer basisjaar
(basis_uit.bvm)
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
De rekenmodule wordt opgestart vanuit het Arclnfo BVMS Systeem. Deze levert een invoer
database aan. De rekenmodule leest de gegevens uit de database in via een ADO verbinding en
schrijft de gegevens weg in een matlab bestand door middel van de Matlab API (zie paragraaf
3.2). Het matlab bestand wordt opgeslagen in een tijdelijke directory die wordt aangemaakt in
een in de registry opgegeven locatie (zie appendix D).
Zodra de invoer succesvol geconverteerd is, wordt het matlab model opgestart. Het matlab
model wordt opgestart door een in de registry opgegeven executable (zie appendix D). Deze
executable doet niets anders dan de verschillende deelmodellen van het matlab model
sequentieel aan te roepen. Het basisjaar deelmodel levert als uitvoer het tijdelijke bestand
basis_uit.bvm dat dient als invoer van het tweede deelmodel prognosejaar. De uiteindelijke
uitvoer bestaat uit het matlab bestand prog_uit.bvm.
De uitvoer van het matlab model wordt door het rekenmodel ingelezen en weggeschreven naar
de uitvoer database. Deze uitvoer database wordt vervolgens aan de BVMS omgeving
aangeboden om verder gebruikt te worden.
3.2
Matlab Application Program Inferface (API)
Om Matlab bestanden te schrijven en uit te lezen wordt gebruik gemaakt van de Matlab API.
Deze is beschreven in "Matlab - The Language of Technical Computing - Application Program
Interface Reference - Version 5" en "Matlab - The Language of Technical Computing Application Program Interface Guide - Version 5". Om deze API te gebruiken worden de
volgende DLLs gebruikt:
-
libmat.dll
libmx.dll
libut.dll
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
A. Beschrijving Database
A.l. Invoer tabellen
BaseNode
BaseLink
nodeid
linkid
BaseTripObs
NodeA
NodeB
Length
Capacity
Type
Origin
Destination
ShipType
Goodgroup
Capacity
BaseDemand
BasePartysize
Origin
nodeid_from
goodgroup
nodeid
nodeidjo
goodgroup
Demand
MinTonnage
MaxTonnage
MeanTonnage
StddevTonnage
Name
Destination
nodeid
Name
LinkType
ForecastNode
ForecastLink
ForecastDemand
ForecastPartysize
linktype
nodeid
linkid
nodeid_from
nodeidjo
goodgroup
goodgroup
Name
NodeA
NodeB
Length
Capacity
Type
Demand
ShipType
ShipTypeLinkType
shiptype
shiptype
linktype
Name
Capacity
SUFactor
FleetSize
IsContainership
CostFix
CostWaiting
Costldle
CostSailFull
CostSailEmpty
Allowed
ShipTypeGoodgroup
shiptype
goodgroup
Parameters
Dimensions
FreeFlowSpeed
NumDaysInSimPeriod
NumDaysSaillnYear
NumDaysSailInSeason
CurrentSeason
FleetLimitPenalty
MaxFleetSizelterations
ShipChoiceLogFilename
ShipChoiceSizeConstraint
NumShipChoiceCoefs
NumGoodGroups
NumShipTypes
NumShipmentCats
NumRiskCats
NumOrigins
NumDestinations
Month
month
Season
Allowed
Goodgroup
GoodGroupShipChoiceCoef
Workday
goodgroup
goodgroup
shipchoicecoef
workday
Name
Max Risk
ContainerFraction
MinTonnage
MaxTonnage
MeanTonnage
StddevTonnage
DemandFactor
Coef
GoodGroupShipmentCat
GoodGroupRiskCat
GoodGroupMonth
goodgroup
shipmentcat
goodgroup
riskcat
goodgroup
month
Probability
Maximum
Probability
DemandFactor
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
A.2. Uitvoer tabellen
BaseTrip
BaseRoute
BaseLinkLoad
basetripidx
basetripidx
routeidx
linkidx
Origin
Destination
ShipType
Goodgroup
Amount
Route
LinklD
LinkLoad
ForecastTrip
ForecastRoute
ForecastLinkLoad
forecasttripidx
forecasttripidx
routeidx
linkidx
Origin
Destination
ShipType
Goodgroup
Amount
Route
LinklD
LinkLoad
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
10
(
(
B.
Datadefinitie
B.1
Variabelen
id
cat
Matlab naam
naam
f
(
tabelnaam
veldnaam
beschrijving
indices typ«
enum
eenh.
bnidx
long
nodeid
id
X
x-coordinate in rijksdriehoek
bnidx
doublé
m
BaseNode
Y
y-coordinate in rijksdriehoek
bnidx
doublé
m
BaseLink
ID
blidx
long
linkid
id
BaseLink
NodeA
blidx
long
nodeid
id
blidx
long
nodeid
id
blidx
doublé
m
blidx
doublé
shp/h
1 invoer B.nds.coli
BaseNodelD
BaseNode
ID
2 invoer B.nds.col2
BaseNodeX
BaseNode
3 invoer B.nds.col3
BaseNodeY
4 invoer B.lnks.coli
BaseLinklD
5 invoer B.lnks.col2
BaseLinkNodeA
6 invoer B.lnks.col3
BaseLinkNodeB
BaseLink
NodeB
7 invoer B.lnks.col4
BaseLinkLength
BaseLink
Length
link length
8 invoer B.BPRpars
BaseLinkCap
BaseLink
Capacity
link capacity
9 invoer B.lnktype
BaseLinkType
BaseLink
Type
link type
blidx
long
linktype id
10 invoer B.triplist_obs.org
BaseTripObsOrg
BaseTripObs
Origin
observed trip origin
btoidx
long
nodeid
id
nodeid
id
11 invoer B.triplisLobs.dst
BaseTripObsDst
BaseTripObs
Destination
observed trip destination
btoidx
long
12 invoer B.triplist_obs.st
BaseTripObsSt
BaseTripObs
ShipType
observed trip shiptype
btoidx
long
shiptype id
13 invoer B.triplist_obs.gg
BaseTripObsGg
BaseTripObs
Goodgroup
observed trip goodgroup
btoidx
long
goodgro id
14 invoer B.triplisLobs.cap
BaseTripObsCap
BaseTripObs
Capacity
observed trip ship capacity
btoidx
doublé
ton
15 invoer B.demand
BaseDemand
BaseDemand
Demand
demand
99. n_f.
n t
doublé
ton
MinTonnage
partysize minimum tonnage
99
doublé
ton
MaxTonnage
partysize maximum tonnage
99
doublé
ton
MeanTonnage
partysize mean tonnage
99
doublé
ton
StddevTonnage
partysize standard deviation
99
doublé
ton
fnidx
long
up
16 invoer B.partysize.min_tonnage
BasePartySizeMinTonna BasePartySize
ge
17 invoer B.partysize.max_tonnage
BasePartySizeMaxTonna BasePartySize
ge
18 invoer B. partysize. mean_tonnage
BasePartySizeMeanTonn BasePartySize
age
19 invoer B.partysize.stddev_tonnage
BasePartySizeStddevTon BasePartySize
nage
20 invoer F.nds.coli
ForecastNodelD
tonnage
ForecastNode
ID
Rap94 - Softwarespecificatie Omkapseling MATLAB-prototype t.b.v. de Integratie in BVMS 0.2
18 januari 2001
nodeid
id
11
(
(
(
21 nvoer F.nds.col2
"orecastNodeX
ForecastNode
X
x-coordinate in rijksdriehoek
22 nvoer F.nds.col3
ForecastNodeY
ForecastNode
Y
y-coordinate in rijksdriehoek
23 nvoer F.Inks.coM
ForecastLinklD
ForecastLink
ID
24 nvoer F.lnks.col2
ForecastLinkNodeA
ForecastLink
NodeA
25 nvoer F.lnks.col3
ForecastLinkNodeB
ForecastLink
NodeB
26 nvoer F.Inks.coM
ForecastLinkLength
ForecastLink
Length
27 nvoer F.BPRpars
ForecastLinkCap
ForecastLink
28 nvoer F.lnktype
ForecastLinkType
ForecastLink
34 invoer F.demand
ForecastDemandOrg
ForecastDemand
Demand
<
m
fnidx
doublé
fnidx
doublé
flidx
long
linkid
id
flidx
long
nodeid
id
flidx
long
nodeid
ink length
flidx
doublé
Cap
link capacity
flidx
doublé
Type
link type
flidx
long
demand
99. n_f,
doublé
ton
m
id
m
shp/h
linktype
id
n t
35 nvoer F.partysize.min_tonnage
ForecastPartySizeMinTo
ForecastPartySize
MinTonnage
partysize minimum tonnage
99
doublé
ton
ForecastPartySizeMaxTo ForecastPartySize
MaxTonnage
partysize maximum tonnage
99
doublé
ton
MeanTonnage
partysize mean tonnage
99
doublé
ton
StddevTonnage
partysize standard deviation
99
doublé
ton
oidx
long
oidx
string
didx
long
nnage
36 invoer F.partysize.maxjonnage
nnage
37 invoer F.partysize.mean_tonnage
ForecastPartySizeMeanT ForecastPartySize
onnage
38 invoer F.partysize.stddevjonnage
ForecastPartySizeStddev ForecastPartySize
Tonnage
tonnage
39 invoer S.origs
OrgNodelD
Origin
NodelD
40 invoer S.orignames
OrgName
Origin
Name
41 invoer S.destis
DestNodelD
Destination
NodelD
name of origin
42 invoer S.destisnames
DestName
Destination
Name
name of destination
didx
string
43 invoer S.linktypenames
LinkTypeName
LinkType
Name
name of linktype
It
string
44 invoer S.shiptypenames
ShipTypeName
ShipType
Name
name of shiptype
st
string
45 invoer S.ShipCapacity
ShipTypeCapacity
ShipType
Capacity
carrying capacity of ships
st
doublé
47 invoer S.ShipSUfactor
ShipTypeSUFactor
ShipType
SUFactor
ship unit factors
st
doublé
46 invoer S.ShipAcces2Link
ShipTypeLinkTypeAllowe ShipTypeLinkType
Allowed
matrix that says which ship use
st.lt
boolean
d
id
nodeid
id
ton
which link
48 invoer S.Freeflowspeed
Parameters
FreeFlowSpeed
FreeFlowSpeed
free flow speed
49 invoer S.goodgroupnames
GoodGroupName
GoodGroup
Name
name of goodgroup
Rap94 - Softwarespecificatie Omkapseling
MATLAB-prototype t.b.v. de Integratie in
BVMS 0.2
18 januari 2001
nodeid
doublé
99
km/h
string
12
(
(
50 invoer S.can_transport
ShipTypeGoodGroupAllo ShipTypeGoodGrou Allowed
matrix that says which ships can
wed
p
transport which goods
51 uitvoer B.triplist.org
3aseTripOrg
BaseTrip
52 uitvoer B.triplist.dst
3aseTripDst
53 uitvoer B.triplist.shiptype
3aseTripSt
54 uitvoer B.triplist. goodgroup
BaseTripGg
55 uitvoer B.triplist.amount
56 uitvoer B.routelist
(
st, gg
boolean
Origin
trip destination
btidx
long
nodeid
id
BaseTrip
Destination
trip destination
btidx
long
nodeid
id
BaseTrip
ShipType
trip shiptype
btidx
long
shiptype id
BaseTrip
Goodgroup
trip goodgroup
btidx
long
goodgro id
BaseTripAmount
BaseTrip
Amount
trip number of ships
btidx
doublé
3aseRoute
BaseRoute
Route
trip route
Dtidx,
long
up
shp
linkid
id
ridx
57 uitvoer B.linkload
BaseLinkload
BaseLinkload
Linkload
link load in ship equivalents
blidx
doublé
58 uitvoer F.triplist.org
ForecastTripOrg
ForecastTrip
Origin
trip destination
ftidx
long
nodeid
id
59 uitvoer F.triplist.dst
ForecastTripDst
ForecastTrip
Destination
trip destination
ftidx
long
nodeid
id
60 uitvoer F.triplist.shiptype
ForecastTripSt
ForecastTrip
ShipType
trip shiptype
ftidx
long
shiptype id
61 uitvoer F.triplist.goodgroup
ForecastTripGg
ForecastTrip
Goodgroup
trip goodgroup
ftidx
long
goodgro id
62 uitvoer F.triplist.amount
ForecastTripAmount
ForecastTrip
Amount
trip number of ships
ftidx
doublé
63 uitvoer F.routelist
ForecastRoute
ForecastRoute
Route
trip route
ftidx, ridx long
64 uitvoer F.linkload
ForecastLinkload
ForecastLinkload
Linkload
link load in ship equivalents
flidx
65 invoer model_const.n_model_vars
NumShipChoiceCoefs
Dimensions
NumShipChoiceCo size of the ShipChoiceCoef index
66 invoer model_const.n_goodstypes
NumGoodGroups
Dimensions
NumGoodGroups
size of the GoodGroup index
long
67 invoer model_const. n_shiptypes
NumShipTypes
Dimensions
NumShipTypes
size of the ShipType index
long
Parameters
NumDaysInSimPer number of days that go into 1
shp
up
doublé
shp
linkid
id
shp
long
efs
68 invoer model_const.N_days_in_simul NumDaysInSimPeriod
ation_period
69 invoer model_const.N_sailing_days_p NumDaysSaillnYear
iod
Parameters
er_year
70 invoer model_const.N_saillng_days_p NumDaysSailInSeason
Rap94 - Softwarespecificatie Omkapseling
MATLAB-prototype t.b.v. de Integratie in
BVMS 0.2
18 januari 2001
d
NumDaysSaillnYe number of days that go into 1 year
long
d
long
d
ar
Parameters
er_season
71 invoer model_const.n_shpmntsz_cats NumShipmenCats
long
simulation period
NumDaysSailInSe number of days that go into 1
ason
Dimensions
season
NumShipmentCats size of the ShipmentCat index
long
13
(
(
(
(
72 invoer model_const.max_risk_cats
NumRiskCats
Dimensions
NumRiskCats
size of the RiskCat index
long
73 invoer model_const.n_origs
NumOrigins
Dimensions
NumOrigins
size of the Origin index
long
74 invoer model_const.n_dests
^umDestinations
Dimensions
NumDestinations
size of the Destination index
long
75 invoer model_const.season
CurrentSeason
Parameters
CurrentSeason
the season to be calculated
long
76 invoer model_const.penalty_factor
-leetLimitPenalty
Parameters
FleetLimitPenalty
factor by which to reduce ship type
doublé
season
id
riskcat
id
use when fleetsize is constrained
77 invoer model_const.max_constr_iter
MaxFleetSizelterations
Parameters
MaxFleetSizelterati maximum number of iterations in
ons
78 invoer model_const.flnm_err_logfile
79 invoer model_const.n_risk
80 invoer model_const.beta
ShipChoiceLogFilename Parameters
GoodGroupMaxRisk
GoodGroup
long
fleet size
ShipChoiceLogFile the error logfile for the shipchoice
string
name
model
MaxRisk
maximum risk category modelled
99
long
gg.scc
doublé
GoodGroupShipChoiceC GoodGroupShipCho Coef
NumShipChoiceCoef model
oef
iceCoef
coefficients for each goodgroup
81 invoer model_const.origs
OrgNodelD
Origin
NodelD
(see varid 40)
oidx
long
nodeid
id
82 invoer model_const.dests
DestNodelD
Destination
NodelD
(see varid 42)
didx
long
nodeid
id
83 invoer model_const.s_index
MonthSeason
Month
Season
indicates to which season a month mo
long
id
st
long
shp
ton
belongs. (the parameter sjndex
must be filled with month numbers
for the current season, see
'read_fltdata.m')
84 invoer model_const.n_models
85 invoer FltData.fltcnstr
86 invoer FltData.ship_avail
=1
This parameter is hardcoded on 1
ShipChoiceSizeConstrain Parameters
ShipChoiceSizeCo size_constraint indicator
t
nstraint
ShipTypeFleetSize
ShipType
FleetSize
available number of ships by ship
type
87 invoer FltData.ship_cap
ShipTypeCapacity
88 invoer FltData.is_containership
ShipTypelsContainership ShipType
89 invoer FltData.canJransport
ShipTypeGoodGroupAllo ShipTypeGoodGrou Allowed
ShipType
Capacity
(see varid 45)
st
doublé
IsContainership
indicates if theshiptype is a
st
boolean
st, gg
boolean
containership
wed
Rap94 - Softwarespecificatie Omkapseling
MATLAB-prototype t.b.v. de Integratie in
BVMS 0.2
18 januari 2001
(see varid 50)
P
14
(
(
(
(
90 invoer FltData.costJixed
ShipTypeCostFixed
ShipType
CostFixed
fixed costs
st
doublé
euro
91 invoer FltData.cost_wait
ShipTypeCostWaiting
ShipType
CostWaiting
waiting costs
st
doublé
euro/h
92 invoer FltData.costJdling
ShipTypeCostldle
ShipType
Costldle
idling costs
st
doublé
euro/h
93 invoer FltData.cosLsail_full
ShipTypeCostSailFull
ShipType
CostSailFull
sailing costs filled-up
st
doublé
euro/h
94 nvoer FltData.cosLsaiLempty
ShipTypeCostSailEmpty
ShipType
CostSailEmpty
sailing costs empty
st
doublé
euro/h
DemandFactor
demand factor by month and goods gg, mo
95 invoer SSD.monthly_demand_factors GoodGroupMonthDeman GoodGroupMonth
d Factor
96 invoer SSD.P_risk_category
doublé
type. Sums to 1 over month index
GoodGroupRiskCatProba GoodGroupRiskCat Probability
probability of goods for each
bility
goodgroup of being in a risk
99. rc
doublé
gg, shc
doublé
gg, shc
doublé
wd
doublé
99
doublé
category. Sums to 1 over riskcat
index
97 invoer SSD. P_shipment_size_d
GoodGroupShipmentCat GoodGroupShipmen Probability
Probability
tCat
probability distribution of shipment
size for goodgroups having a
certain size. Sums to 1 over
shipmentcat index
98 invoer SSD.shipment_size
99 invoer SSD.daily_demand_factors
GoodGroupShipmentCat GoodGroupShipmen Maximum
maximum number of tonnes in a
Max
tCat
sipment category
WorkdayDemandFactor
Workday
DemandFactor
demand factor by day and goods
type. Sums to 1 over day index
100 invoer SSD.fraction_containerised
GoodGroupContainerFra GoodGroup
ction
Rap94 - Softwarespecificatie Omkapseling
MATLAB-prototype t.b.v. de Integratie in
BVMS 0.2
18 januari 2001
ContainerFraction
fraction of goods being
containerised
15
(
(
(
(
B.2. Indices
id
code naam
beschrijving
min max
1n
nodeid
node's
2n_f
nodeid_from
node's (used as 'from')
3n_t
nodeid_to
node's (used as 'to')
4gg
goodgroup
1
10
5 oidx
orginidx
1
9
6 didx
dstidx
1
9
7st
shiptype
1
3
8 It
linktype
1
3
9 bnidx
basenodeidx
base node index
1
54
10 blidx
baselinkidx
base link index
1
126
11 btoidx
basetripobsidx
base observated trip index
1
810
12 btidx
basetripidx
base trip index
1
13 fnidx
forecastnodeidx
forecast node index
1
54
14 flidx
forecastlinkidx
forecast link index
1
126
15 ftoidx
forecasttripobsidx
forecast observated trip index
1
810
16 ftidx
forecasttripidx
forecast trip index
1
17 ridx
routeidx
index in a route
1
18 1
linkid
link
19 rc
riskcat
risk category
20 sec
shpehoicecoef
ship choice coëfficiënt number
21 mo
month
22 wd
workday
monday til friday
23 shc
shipmentcat
shipment size category
54
12
Rap94 - Softwarespecificatie Omkapseling
MATLAB-prototype t.b.v. de Integratie in
BVMS 0.2
18 januari 2001
5
16
(
(
(
(
B.3. Enumeratiewaarden
id
code naam
4 gg
5 oidx
beschrijving
goodgroup
orginidx
entry
waarde
NSTR„1
1
NSTR_2
2
NSTR_3
3
NSTR_4
4
NSTR_5
5
NSTR_6
6
NSTR_7
7
NSTR_8
8
NSTR_9
9
NSTR_10
10
Rotterdam
Zeeland
Maastricht
Venlo
Duitsland
Twente
Delfzijl
Harlingen
velsen
6 didx
dstidx
7 st
shiptype
8 It
zie orgnidx
linktype
Rap94 - Softwarespecificatie Omkapseling
MATLAB-prototype t.b.v. de Integratie in
BVMS 0.2
18 januari 2001
CEMTJI
1
CEMTJII
2
CEMT_V
3
CEMTJI
1
CEMTJII
2
CEMT_V
3
17
C.
Bestanden
Bestand
Onderdeel
Beschrijving
BVMS.reg
installatie
Initiële registry waarden
B VMSCalculator05 .exe
rekenmodule
Rekenmodule COM-object
libmat.dll
matlab API
DLL nodig voor het lezen/schrijven van Matlab files
libmx.dl!
matlab API
DLL nodig voor het lezen/schrijven van Matlab files
libut.dll
matlab API
DLL nodig voor het lezen/schrijven van Matlab files
RegBVMSCalcO5.bat
installatie
Registreert de rekenmodule
db\BasisIn(QQQ).mdb
invoer
Voorbeeld invoer database
db\ProgUit(QQQ).mdb
uitvoer
Voorbeeld uitvoer database
Executable\basisjaar.exe
matlab model
Rekent het basisjaar door van het Matlab model
Executable\bvms.exe
matlab model
Test programma voor de visualisatie van Matlab invoer en uitvoer
bestanden
Executable\compiler.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\gui.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\gui_sgl.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\hardcopy.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\hardcopy_sgl.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\hg.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\hg_sgl.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\libeng.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\libmat.dll
matlab API
DLL nodig voor het lezen/schrijven van Matlab files
Executable\libmatlb.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\libmatlbmx.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\libmcc.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\libmmfile.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\libmx.dll
matlab API
DLL nodig voor het lezen/schrijven van Matlab files
Executable\libut.dll
matlab API
DLL nodig voor het lezen/schrijven van Matlab files
Executable\mpath.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\progjaar.exe
matlab model
Rekent het prognosejaar door van het Matlab model
Executable\runbatch.exe
matlab model
Roept achtereenvolgens basisjaar.exe en progjaar.exe aan
Executable\sgl.dll
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\uiw.dll
matlab model
DLL nodig voor het runnen van het Matlab model
matlab model
DLL nodig voor het runnen van het Matlab model
Executable\uiw sgl.dll
Simulation\.. .\basis_in.bvm
invoer
Invoer bestand wordt aangemaakt door rekenmodule
Simulation\...\basis_uit.bvm
tijdelijk
Tijdelijk bestand wordt aangemaakt door Matlab model
Simulation\.. .\prog_uit.bvm
uitvoer
Uitvoer bestand wordt aangemaakt door Matlab model
Rap94 - Softwarespecificatie Omkapseling
MATLAB-prototype t.b.v. de Integratie in
BVMS 0.2
18 januari 2001
18
D. Registry keys
HKEY_LOCAL_MA CHINE\SOFTWARE\QQQ Delft\B VMS\O. 5 \Simulation
Locatie waar tijdelijke mappen worden aangemaakt voor het schrijven van in- en uitvoer
bestanden van het Matlab model.
HKEY_LOCAL_MACHINE\SOFTWARE\QQQDelft\BVMS\0.5\Source
Bestanden uit deze directory worden gekopieerd naar de tijdelijke directory voor het draaien van
het Matlab model. Voor de huidige implementatie is dit niet vereist.
HKEY_LOCAL_MACHINE\SOFTWARE\QQQDelft\BVMS\0.5\Executable
De executable die wordt opgestart voor het draaien van het Matlab model.
HKEY_LOCAL_MACHINE\SOFTWARE\QQQDelft\BVMS\0.5\TotalTime
Totale tijd benodigd voor het volledig doorrekenen van het Matlab model. Deze waarde wordt
gebruikt om een voortgangsindicatie te kunnen geven.
Rap94 - Softwarespecificatie Omkapseling
MATLAB-prototype t.b.v. de Integratie in
BVMS 0.2
18 januari 2001
19
QQQ Delft - Rap95
Softwarespecifïcatie van het simulatieframework
Alle rechten voorbehouden.
Niets uit deze uitgave mag worden
vermenigvuldigd en/of openbaar
gemaakt door middel van druk,
fotokopie, microfilm of op welke
andere wijze dan ook, zonder
voorafgaande toestemming van
QQQ Delft
© 2001 QQQ Delft
QQQ Delft
Kluyverweg 2a
2629 HT Delft
T: 015-2682581
F: 015-2682591
W: http://www.qqq.nl
23 januari 2001
Auteurs:
ir. G.F. Zegwaard,
ir. J.K. de Haan
1.
ALGEMEEN
5
1.1
1.2
1.3
Introductie
Conventie
Abstractieniveaus
5
5
5
2.
MESSAGEHANDLING
7
2.1
ObjectModel
2.2
Objecten
2.2.1
Message
2.2.2
Listitem
2.2.3
MessageArgument
2.2.4
MessageHandler
2.2.5
Sender
2.2.6
Receiver
7
7
7
8
8
8
8
9
3.
GENERIEKE SIMULATIE
10
3.1
Algemeen
10
3.2
ObjectModel
10
4.
HET COLLECTION OBJECT
11
4.1
Object definitie
4.1.1
Operations
4.1.2
Associations
4.2
Messages
4.2.1
SM_ADD
4.2.2
SM_REMOVE
5.
HET COLLECTEDOBJECT OBJECT
11
11
11
11
11
11
12
5.1
Algemeen
5.2
Object definitie
5.2.1
Operations
5.2.2
Associations
5.3
Messages
5.3.1
SM_MOVE
5.3.2
SM_SETCOLL
12
12
12
12
12
12
12
6.
BVMS SIMULATIE
13
6.1
Algemeen
13
6.2
ObjectModel
13
7.
HET SCHIP OBJECT
17
7.1
Algemeen
7.2
Object definitie
7.2.1
Attributes
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
17
17
17
7.2.2
Operations
7.2.3
Associations
7.3
Het Route hulpobject
7.3.1
Operations
7.3.2
Associations
7.4
Het Routeltem hulpobject
7.4.1
Attributes
7.4.2
Associations
7.5
Messages
7.5.1
SM_SETCOLL
7.5.2
BM_INIT
17
17
17
17
17
17
17
18
18
18
18
8.
19
HET VAARWEG OBJECT
8.1
Algemeen
8.2
Object definitie
8.2.1
Operations
8.2.2
Associations
8.3
Messages
8.3.1
SM_ADD
19
19
19
19
19
19
9.
20
HET WACHTRIJ OBJECT
9.1
Algemeen
9.2
Object definitie
9.2.1
Attributes
9.2.2
Operations
9.3
Messages
9.3.1
SM_ADD
9.3.2
SM_REMOVE
20
20
20
20
20
20
20
10.
21
HET BRUG OBJECT
10.1
10.2
10.3
10.3.1
10.3.2
10.3.3
10.4
10.4.1
10.4.2
10.4.3
10.4.4
10.4.5
10.5
11.
11.1
11.2
Algemeen
Statechart Diagram
Object definitie
Attributes
Operations
Associations
Messages
SM_ADD
SM_REMOVE
BM_SETSTATUS
BM_SETIDLE
BM_SETBUSY
Een voorbeeld
HET SLUIS OBJECT
Algemeen
Object
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
21
21
22
22
22
22
22
22
23
24
25
26
26
29
29
29
3
11.2.1
Operations
11.2.2
Associations
11.3
Messages
11.3.1
SM_ADD
29
29
29
29
12.
31
HET KOLK OBJECT
12.1
12.2
12.3
12.3.1
12.3.2
12.3.3
12.4
12.4.1
12.4.2
12.4.3
12.4.4
12.4.5
12.5
13.
Algemeen
Statechart Diagram
Object definitie
Attributes
Operations
Associations
Messages
SM_ADD
SM_REMOVE
BM_SETSTATUS
BM_SETIDLE
BM_SETBUSY
Een voorbeeld
EXTERNE OBJECTEN
13.1
Object definities
13.1.1
VaarwegParams
13.1.2
BrugParams
13.1.3
SluisParams
13.1.4
KolkParams
13.1.5
ScheepsKlasseParams
13.1.6
Reis
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
31
32
33
33
33
33
34
34
35
35
36
37
37
40
40
40
40
40
41
41
41
1. Algemeen
1.1 Introductie
De hier beschreven simulatie is gebaseerd op de simulatie beschreven in 'Functional
Specification Modelsystem Inland shipping Version 0.5: Specification of the assignment and
simulation model'. Voor een inhoudelijke beschrijving wordt naar dit rapport verwezen.
1.2 Conventie
SO
Stroomopwaarts, een richting op een vaarweg, onder brug of door sluis
SA
Stroomafwaarts, een richting op een vaarweg, onder brug of door sluis
Collection
Een verblijfplaats voor een object: een vaarweg, wachtrij, sluis, brug of kolk
CollectedObjectEen CollectedObject is een object dat zich in een Collection bevindt: een schip
SM
Simulation message
BM
BVMS message
1.3 Abstractieniveaus
Voor het BVMS Event systeem wordt uitgegaan van drie abstractieniveaus en een datalaag:
Messagehandling: beschrijft Messages, MessageArguments, Listitems, de Messagehandler,
Senders en Receivers.
Generieke simulatie: beschrijft Collections en CollectedObjects
BVMS simulatie: beschrijft Sluizen, Kolken, Bruggen, Vaarwegen, Wachtrijen, Schepen,
Routes en Routeltems.
Datalaag: slaat informatie op over Sluizen, Kolken, Bruggen, Vaarwegen, Reizen en
ScheepsKlasses.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
Onderstaand diagram geeft de onderliggende samenhang weer tussen de verschillende objecten
in de drie abstractieniveaus en een datalaag.
s
Q.
•MM
|MessageHandler)
Message
MessageArgument)
1
o
»
A\
1
\/
Sender
3 03
O »
A.
Receiver
2
A^ZA
j? ^
W
3 O
e a3
-^|CollectedObiect|
1
2S
Z^/U_
s.
Sluis
Brug
Schip
Vaarweg
A
VMS
JL.
v>
Kolk
|<
1
3
£
5*
Wachtrij
O
\/
\/
BrugParams I
0)
sr
ö
•o
5T
\/
VaarwegParams
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
SchKlasseParamsk
2. Messagehandling
2.1 ObjectModel
Hieronder ziet u het object model uitgewerkt als Class Diagram. Alle objecten zullen in de
volgende paragrafen een voor een worden beschreven.
MessageArgument
«Type
1
2
Message
«•Type
•ToStringO
*-TypeToSlring(
+ToString()
+TypeToString()
/ \
1
1
MessageHandler
1
+GetTime )
•PostMes sage(in "Sender: Sender, in "Receiver: Receiver. in &Message : Message)
+RunMes >ageLoopO
•Schedult Message(in Time : long. in "Sender: Sender, in "Receiver: Receiver, in &Message : Message)
+SendMe >sage(in 'Sender: Sender, in "Receiver: Receiver, in &Message : Message)
\
Listitem
•Time
f
1
1
1
Sender
\
Receiver
*GetType()
*PostMessage(in "Receiver: Receiver. in SMessage : Message)
#ScheduleMessage(in Time : long, in "Receiver: Receiver. in &Message : Message)
#Sendlv1essage(in "Receiver : Receiver, in «.Message : Message)
•ToStringO
*GetType()
••ProcessMes. age(in &Message: Message)
+ToSthng()
2.2 Objecten
Gebruik ScheduleMessage, PostMessage en SendMessage van de MessageHandler om
messages naar een receiver te sturen. Uitstaande messages worden door de MessageHandler
bijgehouden in een (op tijd gesorteerde) lijst. Het is niet mogelijk messages aan de lijst toe te
voegen met een tijd die voor de laatst uitgevoerde message ligt. De messages worden uitgevoerd
in volgorde van tijd.
2.2.1 Message
Attributes
Type
Een identifier voor het message type
Operations
To String
TypeToString
Geeft de message in string-vorm (voor logging)
Geeft het type van de message in string-vorm (voor logging)
Associations
Arguments
De argumenten van de message
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
2.2.2 Listitem
Attributes
Time
Tijdstip waarop bericht verwerkt moet worden
Associations
Message
Sender
Receiver
Het bericht
De zender van het bericht
De ontvanger van het bericht
2.2.3 MessageArgument
Attributes
Type
Value
Het type van het argument
De waarde van het argument
Operations
ToString
TypeToString
Geeft de message in string-vorm (voor logging)
Geeft het type van de message in string-vorm (voor logging)
2.2.4 MessageHandler
Attributes
LogFile
Een file waarin alle messages gelogged worden (als deze attribuut niet
gezet is wordt er niet gelogged).
Operations
GetTime
RunMessageLoop
ScheduleMessage
PostMessage
SendMessage
Geeft het huidige tijdstip.
Voert alle messages uit de queue uit totdat deze leeg is.
Plaatst een message in de queue op een tijd
Plaatst een message in de queue op de huidige tijd
Stuurt een message meteen uit (niet via de queue)
Associations
MessageList
Lijst van af te werken message, gesorteerd op tijdstip. De oudste
message uit de lijst bepaalt het huidige tijdstip.
2.2.5 Sender
Operations
GetType
ToString
ScheduleMessage
PostMessage
SendMessage
geeft het type object (virtual / abstract)
geeft een identificatie voor het object als string (virtual / abstract)
Plaatst een message in de queue op een tijd
Plaatst een message in de queue op de huidige tijd
Stuurt een message meteen uit (niet via de queue)
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
Associations
MessageHandler
Een verwijzing naar de te gebruiken messagehandler
2.2.6 Receiver
Operations
GetType
ToString
ProcessMessage
Geeft het type object (virtual / abstract)
Geeft een identificatie voor het object als string (virtual / abstract)
Voert een message uit (virtual / abstract)
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
3. Generieke simulatie
3.1 Algemeen
In de generieke simulatie worden de basisprincipes van de simulatie geimplementeerd. Bij de
simulatie is sprake van van Collections en CollectedObjects. Gedurende de simulatie worden
CollectedObject van Collectie naar Collectie verplaatst.
3.2 ObjectModel
Hieronder ziet u het object model uitgewerkt als Class Diagram. Alle objecten zullen in de
volgende paragrafen een voor een worden beschreven.
TT
ZATY
CollectedObject
Collection
'GetTypeO
-ProcessMessage(in &Message:
-ToStringQ
'GetTypeO
>ProcessMessage(in AMessage: Message)
KToStnngQ
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
10
4. Het Collection object
4.1 Object definitie
4.1.1 Operations
GetType
ToString
ProcessMessage
Geeft het type object (overloaded)
Geeft een identificatie voor het object als string (overloaded)
Voert een default simulatie message uit (overloaded)
4.1.2 Associations
CollectedObjects
Een verzameling van de objecten in deze Collection
4.2 Messages
4.2.1 SM_ADD
Argument 1: CollectedObject
Argument 2: LastCollection
Opmerkingen
Zet een CollectedObject in een Collection. De default processor voegt het CollectedObject aan
de CollectedObjects vector toe. Het tweede argument is de vorige Collection voor het
CollectedObject.
4.2.2 SM_REMOVE
Argument 1: CollectedObject
Opmerkingen
Verwijderd een CollectedObject uit een Collection. De default processor haalt het
CollectedObject uit de CollectedObjects vector.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
11
5. Het CollectedObject object
5.1 Algemeen
De generieke messages werken op het abstractieniveau van de generieke simulatie. Er worden
op dit niveau vier typen messages onderscheiden: SM_MOVE, SM_ADD, SM_REMOVE en
SM_SETCOLL.
5.2 Object definitie
5.2.1 Operations
GetType
ToString
ProcessMessage
Geeft het type object (overloaded)
Geeft een identificatie voor het object als string (overloaded)
Voert een default simulatie message uit (overloaded)
5.2.2 Associations
Collection
De Collection waarin dit object zich bevindt.
5.3 Messages
5.3.1 SM_MOVE
Argument 1: Collection
Opmerkingen
Verplaatst een CollectedObject naar een nieuwe Collection. De default processor stuurt een
SM_REMOVE met als argument zichzelf naar de oude Collection als deze ongelijk NULL is en
een SM_ADD met als argument zichzelf en de vorige Collection naar de nieuwe Collection als
deze ongelijk NULL is.
5.3.2 SM_SETCOLL
Argument 1: Collection
Opmerkingen
Zet de huidige Collection. De default processor zet de Collection property.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
12
6. BVMS Simulatie
6.1 Algemeen
Op het abstractieniveau van de BVMS simulatie wordt een algoritme doorlopen voor het
afhandelen van een message. Bij de beschrijving van deze messages zijn activity diagrams
gegeven om het procesverloop aan te geven. Het procesverloop bestaat uit een opeenvolging
van acties die elk een nieuwe message tot gevolg hebben. Voor de hier niet genoemde messages
wordt de default processor (processor op het abstractie niveau van de generieke simulatie)
uitgevoerd.
6.2 ObjectModel
Hieronder ziet u het object model uitgewerkt als Class Diagrammen. Allereerst de objecten rond
het Schip object. Een Schip is een overerving van een CollectedObject. De kenmerken van het
schip worden vooral bepaald door de relatie van het schip met een Reis object. Het Reis object
wordt verder niet beschreven in deze documentatie. Alleen de kenmerken die van belang zijn
voor de simulatie zijn hier weergegeven: het leeg of beladen zijn van het schip en de verwijzing
naar een scheepsklasse. De verwijzing naar de scheepsklasse gebeurt via een verwijzing naar het
ScheepsKlasseParams object. Het ScheepsKlasseParams object bevat de parameters die in de
(invoer) database aan een scheepsklasse worden gekoppeld (hier zijn alleen de parameters die
van belang zijn voor de simulatie weergegeven).
ajCollecledObjectj
Schip
#Huidige Positie
•GetTypeO
•ProcessMessage(in &Message: Message)
•RichtingO
* Volgend eLinkQ
+RouteCollection(in Inr: long)
+RouteRichting(in Inr; long)
•Richting
•Leeg
Sch Klasse Params
+Breedte
•Hoogte
•Lengte
•Snelheid
•SnelheidLeeg
Naast een verwijzing naar een Reis object heeft het Schip object een verwijzing naar een
CollectionRoute object. Deze verwijzing wordt pas gezet op het moment dat het schip wordt
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
13
geïnitialiseerd (vandaar de 0..1 relatie naar CollectionRoute). Om de route te zetten wordt een
vanuit de code een extern route-selectie algoritme aangeroepen. Een CollectionRoute is een
vector met verwijzingen naar Collection (Vaarweg, Brug, Sluis) objecten en een vector met de
vaarrichting (stroomopwaarts of stroomafwaarts) op elke Collection object. Schepen kunnen
CollectionRoute objecten delen. De positie in-de route wordt via het HuidigePositie argument
als index in de CollectionRoute bijgehouden.
Het Vaarweg object is een eenvoudige uitbreiding op het basis Collection object. Het Vaarweg
object heeft een verwijzing naar VaarwegParams object voor de kenmerken van de vaarweg.
Het VaarwegParams object bevat de parameters die in de (invoer) database aan een vaarweg
worden gekoppeld (hier zijn alleen de parameters die van belang zijn voor de simulatie
weergegeven).
Collection
1
Vaarweg
+GetType()
+ProcessMessagepn &Message : Message)
_y
VaarwegParams
•Lengte
•MaxSnelheid
+MaxSnelheidLeeg
•Stroomsnelheid
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
14
Het Brug object heeft een verwijzing naar twee wachtrijen (één stroomopwaarts en één
stroomafwaarts). Kenmerken van de brug zijn beschikbaar via het BnigParams object,
vergelijkbaar met het VaarwegParams object voor de vaarweg.
Brug
«Status
Wdle
#StatusChange
+GetType()
+ProcessMessage(in &Message Message)
1
1
1
\ j
BnigParams
•Hoogte
+EindBediend
+MaxOpenTijd
•MinDicMTijd
+OmkeerTijd
+OpenDichtTijd
2
\l/
Wachtrij
•BinnenkomstTijden
•GetTypeü
•LangsteWachtTljdO
•LangstWachtendeSchipO
+ProcessMessage(in &Message: Message)
+StarlBediend
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
15
Het Sluis object heeft een verwijzing naar één of meer kolken. Elke kolk heeft een verwijzing
naar twee wachtrijen (één stroomopwaarts en één stroomafwaarts). Zowel het Sluis object als
het Kolk object hebben een verwijzing naar respectievelijk SluisParams en KolkParams
objecten voor de (invoer) parameters.
Collection
Wachtrij
Sluis
+BinnenkomstTijden
+GetType<)
•LangsteWachtTijdO
+LangstWachtendeSchip()
•ProcessMessagefin &Message: Message)
/ \
1
•GetTypeO
•ProcessMessage(in &Message: Message)
1
1
1
\ /
\l/
Kolk
«Status
Sldle
•GetTypeO
+ProcessMessage(in &Message: Message)
1
SluisParams
•EindBediend
•InTijd
•InTijdWacht
•OpenDichtTijd
•OpvolgTijd
•StartBediend
•UitTijd
1
1
\ /
KolkParams
•Breedte
•Lengte
•NivelleerTijd
•
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
16
7. Het Schip object
7.1 Algemeen
Het schip object wordt gebruikt om een aantal kenmerken op te slaan en om de route bij te
houden. Het enige 'actieve' dat het schip doet is bij het overgaan van elke link de 'rest' van de
route bijhouden. Voor de overige objecten wordt daarbij de volgende link (Collection) en de
richting op de huidige link (Collection) beschikbaar gesteld via respectievelijk de attributen
NextCollection en Richting.
7.2 Object definitie
7.2.1 Attributes
HuidigePositie
7.2.2 Operations
GetType
ProcessMessage
VolgendeLink
Richting
7.2.3 Associations
Route
Reis
SchKlasseParams
Een index in de route van het schip die aangeeft waar op de route het
schip zich bevindt.
Geeft het type object (overloaded)
Voert een BVMS simulatie message voor het schip uit (overloaded)
Bepaalt met behulp van CollectionRoute en HuidigePositie het
volgende Collection object (vaarweg, brug of sluis) op de route
Bepaalt met behulp van CollectionRoute en HuidigePositie de richting
op het huidige Collection object (vaarweg, brug of sluis).
De route van het schip
De reis die het schip uitvoert
De (invoer) parameters van het schip.
7.3 Het Route hulpobject
7.3.1 Operations
RouteCollection
RouteRichting
7.3.2 Associations
Route
Geeft het Collection object (vaarweg, brug of sluis) voor een index
(volgnummer) op de route
Geeft de richting op een Collection object (vaarweg, brug of sluis)
voor een index (volgnummer) op de route
Een vector met de Routeltem objecten de route uit bestaat.
7.4 Het Routeltem hulpobject
7.4.1 Attributes
Richting
Een vaarrichting door een Collection (vaarweg, brug of sluis).
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
17
7.4.2 Associations
Collection
Een Collection object (vaarweg, brug of sluis).
7.5 Messages
7.5.1 SM_SETCOLL
Argument 1: Collection
Opmerkingen
Na het uitvoeren van de default processor worden de Richting en NextCollection attributes
geupdate door naar de route van het schip te kijken. Indien de nieuwe Collection een link
(vaarweg, brug of sluis) is van de route wordt de Richting en de NextCollection bijgewerkt. De
Richting attribuut krijgt de waarde van de richting behorende bij de nieuwe link. De
NextCollection wordt gelijk gezet aan de volgende link op de route. Indien het schip aan een
Collection wordt toegevoegd dat zich niet op de route bevindt (bijvoorbeeld een wachtrij) dan
behouden Richting en NextCollection hun waarde.
7.5.2 BMJNIT
Opmerkingen
Deze message wordt aan het begin van de simulatie gescheduled voor het moment dat het schip
'in actie' moet komen. Op dat moment kan het schip zijn route door het netwerk bepalen op
basis van dan aanwezige belastingsinformatie.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
18
8. Het Vaarweg object
8.1 Algemeen
Het vaarweg object gedraagt zich op hoofdlijnen als een standaard Collection object. Er wordt
echter bij het 'toevoegen' van een schip op de vaarweg meteen het doorvaren naar de volgende
link op de route van het schip gescheduled.
8.2 Object definitie
8.2.1 Operations
GetType
ProcessMessage
Geeft het type object (overloaded)
Voert een BVMS simulatie message voor de vaarweg uit (overloaded)
8.2.2 Associations
VaarwegParams
De (invoer) parameters van de vaarweg
8.3 Messages
8.3.1 SM_ADD
Argument 1: Schip
Argument 2: LastCollection
Opmerkingen
Naast de default processor van CollectedObject wordt het overgaan naar de volgende link op de
route van het schip gescheduled. Hiervoor wordt de vaartijd op de vaarweg berekend:
Lengte
Schip.Richting = SA/\ Schip.IsBeladen
m\n{Schip. Snelheid, MaxSnelheid) + StroomSnelheid
Lengte
Schip.Richting = SA A -^Schip.IsBeladen
mm(Schip.Snelheid, MaxSnelheidLeeg) + StroomSnelheid
Lengte
Schip.Richting = SO A Schip.IsBeladen
min(Schip.Snelheid,MaxSnelheid) — StroomSnelheid
Lengte
Schip.Richting = SO A Schip.IsBeladen
min(Schip.Snelheid', MaxSnelheidLeeg)- StroomSnelheid
Met behulp van deze vaartijd wordt het moment waarop het schip de vaarweg verlaat bepaalt.
Op dit moment wordt een SM_MOVE message naar de 'NextCollection' van het schip
gescheduled. Dit zorgt ervoor dat het schip zich naar de volgende link op de route begeeft.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
19
9. Het Wachtrij object
9.1 Algemeen
Het wachtrij object wordt gebruikt om wachtrijen voor bruggen en sluizen te modelleren. Het
gedraagt zich in hoofdlijnen als een eenvoudig Collection object. Als toevoeging wordt van elk
schip in de wachtrij bijgehouden wanneer het schip de wachtrij is binnengekomen. Deze
gegevens maken het mogelijk om het langst wachtende schip (via de LangstWachtendeSchip
operatie) en de langste wachttijd (via de LangsteWachttijd operatie) beschikbaar te stellen aan
bruggen en sluizen. Een wachtrij is een abstract object. Het modelleert niet een fysieke rij
schepen, maar een abstracte verzameling van schepen die wachten om hun route te kunnen
vervolgen.
9.2 Object definitie
9.2.1 Attributes
Binnenkomsttijden
Een vector met de binnenkomsttijd (s vanaf start simulatie) voor elk
schip in de wachtrij.
9.2.2 Operations
GetType
ProcessMessage
LangsteWachttijd
Geeft het type object (overloaded)
Voert een BVMS simulatie message voor de wachtrij uit (overloaded)
De wachttijd van het schip in de wachtrij dat zich het langst (op
volgorde van binnenkomst) in de wachtrij bevindt
LangstWachtendeSchip Het schip in de wachtrij dat zich het langst (op volgorde van
binnenkomst) in de wachtrij bevindt
9.3 Messages
9.3.1 SM_ADD
Argument 1: Schip
Argument 2: LastCollection
Opmerkingen
Naast het uitvoeren van de default processor van het Collection object wordt het tijdstip waarop
het schip in de wachtrij is geplaatst opgeslagen.
9.3.2 SM_REMOVE
Argument 1: Schip
Opmerkingen
Naast het uitvoeren van de default processor van het Collection object wordt het tijdstip waarop
het schip de wachtrij binnenkwam verwijderd.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
20
10. Het Brug object
10.1 Algemeen
Het brug object maakt gebruik van twee wachtrijen: voor beide zijden van de brug één wachtnj.
De richting van de schepen in de wachtrij wordt gebruikt voor de benaming van de wachtrij. Dit
betekent dat de Wachtrij SO stroomafwaarts ten opzichte van de brug ligt, deze wachtrij bevat
immers schepen die stroomopwaarts naar de brug varen. Schepen die onder het vaste gedeelte
van de brug door kunnen ondervinden alleen de passeertijd als vertraging. Schepen die door de
brug moeten worden in een wachtrij geplaatst tot het moment dat de ze door kunnen varen. Er
kan slechts één schip tegelijk door het beweegbare gedeelte van de brug varen. Bovendien
worden steeds eerst alle schepen vanuit één richting doorgelaten voordat schepen uit de andere
richting doorgelaten worden. Er zijn limieten aan gesteld aan de maximale tijd dat de brug open
mag staan en aan de minimale tijd die de brug gesloten moet blijven.
10.2 Statechart Diagram
Onderstaand diagram toont de toestanden waarin de brug zich kan bevinden en de
gebeurtenissen die toestandswijzigingen veroorzaken. De beschikbare opentijd is het verschil
tussen MaxOpenTijd en de tijd die de brug geheel open staat. De tijd die de brug nodig heeft om
te openen ofte sluiten wordt hierbij niet in beschouwing genomen.
Wachtrij SO niet leeg
en Beschikbare opentijd
Brug is omhoog
voor schip SO
Openingtime verstreken
en Wachtrij SO ouder of gelijk SA
'
~
.
...
Omkeertjd verstreken
en
Schip arriveert
en brug is bediend
'
.
,
Brug is omlaag
MinGeslotenTijd verst/eken
Brug gaat
omhoog
Wachtrij SO en SA leeg
of onvoldoende beschikbare opentijd
Wachtrij SO is teeg
e n W a c m r j j S A |s ^
|eeg
Beschikbare opentijd groter dan omkeertijd
Omkeren naar
Omkeren naar
SA
SQ
Wachtrij SA is leeg
en Wachtrij SO is niet leeg
en Beschikbare opentijd groter
dan omkeertijd
Brug gaat
omlaag
Omkeertijd verstreken
Wachtrij SO en SA leeg
of Onvoldoende beschikbare opentijd
Brug is
geforceerd
omlaag
OpeningTime verstreken
en Wachtrij SA ouder dan SO
~ ~ — , - ^or'sc°nT SA 9
Wachtrij SA niet leeg
en Beschikbare opentijd
ClosingTime verstreken
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
21
10.3 Object definitie
10.3.1 Attributes
Status
StatusChange
Idle
De status van de brug (OPENEND, OPENSA, OPENSO, SLUITEND
of GESLOTEN)
Geeft aan wanneer voor het laatst de status van de brug is veranderd
(s vanaf start simulatie)
Geeft aan of de brug in rust is
10.3.2 Operations
GetType
ProcessMessage
Geeft het type object (overloaded)
Voert een BVMS simulatie message voor de brug uit (overloaded)
10.3.3 Associations
BnigParams
Wachtrijen
De (invoer) parameters van de brug
De wachtrijen behorende bij deze brug (stroomopwaarts en
stroomafwaarts).
10.4 Messages
10.4.1 SM_ADD
Argument 1: Schip
Argument 2: LastCollection
Opmerkingen
In plaats van de default processor (processor van de generieke Collection) wordt het volgende
algoritme doorlopen:
[Schip kan onder brug door]
Indien het schip onder het vaste deel van de brug door kan (Schip.Hoogte < Hoogte) wordt het
doorvaren naar de volgende link op de route (Schip.NextCollection) gescheduled. Als vaartijd
wordt de PasseerTijd attribuut genomen.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
22
Indien de brug open en idle is wordt de brug busy gezet en wordt het doorvaren naar de
volgende link op de route (Schip.NextCollection) gescheduled. Als vaartijd wordt de
PasseerTijd attribuut genomen. Beredeneerd kan worden dat deze situatie zich alleen kan
voordoen indien het schip uit een wachtrij komt.
In alle andere gevallen (indien een schip arriveert dat niet onder het vaste deel van de brug door
kan) wordt het schip aan de wachtrij toegevoegd en wordt, indien de brug gesloten en idle is, het
openen van de brug gestart.
10.4.2 SM_REMOVE
Argument 1: Schip
Opmerkingen
Naast het uitvoeren van de default processor wordt het volgende algoritme doorlopen:
/ \
[Anders]
[Met schip kon onder de brug door]
Indien het schip niet onder het vaste deel van de brug door kon varen (Schip.Hoogte >= Hoogte)
wordt de brug idle gezet. De brug was dan immers busy omdat het schip dat nu wordt
verwijderd er door voer.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
23
10.4.3 BM_SETSTATUS
Argument 1: OPENEND, OPENSA, OPENSO, SLUITEND of GESLOTEN
Opmerkingen
De nieuwe status wordt gezet. Daarnaast wordt het volgende algoritme doorlopen:
Schedule brug open
in richting vh langst
wachtende schip
(opendichttijd)
-[opensa/so]
\
Zet de brug
busy
-[sluitend]
brug idle
(omkeertijd)
/
/^Schedule d e ^
brug gesloten
(opendichttijd)
Schedule de
brug idle
(MinDichtTijd)
-[gesloten]
[tijd + mingeslotentijd
valt buiten bedieningsperiode]
\1/
Schedule de
brug idle
(StartBediend)
De brug wordt alleen 'openend' gezet indien er minstens één schip in één van de wachtrijen ligt.
De brug wordt busy gezet om aan te geven dat de brug actiefis. Daarnaast wordt een 'open'
status in de richting van de wachtrij met het langst wachtende schip gescheduled. Het 'openend'
zetten doet zich voor in twee situaties: 1) de vorige keer dat de brug open was heeft hij niet alle
schepen kunnen doorlaten in de 'MaxOpenTijd' en de 'MinDichtTijd' is verstreken dus de brug
kan weer open om de resterende schepen door te laten of 2) een schip arriveert terwijl de brug
gesloten en in rust (idle) is. Dit laatste laatste geval doet zich alleen voor indien beide
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
24
wachtrijen leeg zijn. Het schip wordt gedurende het opengaan van de brug in de wachtrij
geplaatst.
Indien de brug de status 'open' krijgt in een vaarrichting kunnen zich twee situaties voordoen:
1) de brug is open gezet vanuit de status 'openend', in dit geval was de brug busy en dient de
brug 'idle' te worden gezet zodat schepen doorgelaten kunnen worden of 2) de brug is open
gezet vanuit de 'open' stand in de andere vaarrichting, in dit geval was de brug 'idle' en dient
het gedurende de omkeertijd 'busy' gezet te worden.
Indien de brug 'sluitend' wordt gezet wordt de gesloten toestand van de brug gescheduled,
ondertussen wordt de brug 'busy' gezet. Als de brug op 'gesloten' wordt gezet wordt de brug
'busy' gehouden totdat de MinGeslotenTijd is verstreken. Indien de tijd waarop de brug weer
idle zou worden gezet buiten de bedieningstijd valt wordt de brug 'busy' gehouden tot het
moment waarop de brug weer bediend wordt.
10.4.4 BMLSETIDLE
Opmerkingen
Zet de brug op idle (de brug is niet meer busy). Daarnaast wordt het volgende algoritme
doorlopen:
[Anders]
[Anders]
Zet de brug
openend
[Wachtrijen zijn leeg]
[Brug is open]
[Er wachten nog schepen
in dezelfde richting]
[Maximale opentijd is verstreken]
i
I
[Anders]
[Anders]
[Anders]
[Anders]
[Resterende opentijd is
meer dan de omkeertijd]
[Wachtrijen zijn leeg]
Zet de brug
sluitend
AL
'
Laat het
volgende schip
v binnenvaren
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
Draai de
vaarrichting om
25
Bij 'idle' zetten van de brug wordt bekeken of er nog schepen zijn die doorgelaten kunnen
worden. De brug wordt 'openend' gezet indien de brug gesloten is en er zijn wachtende
schepen. Indien de brug open is wordt de brug gesloten als 1) de maximale opentijd is
verstreken, 2) de wachtrijen leeg zijn of 3) er alleen schepen vanuit de tegenovergestelde
vaarrichting wachten en de maximale opentijd minder is dan de omkeertijd. Indien dit zich niet
voordoet wachten er schepen en is er voldoende tijd om ze door te laten. Het langst wachtende
schip met de vaarrichting waarvoor de brug open staat wordt doorgelaten. De vaarrichting wordt
omgekeerd indien er geen schip meer wacht in deze vaarrichting.
10.4.5 BM_SETBUSY
Opmerkingen
Zet de brug op busy (de brug is niet meer idle)
10.5 Een voorbeeld
Met behulp van een sequence diagram staat hieronder uitgewerkt hoe één schip door een in rust
verkerende brug vaart. Het schip komt van vaarweg 1 en vaart na de brug naar vaarweg2 en
vervolgens naar vaarweg3. Het schip vaart stroomafwaarts.
Het hier beschreven voorbeeld is redelijk eenvoudig omdat slechts één schip wordt beschouwd.
Op het moment dat er meerdere schepen (uit beide richtingen) betrokken worden, worden de
message-reeksen uiteraard complexer. Echter het hier weergegeven basisprincipe blijft intact.
De serie messages die wordt verwerkt wordt gestart door het binnekomen van een SM_MOVE
message naar de brug vanuit vaarweg 1. Deze message is gescheduled op het moment dat het
schip toegevoegd werd aan vaarweg 1. De acties die plaatsvinden zijn: het verplaatsen van het
schip naar de wachtrij en het starten van het openen van de brug.
'iHan^er3 I I
Schip
I Vaarweg 1 I
Brug
SM_MOVE(Brug) _
I I Wachtrij I I Vaarweg2
;
SM.REMOVE(Schip)SM_SETCOLL(NULL)
SM.ADD^nip.Vaarwegp
L
S
™**>'
_
SM_SETCOLL(Wachtrij)
BM_SETSTATUS
(Openend)
!
, BM_SETBUSY
Schedule(Brug. BM_SETSTATUS(OpenSA))
<
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
26
De 'OpenSA' status wordt gescheduled. Na het verstrijken van de OpenDichtTijd wordt deze
message uitgevoerd. Op dit moment kan het schip de brug binnenvaren:
Message
Handler
Schip
I I Vaarwegi I I
Brug
I I Wachtrij I I Vaarweg2 I
BM_SETSTATUS(OpenSA)
SM_MOVE(Brug)
I SM_REMOVE(Schip)
SM_SETCOLL(NULl)
SM.ADD(Schip. Wachtrij)
SM_SETCOLL(Brug)
BM.SETBUSY
I
Scriedule(Schip, SM_MOVE(vaarweg2))
Het doorvaren naar Vaarweg2 wordt bij het binnenvaren gescheduled. Op het moment dat
PasseerTijdWacht is verstreken wordt de SM_MOVE(Vaarweg2) message naar het schip
gestuurd. Dit zorgt ervoor mede voor dat de brug zich weer zal sluiten:
Door de bovenstaande serie messages worden twee messages gescheduled: 1) het zetten van de
'gesloten' status van de brug en 2) het doorvaren van het schip naar vaarweg3. Het doorvaren
naar vaarweg3 wordt hier niet verder behandeld.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
27
Na het verstrijken van de OpenDichtTijd komt de SETSTATUS(Gesloten) message binnen bij
de brug:
Message I I
Handler
Schip
I I Vaarwegi I I
Brug
I I Wachtrij I I Vaarweg2 I
SM_SETSTATUS(Gesloten)
Schedule(Brug. SM_SETIDLE)
SM.SETIDLE
Op het moment dat de status op gesloten wordt gezet wordt de brug idle (in rust) gescheduled
nadat de MinDichtTijd verlopen is. Dit is reeds in het bevenstaande schema weergegeven.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
28
11. Het Sluis object
11.1 Algemeen
Het sluis object bestaat uit één of meer kolken. De enige verantwoordelijkheid van een
sluisobject is het kiezen van een kolk voor een aankomend schip. Wachtrijen zijn aan de kolk
objecten en niet aan het sluis object gekoppeld.
11.2 Object
11.2.1 Operations
GetType
ProcessMessage
Geeft het type object (overloaded)
Voert een BVMS simulatie message voor de sluis uit (overloaded)
11.2.2 Associations
Kolken
SluisParams
Een vector met alle kolken van de sluis
De (invoer) parameters van de sluis
11.3 Messages
11.3.1 SM_ADD
Argument 1: Schip
Argument 2: LastCollection
Opmerkingen
In plaats van de default processor (processor van de generieke Collection) wordt het schip naar
één van de kolken van de sluis doorgestuurd. Dit gebeurt volgens onderstaande beslisregels.
Voor een definitie van de hoeveelheid schepen die in een kolk passen wordt verwezen naar het
kolk object.
1) Selecteer alle kolken die breed en lang genoeg zijn voor het schip. Dit zijn alle mogelijke
kandidaat-kolken om gekozen te worden voor het schip.
2) Van de kandidaten worden de kolken geselecteerd die open staan in de richting van het
schip.
3) Van de overgebleven kandidaten selecteer de kolk(en) waarbij de schepen in de kolk plus de
schepen die in dezelfde richting als het aankomende schip wachten plus het aankomende
schip in de kolk passen.
4) Van de overgebleven kandidaten kies de kolk(en) waarbij de beschikbare ruimte voor
nieuwe schepen na het binnenvaren van de schepen uit de wachtrij plus het aankomende
schip het kleinst is.
5) Indien de overgebleven kandidatenlijst niet leeg is selecteer de kolk met het laagste
volgnummer. Dit is de geselecteerde kolk. Indien de overgebleven kandidatenlijst leeg is ga
naar stap 6.
6) Selecteer uit de kandidaten na stap 1 de kolken die niet open staan in de richting van het
schip.
7) Van de overgebleven kandidaten kies de kolk(en) waarbij de schepen in die in dezelfde
richting als het aankomende schip wachten plus het aankomende schip in de kolk passen.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
29
8) Van de overgebleven kandidaten kies de kolk(en) waarbij de beschikbare ruimte voor
nieuwe schepen na het binnenvaren van de schepen uit de wachtrij plus het aankomende
schip het kleinst is.
9) Indien de overgebleven kandidatenlijst niet leeg is selecteer de kolk met het laagste
volgnummer. Dit is de geselecteerde kolk. Indien de overgebleven kandidatenlijst leeg is ga
naar stap 10.
10) Selecteer uit de kandidaten na stap 1 de kolken met het minste aantal schepen in de wachtrij.
11) Selecteer de kolk met het laagste volgnummer. Dit is de geselecteerde kolk.
Uiteraard moet het zo zijn dat het schip in ieder geval in één van de kolken past. De simulatie
wordt beëindigd op het moment dat dit niet het geval is. Dit zou echter niet plaats moeten
vinden omdat bij het selecteren van de route gecontroleerd wordt of de lengte en breedte van het
schip de maximale breedte en de maximale lengte van de link (sluis) niet overstijgt. Deze
voorwaarde zou moeten voorkomen dat het schip door een sluis zonder een 'passende' kolk
gestuurd wordt. Een onopgelost probleem ontstaat op het moment dat het schip wel in de kolk
past maar het oppervlak van het schip 75% van de oppervlak van de kolk overtreft.
Om er voor te zorgen dat het schip bij kan houden waar het zich in de route bevindt, wordt voor
het doorsturen naar de kolk de collectie van het schip middels een SM_SETCOL message op
sluis gezet.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
30
12. Het Kolk object
12.1 Algemeen
Binnen het kolk object wordt het nivelleren, openen en sluiten van kolken geregeld. Daarnaast
zorgt het kolk object voor de afhandeling van schepen door de sluis. Elk kolk object heeft twee
wachtrijen: voor beide zijden van de sluis één wachtrij. De richting van de schepen in de
wachtrij wordt gebruikt voor de benaming van de wachtrij. Dit betekent dat de Wachtrij SO
stroomafwaarts ten opzichte van de sluis ligt, deze wachtrij bevat immers schepen die
stroomopwaarts naar de sluis varen. Een kolk in rust staat altijd open om schepen van één van
beide richtingen binnen te laten. Als schepen zijn binnengelaten wordt de kolk gesloten, wordt
de kolk genivelleerd en wordt de sluis geopend. Vervolgens kunnen de schepen uit de kolk
gelaten worden en ligt de kolk in rust voor de andere vaarrichting.
Het aantal schepen dat in een kolk past wordt als volgt gedefinieerd: Indien de totale
oppervlakte van de schepen in de kolk minder is dan 75% van de oppervlakte van de kolk
passen de schepen in de kolk. Een kolk is vol indien het eerstvolgende schip in de wachtrij voor
schepen in de richting waarvoor de kolk openstaat niet meer in de kolk past (indien de
oppervlak van de schepen in de kolk plus het eerstvolgende schip in de wachtrij meer is dan
75% van de oppervlakte van de kolk).
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
31
12.2 Statechart Diagram
Onderstaand diagram toont de toestanden waarin de kolk zich kan bevinden en de
gebeurtenissen die toestandswijzigingen veroorzaken.
Kolk is open
(SO)
Een schip SA arriveert
Schip is binnen
en wachtrij SO
is leeg of kolk is vol
Kolk sluit,
nivelleert en
opent (SO)
Schip is binnen
en wachtrij SO
is leeg of kolk is vol -
Een schip s 0
arrjveert
Schip is uitgevaren,
kolk is leeg
en wachtrij SO
is leeg
Schip SO vaart
kolk binnen
(direct)
Schip is uitgevaren
en kolk is niet leeg
Schip is binnen,
wachtrij SO is niet
leeg en kolk is niet vol
Schip is uitgevaren,
kolk is leeg
en wachtrij SO
is niet leeg
Schip SO vaart
kolk binnen
(uit wachtrij)
—
Schip is binnen.
wachtrij SO is niet
teeg en kolk is niet vol
2x open-/sluittijd plus
nivelleertijd is verstreken
2x open-/sluittijd plus
nivelleertijd is verstreken
Schip is binnen,
wachtrij SA is niet
leeg en kolk is niet vol
Kolk laat schip
SO uitvaren
Schip is uitgevaren,
kolk is leeg
en wachtrij SA
is niet leeg
Schip SA vaart
kolk binnen
(uit wachtrij)
-
Schip is binnen
en wachtrij SA
is leeg of kolk is vol
Kolk sluit (SA)
Schip is binnen,
wachtrij SA is niet
leeg en kolk is niet vol
Schip is uitgevaren
en kolk is niet leeg
Schip is binnen
en wachtrij SA
is leeg of kolk is vol
Schip is uitgevaren,
kolk is leeg
en wachtrij SA
is leeg
Een schip SA arriveert
Een schip SO arriveert
Kolk is open
(SA)
Een schip wordt doorgestuurd naar de wachtrij tenzij de kolk open en in rust is (in bovenstaand
schema 'Kolk is open (SA)' en 'Kolk is open (SO)'). Onder 'schip is binnen' en een 'schip is
uitgevaren' wordt verstaan dat de invaartijd of uitvaartijd is verstreken. Daarbij wordt er ook
onderscheid gemaakt tussen invaartijd vanuit de wachtrij en invaartijd vanuit de vorige link
(vaarweg, brug of sluis).
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
32
12.3 Object definitie
12.3.1 Attributes
Status
Idle
De status van de brug (INVARENDSA, INVARENDSO,
NIVELLERENDSA, NIVELLERENDSO, UITVARENDSA,
UITVARENDSO)
Geeft aan of de kolk in rust is
12.3.2 Operations
GetType
ProcessMessage
Geeft het type object (overloaded)
Voert een BVMS simulatie message voor de kolk uit (overloaded)
12.3.3 Associations
KolkParams
Sluis
De (invoer) parameters van de kolk
De sluis waar de kolk een onderdeel van uitmaakt.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
33
12.4 Messages
12.4.1 SM_ADD
Argument 1: Schip
Argument 2: LastCollection
Opmerkingen
In plaats van de default processor (processor van de generieke Collection) wordt het volgende
algoritme doorlopen:
»®
[LastCollection is
een Wachtrij]
[Anders]
Schedule de
kolk idle
(SluisInTijdWacht)
O
[Kolk bevat meerdere schepenj
Schedule de
kolk idle
(SluisInTijdWacht + OpvolgTijd)/
Indien de kolk open staat voor de richting van het schip en de kolk in rust is kan het schip direct
de kolk binnenvaren. Het schip wordt toegevoegd aan de kolk, de kolk wordt 'busy' gezet. De
kolk wordt 'idle' gezet nadat het schip de kolk binnengevaren is (na het verstrijken van
'SluisInTijd' of'SluisInTijdWacht' eventueel verlengd met OpvolgTijd). Als het schip niet
meteen de kolk in kan varen wordt het schip aan de wachtrij toegevoegd.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
34
12.4.2 SM_REMOVE
Argument 1: Schip
Opmerkingen
Naast het uitvoeren van de default processor wordt de kolk op 'idle' gezet. Dit wordt meteen
gedaan indien er geen schepen meer in de kolk aanwezig zijn. Indien er nog wel schepen
aanwezig zijn wordt het op 'idle' zetten gescheduled na het verlopen van de OpvolgTijd:
[Anders]
[Kolk is leeg]
Zet de kolk idle
12.4.3 BM_SETSTATUS
Argument 1: INVARENDSA, INVARENDSO, NIVELLERENDSA, NIVELLERENDSO,
UITVARENDSA, UITVARENDSO
Opmerkingen
De nieuwe status wordt gezet. Daarnaast wordt het volgende algoritme doorlopen:
— [invarendsa/so] - -
. — [anders] ^ - Zet de kolk idle
,..'
.
[t„d buiten
bedierangspenode]
Schedule de
k<J|kid(e
(Startbediend)
Schedule de kolk
— [nivellerendsa/so] - - Zet de kolk busy
.
s-
,^'^ich^d *
nivelleertijd)
- [uitvarendsa/so] —-1 - Zet de kolk idle
Indien de kolk invarend wordt gezet (dit gebeurt automatisch nadat elk schip uit de kolk is
gevaren) wordt bekeken of de kolk daadwerkelijk schepen kan laten binnenvaren. Indien de
sluis niet meer bediend is wordt de kolk pas 'idle' gescheduled op het moment dat de kolk weer
wel bediend is. Is de kolk nog wel bediend dan wordt de kolk meteen 'idle' gezet. Het 'idle'
zetten van de kolk zorgt ervoor dat schepen de kolk binnenvaren.
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
35
Als de kolk nivellerend is gezet wordt de brug 'busy' gezet. Daarnaast wordt de kolk op
'uitvarend' gescheduled na het verstrijken van 2x de OpenDichtTijd en de nivelleertijd.
De brug wordt idle gezet om schepen daadwerkelijk uit te laten varen op het moment dat de
kolk op uitvarend wordt gezet.
12.4.4 BM_SETIDLE
Opmerkingen
Zet de kolk op idle (de kolk is niet meer busy). Daarnaast wordt het volgende algoritme
doorlopen:
[Kolk is invarendsa/so]
[Wachtrijen zijn leeg]
[Kolk is leeg]
De kolk kan 'idle' worden gezet om schepen binnen te laten varen of om schepen uit te laten
varen. Indien de kolk open staat om schepen uit te laten varen wordt de status altijd weer op
'busy' gezet. Als de kolk leeg is (alle schepen zijn al uit de kolk gevaren) wordt de kolk op
invarend gezet. Anders laat de kolk het volgende schip uitvaren (door een move naar de
volgende link na de SluisUitTijd te schedulen). Let op dat bij het 'invarend' zetten de kolk
'invarend' gezet wordt voor de andere richting!
Indien de kolk open staat om schepen binnen te laten varen zijn er drie mogelijkheden: er
gebeurt niets, de sluis gaat nivelleren naar de andere richting of er wordt een schip uit de
wachtrij binnengelaten. Er gebeurt niets indien beide wachtrijen leeg zijn en de kolk ook leeg is.
Het volgende schip wordt binnengelaten indien de wachtrij in de richting waarvoor de sluis
open staat niet leeg is en de kolk niet vol is. In alle overige gevallen wordt de kolk genivelleerd
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
36
(als de kolk vol is of als de wachtrij in de richting waarvoor de kolk open is leeg is en 1) de kolk
niet leeg is of 2) de andere wachtrij niet leeg is).
Zie voor een definitie voor het 'vol' zijn van een kolk de opmerkingen onder 'Algemeen' van
het Kolk object.
12.4.5 BM_SETBUSY
Opmerkingen
Zet de kolk op busy (de kolk is niet meer idle).
12.5 Een voorbeeld
Met behulp van een sequence diagram staat hieronder uitgewerkt hoe één schip door een in rust
verkerende sluis vaart die in rust open staat voor de richting van het schip. Het schip komt van
vaarweg 1 en vaart na de sluis naar vaarweg2 en vervolgens naar vaarweg3. Het schip vaart
stroomafwaarts.
Het hier beschreven voorbeeld is redelijk eenvoudig omdat slechts één schip wordt beschouwd.
Op het moment dat er meerdere schepen (uit beide richtingen) betrokken worden, worden de
message-reeksen uiteraard complexer. Echter het hier weergegeven basisprincipe blijft intact.
De serie messages die wordt verwerkt wordt gestart door het binnenkomen van een SM_MOVE
message naar de sluis vanuit vaarweg 1. Deze message is gescheduled op het moment dat het
schip toegevoegd werd aan vaarweg 1. Het schip wordt in plaats van in de sluis geplaatst te
worden direct doorgestuurd naar een kolk. De kolk blijft busy gedurende SluisInTijd.
Message
Handler
Schip
SM_MOVE(Sluis)
Vaarweg 1
Kolk
Sluis
I I Vaarweg2 I
4]SM_REMOVE(Schip)X
^
SM_SETCOLL(NULL)
u
SM_ADD(Schip. Vaarwegi)
ft
SM_SETCOLL(Sluis)
SM_ADD(Schip,
Vaarwegi)
SM.SETCOLLIKolk)^
BVLSETBUSY
Schedule(Kolk, BM_SETIDLE)
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
37
Op het moment dat het schip de kolk is binnengevaren wordt begonnen met het nivelleren van
de kolk in de richting van het schip. De kolk wordt uitvarend gescheduled na nivelleertijd plus
twee keer de OpenDichtTijd.
I Ser
| r ^ H
| Vaarwegi | |
Sluis
| |
BM_SETIDLE
Kolk
| | Vaarweg2 |
BlvLSETSTATUS(NivellerendSA)
I
I
I
I
| Schedjle(Kolk, BM_SETSTATUS(UitvarendSA))
I
Zodra de kolk uitvarend wordt, wordt het schip verplaatst naar vaarweg2 (na SluisUitTijd).
rsn r^n r^-^i r^n
BM_SETSTATUS(UitvarendSA)
I
Schedule(Schip. SM_MOVE(Vaarweg2))
Kolk
Vaarweg2
BM_SETIDLE
I
|
I
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
38
Zodra het schip uit de kolk gevaren is wordt de kolk op invarend gezet (in de tegenovergestelde
vaarrichting). Het schip wordt tenslotte toegevoegd aan vaarweg2 en er wordt gescheduled dat
deze zijn reis vervolgt naar vaarweg3.
Message
Handler
1 I
Schip
I I Vaarwegi I I
Sluis
I I
Kolk
I I Vaarweg2 I
SM_MOVE(Vaarweg2) I
l SM_REMOVE(Schip) I
1
SM_SETCOIL(NUIL)'
BM.SETSTATUS(lnvarendSO)
BM.SETIDLE
SM_ADD(Schip, Kolk)
r
SM_SETCOLL(Vaarweg2)
Schedule(Schip, SM_M0VE(Vaarweg3))
u
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
39
13. Externe obj ecten
13.1 Object definities
Binnen de beschrijving van de BVMS simulatie is ervan uitgegaan dat er een aantal externe
objecten aanwezig zijn. Daarbij gaat het met name om kenmerken vanuit de (invoer)database. In
dit hoofdstuk staan deze objecten beschreven.
13.1.1 VaarwegParams
Attributes
Lengte
MaxSnelheidLeeg
MaxSnelheid
StroomSnelheid
De lengte van de vaarweg (m)
De maximale snelheid op de vaarweg voor onbeladen schepen (m/s)
De maximale snelheid op de vaarweg voor beladen schepen (m/s)
De stroomsnelheid op de vaarweg (m/s)
13.1.2 BrugParams
Attributes
Hoogte
StartBediend
EindBediend
MaxOpenTijd
MinDichtTijd
OmkeerTijd
OpenDichtTijd
PasseerTijd
De hoogte van het vaste gedeelte van de brug (m)
Het tijdstip op de dag waarop bediening start (s vanaf 0:00:00)
Het tijdstip op de dag waarop bediening eindigt (s vanaf 0:00:00)
De maximale tijd dat de brug open mag staan, exclusief de tijd
benodigd om open en dicht te gaan (s)
De minimale tijd dat de brug dicht moet blijven nadat hij open is
geweest (s)
De benodigde wachttijd om de vaarrichting door de open brug te
veranderen (s)
De benodigde tijd om de brug te openen ofte sluiten (s)
De benodigde tijd voor een schip om de brug te passeren (s)
13.1.3 SluisParams
Attributes
StartBediend
EindBediend
InTijd
InTijdWacht
OpenDichtTijd
OpvolgTijd
UitTijd
Het tijdstip op de dag waarop bediening start (s vanaf 0:00:00)
Het tijdstip op de dag waarop bediening eindigt (s vanaf 0:00:00)
De benodigde tijd om een schip een kolk in te varen vanuit de vorige
vaarweg, brug of sluis (s)
De benodigde tijd om een schip een kolk in te varen vanuit een
wachtrij (s)
De benodigde tijd om de sluis te openen ofte sluiten (s)
De benodigde wachttijd tussen het een kolk in- of uitvaren van twee
schepen (s)
De benodigde tijd om een schip een kolk uit te varen (s)
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
40
Associations
Kolken
Een vector met de kolken (KolkParam objecten) van de sluis
13.1.4 KolkParams
Attributes
Breedte
Lengte
Nivelleertijd
De breedte van de kolk (m)
De lengte van de kolk (m)
De benodigde tijd om de kolk te nivelleren (s)
13.1.5 ScheepsKlasseParams
Attributes
Breedte
Lengte
Hoogte
Snelheid
SnelheidLeeg
De breedte van elk schip in de scheepsklasse (m)
De lengte van elk schip in de scheepsklasse (m)
De hoogte van elk schip in de scheepsklasse (m)
De snelheid van elk beladen schip in de scheepsklasse (m)
De snelheid van elk onbeladen schip in de scheepsklasse (m)
13.1.6 Reis
Attributes
Leeg
Geeft aan of het schip onbeladen (leeg) of beladen (vol) is (m).
Rap95 - Softwarespecificatie van het simulatie-framework
23 januari 2001
41
QQQ Delft - Rap99
Testverslag simulatie-framework
Adviesdienst Verkeer en Vervoer
Alle rechten voorbehouden.
Niets uit deze uitgave mag worden
vermenigvuldigd en/of openbaar
gemaakt ÖOOT middel van druk,
fotokopie, microfilm of op welke
andere wijze dan ook, zonder
voorafgaande toestemming van
QQQ Delft
©2001 QQQ Delft
QQQ Delft
Kluyverweg 2a
2629 HT Delft
T: 015-2682581
F: 015-2682591
W: http://www.qqq.nl
1 februari 2001
Auteurs:
ir J.K. de Haan,
ir G.F. Zegwaard
1.
VOORBEELD SIMULATIE
3
1.1
Inleiding
3
1.2
Opzet
3
2.
RESULTATEN
5
2.1
2.2
2.3
Statistieken Brug
Statistieken Sluis
Statistieken Vaarweg
5
7
8
Rap99 - Testverslag simulatie-framework
1 februari 2001
1. Voorbeeld Simulatie
1.1 Inleiding
Om de implementatie van de simulatie- en toedelingsmodule beschreven in Softwarespecificatie
Toedelingsmodule BVMS Fase 2' en 'Softwarespecificatie van het simulatie-framework' te
testen, is een eenvoudig voorbeeld uitgewerkt. Het voorbeeld bestond uit het simuleren van een
aantal reizen door een eenvoudig netwerk, waarbij de routekeuze voor een reis bestond uit het
kiezen van de route met de kortste gemiddelde reistijd gemeten vanaf het begin van de
simulatie.
Als uitvoer zijn de laatste reistijd, de gemiddelde reistijd en het aantal schepen in de link
uitgezet tegen de tijd. Hoewel niet getracht is realistische waarden te vinden voor alle
parameters, geven deze uitvoer grafieken toch een redelijk beeld van het gedrag van de
verschillende netwerkonderdelen. Bij de keuze van de invoer is juist gekozen voor een
overbelasting van het netwerk zodat de routekeuze ondanks zijn eenvoud toch verandert
gedurende het verloop van de simulatie.
1.2 Opzet
Onderstaand figuur beeld schematisch het gebruikte netwerk af. Het netwerk bestaat uit een
parallel geschakelde brug (BRG1), sluis (SLS1) en vaarweg (VW2) en een aanvoer en afvoer
vaarweg (VW1 en VW3). De pijlen geven de stroomrichting aan. De sluis bevat 1 kolk.
VW1
-VW3
-VW2-
Rap99 - Testverslag simulatie-framework
1 februari 2001
De toedelingsmodule gaat (in tegenstelling tot de simulatiemodule) uit van gerichte links.
Onderstaand figuur beeld het gebruikte netwerk nogmaals af, maar nu in termen van gebruikte
links.
Tijdens de simulatie worden afwisselend, in een hoge constante frequentie, schepen het netwerk
opgestuurd van knoop 1 naar knoop2 en omgekeerd.
Rap99 - Testverslag simulatie-framework
1 februari 2001
2. Resultaten
De volgende paragrafen laten de statistieken zien van de parallel geschakelde brug, sluis en
vaarweg (stroomafwaarts). In het begin van de simulatie zijn nog geen reistijden bekend en
begint de routekeuze module schepen via de eerste route, de brug, te sturen. Zodra het eerste
schip de brug gepasseerd heeft en er een reistijd voor deze route bekend is, worden schepen naar
de sluis en tenslotte naar de vaarweg gestuurd.
Aangezien de gemiddelde reistijd voor de brug en de sluis een stuk korter is dan de (lange)
vaarweg, herziet de routekeuze module zijn voorkeur en stuurt schepen weer naar de brug en als
de reistijden hier beginnen toe te nemen ook naar de sluis. Op het moment dat de reistijden van
de brug en sluis (vanwege onvoldoende capaciteit) zodanig zijn toegenomen dat deze die van de
vaarweg evenaren, worden er geen schepen meer naar de brug en sluis gestuurd. Vanaf dat
moment nemen de wachtrijen weer af totdat er zich helemaal geen schepen meer in de brug of
sluis bevinden. Vanaf dat moment blijven de gemiddelde reistijden van deze links constant.
2.1 Statistieken Brug
In onderstaande grafieken staan de statistieken van de simulatie van de brug weergegeven.
Horizontaal staat de tijd uitgezet (in seconden vanaf middernacht) en verticaal respectievelijk de
laatste reistijd, gemiddelde reistijd en het aantal schepen (zowel in de wachtrij als onder de
brug). Niet de gehele simulatietijd is afgebeeld. Het stuk voor 25000 is weggelaten omdat de
reizen pas vanaf dit tijdstip zijn begonnen en het stuk na 62500 is weggelaten aangezien er niets
meer verandert: er varen alleen nog maar schepen over de vaarweg.
Onderstaande grafiek toont de laatste reistijd. Een reistijd (tijd benodigd om de brug te
passeren) wordt bekend op het moment dat een schip de brug verlaat. De pieken in grafiek
worden veroorzaakt door schepen die aankomen op het moment dat de brug net is gesloten
omdat de maximale opentijd is verstreken. De horizontale stukken in de grafiek kunnen twee
oorzaken hebben: of er komen geen schepen meer naar de brug en de brug is leeg (bijvoorbeeld
iets na 40000), of de brug staat open en de schepen zijn met dezelfde intervaltijd
binnengekomen in de wachtrij als nodig is om de brug te passeren (bijvoorbeeld iets na 52000)
(de reistijden van opeenvolgende schepen is dan gelijk).
Laatste reistijd
4000
o
o
CM
O
o
O
o
LO «
CO
en
CM CN
o
o
O
m o
o
O)
CM
CO
8
8 8
in
in
CM
CO
o
*r
CO
CO
o o o o
o o
o
o o o
o o
o
r
—
CO
IO
CO
CO
o
o
•<r
in
Rap99 - Testverslag simulatie-framework
1 februari 2001
o
CO
*r
LD
8 8
& in
•<*•
o
o o o
o
o o
o o o
o o
o o
o o
o o
ir> o in o m
o
o in o
m
o
CM
en o CM CO
m to CO o>
m in m in m in CO CO
De gemiddelde reistijd is bepalend voor de routekeuze in dit voorbeeld. De gemiddelde reistijd
wordt bepaald over alle reistijden van alle schepen die de brug gepasseerd zijn vanaf het begin
van de simulatie. Op de momenten dat de gemiddelde reistijd van de brug lager is dan die van
de sluis en de vaarweg, zal de routekeuze module schepen via de brug sturen (op ongeveer
28000+, 31000+ en 44000+). Op het moment dat de gemiddelde reistijd boven die van de
vaarweg uitkomt, zullen geen schepen de route via de brug meer kiezen. Zodra de laatste
schepen dan ook de brug verlaten hebben (om ongeveer 62500), zal de gemiddelde reistijd niet
meer veranderen.
Gemiddelde reistijd
1800
1600
1400
1200
1000
800
600
400
200
o
o
o
CM
O
O
in
CO
CM
O
O
O
o o
o
o ion o
CO
CM o>
CM CO
in
CM
CO
8
CJ
3
o
o o
o o o o o
o
in o in o
o
m
o
in h- CO
CO
CO
co
CO
o
TT
rr
rf
O
O
in o
ra- CO
TI-
8 8
o
m
r^
•3-
o
o
o o
o o
o o
o 8 8 8 o
in o m o m o
o
CM
in CO CO O5
o
in
ir) in in in
8
in
Het aantal schepen laat scherp stijgende lijnen zien op het moment dat de route via de brug
verkozen wordt, maar de brug niet geopend is voor schepen in deze richting. Een afname vindt
plaats doordat meer schepen de brug verlaten dan dat er nieuwe bijkomen. Horizontale stukken
zijn te verklaren doordat er geen schepen meer bijkomen (er wordt een andere route gekozen),
maar de brug nog niet geopend is voor schepen in deze richting.
Aantal Schepen
25 4
20
15 4i
10 -j
:
!*3fi*ïï'
0-ü
isamSiï
o
o
o
o o
o o
o o
o o
o o
o o
o o
o o
o o
o o
o o
o o
o o
o o
o o
o o
o _~o
o
o i n o i n o i n o i n o m o i n o t n o i n ~
i o c o c o c n i - C M ' 3 - i n r - - c o O T - c O T ) - c o r ~
c M C M C M C M c o c o c o c o c o c o T i - T r ^ T r r r T i -
Rap99 - Testverslag simulatie-framework
1 februari 2001
o
en
Tt
in
o
m
o
~o
CM
m
_
m
co
m
O
o
m
m
o
o
m
co
m
o
o
o
co
m
o
o
in
o
m
o
o
o
co
T-
2.2 Statistieken Sluis
In onderstaande grafieken staan de statistieken van de simulatie van de sluis weergegeven.
Horizontaal staat de tijd uitgezet (in seconden vanaf middernacht) en verticaal respectievelijk de
laatste reistijd, gemiddelde reistijd en het aantal schepen (zowel in de wachtrij als in de kolk).
Niet de gehele simulatietijd is afgebeeld. Het stuk voor 25000 is weggelaten omdat de reizen
pas vanaf dit tijdstip zijn begonnen en het stuk na 62500 is weggelaten aangezien er niets meer
verandert: er varen alleen nog maar schepen over de vaarweg.
Onderstaande grafiek toont de laatste reistijd. Een reistijd (tijd benodigd om de sluis te
passeren) wordt bekend op het moment dat een schip de sluis verlaat. De piekjes in de grafiek
worden veroorzaakt door schepen die aankomen op het moment dat de kolk net is gesloten
omdat deze vol is. De horizontale stukken in de grafiek worden veroorzaakt doordat er geen
schepen meer naar de sluis komen en de sluis is leeg (bijvoorbeeld 26500+, 33000+ en 47500+).
Laatste reistijd
4000
3500
3000
2500
2000
1500
1000
500
u—
8
o
in
CM
o
o o
o o o o
o o o 8
o
oO o in o m
o L
CM
in
oo rn
t
n
o
CD
CM
CM
CM
CO
CO
CO
CO
CO
o
o o
o
o
in o
m
CO o
CO
CO TT
8
O
o
o
<->
in o
*f «7
rr 'S-
8
m
O
o o
o o 8 O
in ra in
CM co
Tf o
in IO m
o o
o o
o in
m co
IO
m
g 8 8 8
De gemiddelde reistijd is bepalend voor de routekeuze in dit voorbeeld. De gemiddelde reistijd
wordt bepaald over alle reistijden van alle schepen die de sluis gepasseerd zijn vanaf het begin
van de simulatie. Op de momenten dat de gemiddelde reistijd van de sluis lager is dan die van
de brug en de vaarweg, zal de routekeuze module schepen via de sluis sturen (op ongeveer
26000+, 29500+ en 38500+). Op het moment dat de gemiddelde reistijd boven die van de
vaarweg uitkomt, zullen geen schepen de route via de sluis meer kiezen. Zodra de laatste
schepen dan ook de sluis verlaten hebben (om ongeveer 47500), zal de gemiddelde reistijd niet
meer veranderen.
Rap99 - Testverslag simulatie-framework
1 februari 2001
Gemiddelde reistijd
1800
1600
1400
1200
1000
800
600
400
200
itisiisiiiif!
yitiiëïi
in
co
CM
CN
o
o
o
CO
8
CM
CM
m
O)
000
''fë'ï&sA'>y/*£i••^'•^•Z,i,• i, '•'•- '*-~ %\:.;.fy.%ty*:&.$.%*t
u J—
o o
o o
o m
cö
o o
o
o
m o
o
o
o
o
o
l»
o
o 8
m
o
co o
CO
r*co
m
co
J
y4*'*$?A?'<ffi'0'1 '•'::'0£&&'W''3$::'''?: ^^it&i 1 ^^'-
LO
o o O o o
o
o
o
m o
o in
r~ OT o
m
m
m
o o
o
o
m CO
o
8 8
o
CO
o
o
o
ft
o
o
CO
in
o
o
o
co
m
8 8 8
in
o
in
CO
co
Het aantal schepen laat korte stijgende lijnen zien op het moment dat de route via de sluis
verkozen wordt, maar de sluis niet geopend is voor schepen in deze richting. Een afname vindt
plaats doordat schepen de sluis verlaten. De korte periode tijd duidt op een zeer snelle nivelleeren passeertijd. De korte daling per keer laat zien dat de capaciteit van de kolk zeer beperkt is.
Aanta Schepen
25
20
i
15
10
:
5
' --,; •>y
;-. > .
!
'
'
-
:
•
"
;
:
•
•
:
V.-K
SI*-
§ï
-
'
:
0
'&••';•!
o
o
o
O
O
m
o o
o o
m o
co
CM
CM
CM
CO
CM
m
en
O
8
CO
o
o
in
CM
CO
O
8
o
o
m
o o
o o
o in
in
h-
CO
CO
co
co
o
o
r>
o
^r
O
O
O
O
in
O
O
•>jin
o
CO
"3-
o
o
o
CO
O
O
h-
O
O
O>
^~
o
m
O
O
\Ti
g
o
o1 &
O
CM
in
co
m
o
8
m
m
o
o
o
o
O
8
CO
in
o
in
O5
T-
m
un
co
CM
CD
2.3 Statistieken Vaarweg
In onderstaande grafieken staan de statistieken van de simulatie van de vaarweg weergegeven.
Horizontaal staat de tijd uitgezet (in seconden vanaf middernacht) en verticaal respectievelijk de
laatste reistijd, gemiddelde reistijd en het aantal schepen dat zich op de vaarweg bevindt
(stroomafwaarts). Niet de gehele simulatietijd is afgebeeld. Het stuk voor 25000 is weggelaten
omdat de reizen pas vanaf dit tijdstip zijn begonnen en het stuk na 62500 is weggelaten
aangezien er niets meer verandert: er varen alleen nog maar schepen over de vaarweg.
Onderstaande grafiek toont de laatste reistijd. Een reistijd (tijd benodigd om de sluis te
passeren) wordt bekend op het moment dat een schip de brug verlaat. De reistijd van de
vaarweg verandert niet aangezien de capaciteit van de vaarweg onbeperkt is en alle schepen
even snel varen in dit voorbeeld.
Rap99 - Testverslag simulatie-framework
1 februari 2001
8
Laatste reistijd
i n o m o i n o i n o i n o i n o L O O
c o c o a s * - C M * 3 - L o r * - c o o * - c o T r c o
o o
o o
m
490
o o o o o o o o o o o o o o
o o o o o o o o o o o o o o
C N C M C M C O C O C O C O C O C O T J - ^ - ^ - ^ - ^ -
o o o o o o o o o
o
o o o o o
o o
IO o
o m
o in
m
o o CM
co o
in m
CM
CO
m CO CD
lf>
in in in
s
s
De gemiddelde reistijd is bepalend voor de routekeuze in dit voorbeeld. Aangezien de reistijden
van alle schepen in deze simulatie hetzelfde zijn, is ook het gemiddelde constant. Op de
momenten dat dit gemiddelde lager is dan die van de brug en de sluis, zal de routekeuze module
schepen via de vaarweg sturen (op ongeveer 26500+ en 60000+). Op het moment dat de
gemiddelde reistijden van de brug en sluis boven die van de vaarweg uitkomen, zullen alle
schepen deze route kiezen.
Gemiddelde reistijd
1800
1600
1400
1200
1000
800
600
400
O
O
o
m o
in <D
CO
CM
CM
CM
8
8
8 8 8 8 8 8
in
LO
o m o m
in o GO 8
o» CO CM
CO 3 co co CO
CM
o
o o
o
in o
"3-
O
O
in
o
o
o
CO r—
500
u -*—
o o
o o
o o o o o o o o
o
o o
o
o
in o
m o
o
o
CNI
Oi
o>
m m m in ir)
s
000
200
o
o
CN
Het aantal schepen laat een stijgende lijn zien op het moment dat de route via de vaarweg
verkozen wordt, totdat het eerste schip de vaarweg verlaat. De eerste keer treedt dan direct weer
een daling op aangezien de schepen vanaf dat moment de brug en sluis zullen verkiezen omdat
de gemiddelde reistijd via de vaarweg een stuk hoger ligt. De tweede keer blijft het aantal
constant aangezien de schepen even snel de vaarweg verlaten als dat er nieuwe schepen
bijkomen (horizontale stuk na ongeveer 61500+).
Rap99 - Testverslag simulatie-framework
1 februari 2001
Aantal Schepen
CM
CO
CO
CO
CO
CO
CO
_ - o in o -. _ —
O T - c o ^ j - c o r ^ c n o
Rap99 - Testverslag simulatie-framework
1 februari 2001
m o m
10
LEXICON
Basisjaar
Het basisjaar betreft de verzameling invoergegevens en uitvoergegevens van het jaar waarop
het uiteindelijke binnenvaart model gecalibreerd is (voor het huidige BVMS is dit 1992).
Bedieningstijd
Periode van de dag dat een sluis of brug voor de scheepvaart geopend kan worden
Beladingsgraad
Gemiddelde belading in ton van een verzameling schepen over een gegeven tijdsperiode als
percentage van de theoretische capaciteit
BICS
Informatiesysteem voor schippers waarmee ze gegevens naar IVS kunnen sturen
Bruine vloot
Vloot van commercieel geëxploiteerde Hollandse platbodems voor het groepsvervoer van
personen
Calibratie:
Het bepalen van de afwijking ten opzichte van een standaard (lees: het basisjaar) met als doel correctie
factoren (lees: de juiste waarden voor de modelparameters) te bepalen.
Capaciteit
De maximale hoeveelheid werkaanbod die een schakel onder gegeven omstandigheden
maximaal kan verwerken, uitgedrukt in aantal normaalschepen.
Case
De totale verzameling van invoer (projectbasisjaar, scenario en variant) en uitvoer behorende
bij één run van BVMS
CRB
Centrale Registratie Binnenvaartschepen, een bestand met vlootgegevens.
Dagtype
Dag in de week waarvoor in BVMS specifieke invoergegevens gebruikt. Dit heeft met name
betrekking op openstellingsregimes van sluiscomplexen en voorbelasting (recreatievaart,
bruine vaart). De volgende dagtypen worden gebruikt:
1 = werkdagen (ma-vr);
2 = zaterdagen;
3 = zon- en feestdagen;
DZO-reizen
Doorvoer Zonder Overlading, reizen van het buitenland naar het buitenland waarbij onderweg
Nederlandse vaarwegen gepasseerd worden
FORWARD
Door RAND / EAC ontwikkeld model dat op een vrij hoog aggregatieniveau inzicht geeft in
regionale economische en milieu effecten van goederenvervoerbeleid.
Goederengroep
Een verzameling goederen met gelijksoortige kenmerken. In het BVMS zal gebruik worden
gemaakt van 27 goederengroepen, een aggregatie van de 52 NSTR-2 groepen.
H-B matrix
Herkomst-bestemmingsmatrix, een kruistabel waarin gegevens per vervoersrelatie op
verkeersgebiedniveau zijn opgeslagen
I/C verhouding
Intensiteit / Capaciteitsverhouding, in feite de bezettingsgraad van een sluis
IVR
INDRIS
Europees project dat zich richt op het ontwikkelen van navigatie en planningssystemen voor
de binnenvaart.
Inputvariabelen
Inputvariabelen zijn de variabelen waarvan de rekenmodules gebruik maken om de waarde
van outputvariabelen te bepalen. Binnen een variant kunnen twee typen inputvariabelen
worden onderscheiden:
oorspronkelijke variabelen; variabelen waarvan de waarde rechtstreeks terug te vinden is in
de basisvariant
gewijzigde variabelen; variabelen waarvan de waarde die specifiek voor de variant gewijzigd
zijn.
Intensiteit
Aantal schepen die een sluis in een gegeven tijdsinterval verwerkt
IVS '90
Registratiesysteem voor schepen. Op een groot aantal plaatsen worden de scheepsbewegingen
(schip, richting, herkomst, bestemming lading, etc.) geregistreerd. Voornamelijk gericht op
verbeteren beheer ten behoeve veiligheid (waar bevinden zich schepen met gevaarlijk
stoffen). De regionale directies van RWS zijn nu eigenaar van dit systeem.
Knoop(punt)
Punt waar schakels (brug, sluis, stuk vaarweg) op elkaar aansluiten, bedoeld om de
geografische positie van een schakel (begin- en eindpunt) weer te geven.
Kolk
Deel van een sluis waar één of meer schepen in één slag geschut kunnen worden; een
sluiscomplex bestaat uit één of meer parallelle kolken. Kolken binnen een sluiscomplex
hoeven niet identiek te zijn qua afmetingen en verwerkingstijden.
Kunstwerk
Stuk infrastructuur (anders dan vaarweg) die de doorlooptijd langs en capaciteit van een
vaarweg beïnvloedt (sluis, brug)
Laad-losplaats
Plaats, bijvoorbeeld haven, waar schip wordt geladen of gelost. In het BVMS heeft iedere
zone één geaggregeerde BVMS-laad/losplaats.
Manoeuvreertijd
Tijd die nodig is om een sluis in- of uit te varen, afhankelijk van de sluis maar onafhankelijk
van scheepstype en -klasse. Volgens de SIVAK-definitie valt dit ofwel onder de wachttijd
(als het schip niet overligt), ofwel onder de overligtijd
Nivelleertijd
Tijd benodigd om de waterstand in een sluis te nivelleren, afhankelijk van de sluis maar
onafhankelijk van het aantal en type/klasse van de schepen die in een sluis aanwezig zijn.
Volgens de SIVAK-definitie maakt dit deel uit van de schuttijd (schuttijd = 2xOpen/dichttijd
+ nivelleertijd).
Open/dichttijd
Tijd benodigd om de sluisdeuren te openen of te sluiten, afhankelijk van de sluis maar
onafhankelijk van het aantal en type/klasse van de schepen die in een sluis aanwezig zijn.
Volgens de SIVAK-definitie maakt dit deel uit van de schuttijd (schuttijd = 2xOpen/dichttijd
+ nivelleertijd).
Outputvariabelen
Outputvariabelen zijn de variabelen die het resultaat van het rekenmodel bevatten.
Overligger (bron: SIVAK)
Een schip dat bij een sluis in de wachtrij ligt, de eerstvolgende schutting niet mee kan gaan en
moet wachten op een volgende schutting.
Overligtijd (bron: SIVAK)
De overligtijd van een schip bij een sluis gaat in op het moment dat het schip in de wachtrij
ligt en er een kolk, waar het schip in zou mogen, omgaat naar de andere kant. De overligtijd
stopt op het moment dat de schuttijd ingaat.
Partijgrootte
De hoeveelheid lading die in één schip wordt geladen (meestal weergegeven in tonnen)
Passeertijd (bron: SIVAK)
De vertraging die een schip bij een sluis oploopt ten opzichte van de situatie waarin de sluis er
niet zou zijn. Deze tijd is gelijk aan de som van de wachttijd, overligtijd en de schuttijd.
POINT
Model om milieueffecten van het goederenvervoer te bepalen.
Prognosejaar
Het jaar waarop een case/variant, niet zijnde de referentiecase/variant betrekking heeft.
Project
Het project betreft een groepering van in- en uitvoer gebaseerd op een bepaalde beleidsvraag.
Dit is de combinatie van één projectbasisjaar met een verzameling bijbehorende scenario's en
varianten.
Projectbasisjaar
Het basisjaar dat voor een project gebruikt zal worden. In veel gevallen zal dit
projectbasisjaar gelijk zijn aan het gewone basisjaar, maar het is mogelijk dat er bijvoorbeeld
een andere zone-indeling wordt gehanteerd. Door gebruik te maken van een project-basisjaar
worden structuurwijzigingen toegelaten zonder dat de kern van de database (het basisjaar)
wordt gewijzigd.
Regio
Een geografisch gebied dat gebruikt wordt binnen TEM. Deze geografische indeling is grover
dan de indeling die voor BVMS noodzakelijk is. Daarom wordt in BVMS een zone-indeling
gehanteerd, die een verfijning is van de TEM-regio's (d.w.z. elke TEM-regio bestaat uit één
of meer BVMS-zones).
Reis
Vaart van een schip vanaf een laadplaats naar een losplaats langs een eenduidig
gespecificeerde route, vertrekkend op een gegeven tijdstip
Retourlading
Ladingaanbod dat op een plaats van lossing beschikbaar komt en naar de plaats van
oorspronkelijke lading (van het schip) moet worden gebracht
Scenario
Een scenario betreft een vertaling van de exogene variabelen van het basisjaar op grond van
mogelijke exogene ontwikkelingen (bijvoorbeeld op basis van de verwachte economische
groei).
Schakel
Een brug, sluiscomplex of stuk vaarweg.
Scheepstype
Indicator voor type schip: motorvrachtschip, motortankschip, duwbakken (nietgemotoriseerde vaartuigen) en containerschepen. Het scheepstype geeft niet de omvang van
een schip weer, dat wordt beschreven door de scheepsklasse.
Scheepsklasse
Indicator die de omvang van een schip aangeeft. De scheepsklasse wordt weergegeven door
een combinatie van lengteklasse en breedteklasse, die per scheepstype (containerschip,
motorvrachtschip, etc.) kan verschillen. Per scheepstype zijn er ongeveer 15 scheepsklassen.
Schuttijd
Alle schepen liggen in de schutruimte en de (invaar-)deuren gaan dicht. De schuttijd stopt op
het moment dat het schip met zijn hek de uitvaardeuren passeert.
Seizoen
Periode in het jaar waarvoor BVMS aparte berekeningen kan maken m.b.t. goederenstromen,
vaardiepte, stroomsnelheden en voorbelasting (recreatievaart, bruine vaart). De volgende
seizoensindeling wordt gehanteerd:
1 = met recreatievaart
2= zonder recreatievaart
Sluiscomplex
Kunstwerk voor het schutten van schepen, bestaande uit één of meer parallelle, mogelijk nietidentieke kolken.
SMILE
Strategisch goederenvervoer model, genereert ook verwachte goederenstromen, maar
beschrijft ook de wijze waarop transport plaatsvindt. Eigenaar: AVV.
TEM
Transport Economisch Model. Is ontwikkeld door NEA en wordt beheerd door AVV. Geeft
prognose over de verwachte goederenstromen in Nederland op basis van economische
ontwikkelingen. Eigenaar: AVV.
Vaarweg
Een geografisch gedefinieerd kanaal of rivier, zoals bijvoorbeeld het Amsterdam-Rijn kanaal.
Een vaarweg is een reeks aaneengeschakelde vaarwegvakken die samen een geografische
eenheid vormen.
Vaarwegvak
Een deel van een vaarweg dat over unieke eigenschappen beschikt (bepaalde diepte, breedte
etc.) of dat begrenst wordt door een kunstwerk (brug, sluis).
Variant
Een planvariant of kortweg een variant betreft een aanpassing van de endogene variabelen
van het basisjaar als reactie op mogelijke exogene ontwikkelingen (zoals vastgelegd in een
scenario).
Vertrektijd
Tijdstip waarop een schip de laadplaats verlaat (d.w.z. nadat alle laadhandelingen zijn
verricht).
Vervolglading
Nieuw ladingaanbod dat op een plaats van lossing beschikbaar komt.
View
Een representatie van de waarde van een deel van de variabelen. Bijvoorbeeld: alle
invoervariabelen, alle 'vloot-variabelen', alle invoervariabelen die gebruikt worden in de
toedelingsmodule of alle uitvoervariabelen. De gebruiker krijgt geen mogelijkheid eigen
views' te definiëren. Tijdens de ontwerpfases worden aantal en inhoud van de views
vastgesteld.
VIN en NWB-v
Overzicht van alle wegen (NWB). Overzicht van alle vaarwegen (NWB-v) en de belangrijkste
kenmerken, en laad-, los- en ligplaatsen wordt via ViN gepresenteerd. ViN maakt gebruik van
MapObjects. Eigenaar: AVV, afdeling Basisgegevens.
Voir
Voir is een spin-off van FVS'90: een grafische presentatie van IVS data om analyses te
kunnen uitvoeren. Eigenaar wordt de afdeling Basisgegevens.
Voorbelasting
Niet direct door het model bepaalde intensiteit op vaarwegen, bijvoorbeeld door de bruine
vaart en door recreatievaart
1
Een uitzondering hierop zijn de rapporten die in de uitvoermodule gegenereerd worden
Zendinggrootte
De hoeveelheid lading die een verlader tegelijkertijd wil verschepen, eventueel te verdelen
over meerdere partijen (zie partijgrootte)
Zone
Een geografisch gebied dat gebruikt wordt als aggregatie van nabijgelegen laad/losplaatsen.
Binnen elke zone is één BVMS laad-losplaats aangewezen. Alle goederenstromen lopen
vanaf en naar deze BVMS laad-losplaats. BVMS zal tussen de 200 en 250 zones omvatten,
inclusief de buitenlandse zones (ongeveer 10 stuks). Een BVMS zone is daarmee een
verfijning van de regio-indeling uit TEM.
Naam
Opleiding:
Vorige werkgevers:
Huidige functie: specialisatie
Huidige functie: enkele karakteristieke projecten
Huidige functie: inspiratie & voorbeelden
Hobbies/vrije tijd
Laatst gekochte boek, cd, geziene film en/of geproefde wijn
Persoonlijk motto
Plaats hier zo
mogelijk je
digitale pasfoto
BEN IK WAT VERGETEN??????
Inhoud Welkomboek
Welkomstwoordje door afdelingshoofd (wie we zijn, wat we willen zijn) (1 pag)
De doelen van de afdeling L&T voor 2001 (1 pag)
De afdeling (iedereen in 1 a4tje: zie boven) (1 pag per medewerker)
Telefoonnumers van de Inro afdelingen (4 pag)
Wat moet ik op korte termijn weten:
• Hoe werkt SAB? (1 pag)
• Hoe werkt het planningssysteem? (1 pag)
• Hoe werkt het secretariaat? (1 pag)
• Bij wie moetje zijn voor vragen over: (1 pag)
kantoormeubilair
rsi
cursussen & trainingen
pc 's/pc privé
99?
V

De route van de 2 Midwinterhoorn Kuiertocht 2014

BRONNEN BREUK - Mijn Mooi Brabant

Fietsroute KW Groene Loper sept 2014

Traktatiepunten 36ste Goirlese

Brochure ENG - BVA Nautic

Bos menroute westenschouwen

Korte handleiding routegenerator

Brochure (ENG)

Definitieve startlijst NK long distance 2014 ()

Maat/Stuurman/Bootsman gezocht Tall Ship Minerva