DTGS Een ontwerp voor een dynamisch reisbegeleidingssysteem

DTGS

Een ontwerp voor een dynamisch reisbegeleidingssysteem

Afstudeerverslag Student :Erdal Ylldlz, 0515820 Datum :14-10-2000

Verslag, oktober 2000

Voorwoord Het laatste onderdeel van de Hogere Informatica Opleiding (HIO) aan de Hogeschool Rotterdam en Omstreken (HRO) is het maken van een afstudeeropdracht. Mijn opdracht houdt een onderzoek in naar de mogelijkheden voor een persoonlijk reisbegeleidingssysteem (RBS) dat met behulp van een mobiel toestel de reiziger kan informeren en het ontwerpen van dit systeem. Ik heb deze opdracht uitgevoerd voor Kennis Gestuurde Systemen (KGS) bij de Informatica opleiding aan de Technische Universiteit Delft (TU Delft). De nodige informatie is verzameld uit rapporten, boeken en het Internet. Hierbij gaat mijn dank uit naar mijn begeleiders Robert van Vark en Leon Rothkranz van TU Delft, en Joop van Amen en Peter Den Brok van HRO. Ik ben hun dankbaar voor hun nuttige bijdragen gedurende het gehele project en voor hun begrip voor de persoonlijke problemen die ik in de afgelopen periode heb meegemaakt. Verder wil ik mijn familie, vrienden en kennissen voor hun steun en hulp bedanken. Erdal Ylldlz


Samenvatting Voor het openbaar vervoer zijn er tegenwoordig een aantal reisplanners, deze leveren een reisadvies wat statisch is, met andere woorden het reisadvies verandert niet mee met de vertragingen, storingen en dergelijke die optreden tijdens de reis. De Personal Intelligent Travel Assistant (PITA) is een project dat erop gericht is om persoonlijke reisbegeleiding tijdens de reis te leveren aan de reiziger met behulp van een mobiel toestel, bijvoorbeeld een WAP telefoon. Het reisbegeleidingssysteem is het gedeelte wat de reisbegeleiding en reisbewaking voor zijn rekening neemt in het PITA project. Er is al een prototype reisbegeleidingssysteem (RBS). In dit verslag wordt een nieuw ontwerp beschreven voor een dynamisch reisbegeleidingssyteem, Dynamic Travel Guidance System (DTGS). Het DTGS probeert tegemoet te komen aan de beperkingen van het RBS en de huidige openbaar vervoer en de hiervoor bestemde reisplanners. Het DTGS probeert met gebruikmaking van een statisch reisplanner een dynamische reisbegeleiding te verzorgen tijdens de reis.


Inhoud 1. Inleiding ___________________________________________________________________________ 6 1.1 Probleemstelling _________________________________________________________________ 7 1.2 Opdrachtomschrijving _____________________________________________________________ 7 1.3 Achtergrond informatie ____________________________________________________________ 8 2. Huidige prototype RBS ______________________________________________________________ 10 2.1 Beschrijving RBS________________________________________________________________ 10 2.2 Sterke en zwakke punten van het RBS _______________________________________________ 13 3. Onderzoek ________________________________________________________________________ 15 3.1 Openbaar Vervoer Reisinformatie ___________________________________________________ 15 3.2 Nederlandse spoorwegen __________________________________________________________ 15 3.3 Mogelijkheden met een mobiel telefoon ______________________________________________ 17 3.4 Communicatie __________________________________________________________________ 17 3.5 Organisatorische problemen _______________________________________________________ 17 4. Eisen en wensen____________________________________________________________________ 19 4.1 Eisen _________________________________________________________________________ 19 4.2 Wensen________________________________________________________________________ 20 5. Ontwerp __________________________________________________________________________ 21 5.1 Aannames______________________________________________________________________ 21 5.2 Het gehele ontwerp van buiten bekeken ______________________________________________ 21 5.3 Groepen _______________________________________________________________________ 26 5.4 Persoonlijke voorkeuren __________________________________________________________ 27 5.5 Route bewaren in het systeem ______________________________________________________ 28 6. Implementatie _____________________________________________________________________ 29 7. Conclusies en aanbevelingen __________________________________________________________ 30 7.1 Conclusies _____________________________________________________________________ 30 7.2 Aanbevelingen __________________________________________________________________ 31 8. Literatuur _________________________________________________________________________ 32 8.1 Boeken en rapporten _____________________________________________________________ 32 8.2 Internet adressen ________________________________________________________________ 32 9. Lijst van afkortingen ________________________________________________________________ 33 Bijlagen I II III IV

: : : :

Voorbeeld reisaanvraag via de NS website Werking en demonstratie van de nieuwe OVR website Een voorbeeld van hoe het RBS systeem werkt Communicatie tussen verschillende programma's in DTGS


V VI

: Beschrijving objecten in het DTGS programma : De gegevens in het DTGS programmma


1. Inleiding In dit verslag wordt het eerste prototype van het reisbegeleidingssyteem (RBS) beschreven. Verder worden de onderzoeks- en ontwerpfase van het nieuwe reisbegeleidingssysteem Dynamic Traveler Guidance System (DTGS) in kaart gebracht. De opzet van deze opdracht is niet het ontwerpen van een routeplanner, maar het reisadvies dat geleverd wordt door een routeplanner te bewaken en zonodig aan te passen én gedurende de reis aanwijzingen te geven aan de gebruiker zodat deze geen omkijken heeft naar de verdere details van de reis. Routeplanners en dienstregelingen vormen natuurlijk wel een belangrijke bron van informatie voor het goed functioneren van het totale reisbegeleidingssyteem.

6/61


1.1 Probleemstelling Binnen de groep Kennis Gestuurde Systemen loopt een project gericht op Naadloos Openbaar Vervoer. Het doel van het project is om de reiziger vooraf en tijdens de reis van relevante reisinformatie te voorzien zoals vertrektijden, aankomsttijden, vertragingen en optimale reisschema's. Een onderdeel van het project is het ontwikkelen van een reisbegeleidingssysteem voor specifieke doelgroepen van reizigers zoals ouderen en gehandicapten. Het idee is dat deze reizigers bij het begin van de reis hun reisdoel bekendmaken en het systeem neemt dan de begeleiding van de reis over. Dit kunnen multimodale reizen zijn. Een multimodale reis is een reis waarin verschillende vervoermiddelen gebruikt worden, bijvoorbeeld gebruikmaken van trein, bus, metro en tram in één reis. De reiziger wordt onderweg geïnformeerd over eventuele vertragingen, overstapmogelijkheden en reisalternatieven. Er is al een eerste prototype van een gesimuleerd reisbegeleidingssysteem voor alleen treinreizen beschikbaar. De informatie die geleverd wordt door deze prototype is mondjesmaat en niet adequaat voor het individu. Veel van deze informatie wordt op de informatieborden op de stations ook verstrekt. Maar de bedoeling is om deze informatie aan de reiziger onderweg te verstrekken. De informatieoverdracht kan plaatsvinden via GSM (SMS-berichten) of het Wireless Application Protocol (WAP). De nu beschikbare prototype reisbegeleidingssysteem heeft nog een behoorlijk aantal beperkingen: -er kunnen slechts een beperkt aantal stations gekozen worden. En er is slechts een zeer beperkt deel van de OVR-reisplanner beschikbaar in het systeem. -verder zijn er geen mogelijkheden om scenario’s voor simulaties te gebruiken -de visualisatie van het gesimuleerde systeem is nu beperkt, geen uitgebreide graphical user interface (GUI) -er zijn geen gesimuleerde berichten voor op een GSM of WAP telefoon 1.2 Opdrachtomschrijving De feitelijke opdracht is een nieuw prototype te ontwerpen dat aan de bovengenoemde bezwaren/beperkingen tegemoet komt. Het ontwerpen van een simulator voor een geautomatiseerd reisbegeleidingssysteem (RBS). Het huidige prototype werkt onder Windows NT. Het systeem kan tevens zoveel mogelijk besturingssysteem(platform) onafhankelijk gemaakt worden. In eerste instantie was het de bedoeling om een werkend systeem op te zetten. Daarom was er gekozen om het systeem alleen voor treinreizen met gebruikmaking van de reisadviezen van de NS-website te ontwerpen en te implementeren. Dit zou minder ingewikkeld zijn dan het systeem te implementeren voor multimodale reizen. In de beginperiode van het onderzoek was de NS-website veel nuttiger voor dit systeem. Echter in september, na het verschijnen van de nieuwe website van OVR, blijkt deze ook meer geschikt voor het systeem. Er is in het gemaakte ontwerp ook nauwelijks een onderscheid tussen de NS en het OVR reisplanner, daarom kunnen deze verschillende reisplanners ook als een reisplanner gezien worden.

7/61


1.3 Achtergrond informatie TRAIL is het nationale kennisinstituut op het gebied van Transport, Infrastructuur en Logistiek met drie kernactiviteiten: Het verzorgen van opleidingen, het doen van toponderzoek en het realiseren van kennisoverdracht en –uitwisseling. In dit kennisinstituut werken de Technische Universiteit Delft en de Erasmus Universiteit Rotterdam samen aan fundamenteel en toegepast wetenschappelijk onderzoek. Momenteel zijn in TRAIL ruim 200 onderzoekers, van wie 100 promovendi, actief. Een van de programma’s van TRAIL is Seamless Multimodal Mobilty(SMM, in het Nederlands: naadloze multimodale ketens). Naadloze multimodale ketens in het personenvervoer op regionale schaal is het antwoord op groeiende restricties in het gebruik van de auto voor persoonlijke doeleinden. Het onderzoeksprogramma zal ‘tools’ creëren voor het ontwerp en de uitvoering van ongekende vormen van aantrekkelijke en efficiënte ketendiensten in reizigersvervoer in gemengde multimodale netwerken. Het uiteindelijke doel is om in samenwerking met reizigers, tussenpersonen, transporteurs, industrie en publieke autoriteiten een dergelijk complex multimodaal transportsysteem te ontwikkelen. Dit kan worden bereikt in nauwe samenwerking tussen een aantal disciplines zoals systeemconstructie, transportplanning, infrastructuur en bouwkunde, wiskunde, informatica en telecommunicatie. SMM projecten zijn onderverdeeld in zes clusters, een van deze clusters is de cluster Traveler Guidance. In het cluster Traveler Guidance loopt het Personal Intelligent Travel Assistant project (PITA). Het PITA project probeert dialoog management technieken te ontwikkelen voor de volgende generatie automatische informatie voorzieningen. Dialoog management technieken zijn tecnieken die gebruikt worden voor automatische spraakherkenning en –synthese. Dit onderzoek wordt gedaan door de Alparon onderzoeksgroep bij de afdeling kennisgestuurde systemen. Essentieel in het bereiken van het doel zijn codeerschema’s voor multimodale dialogen en metrieken voor het meten van verschillende aspecten van voortdurende dialogen. Door gebruik te maken van deze codeerschema’s kan een flexibele en adaptieve dialoog manager ontwikkeld worden. In het begin van het PITA-project werd gedacht dat er een PITA-toestel zou worden ontwikkeld (hieronder een plaatje). Van het idee om een PITA-toestel te ontwikkelen is afgestapt, omdat in de laatste jaren het gebruik van de mobiele telefoons erg toegenomen is.

8/61


Het RBS systeem moet het reisbegeleidende/reisbewakende onderdeel van de PITA gaan worden, want bij het uiteindelijk in gebruik nemen van het systeem zal er met behulp van de dialoogmanager, gecommuniceerd worden met de gebruiker en eventueel met andere partijen. Het systeem moet meerdere reizen van meerdere personen bewaken.

9/61


2. Huidige prototype RBS 2.1 Beschrijving RBS Het RBS prototype wat nu bestaat is opgebouwd uit een aantal programma’s die op een gedistribueerde wijze de reisbegeleiding kunnen verzorgen. Er is in het huidige systeem ook een gedeelte dat de reisplanning op een simplistische manier voor zijn rekening neemt. Als je een reis als een ketting voorstelt, dan zijn de schakels alle verbindingen waar je over reist. En een station is de verbinding tussen twee schakels. Het systeem is gebaseerd op agents die een persoonlijke reisbegeleider per reiziger moeten voor stellen. Als er een wijziging optreedt welke invloed heeft op de reis, wordt er direct opnieuw een optimale route bepaald naar de eindbestemming en dit wordt dan gemeld aan de reiziger. De agent geeft de reiziger tijdens zijn reis dus aanwijzingen over vertrektijden/aankomsttijden, overstapgegevens en wijzigingen in de reis. Hieronder staat een voorbeeld van hoe een reiziger(rode stip) wordt begeleid door de agent(groene stip)die vooruit reist en veranderingen in de route in de gaten houdt. Normaal gesproken zou in de plaatjes hieronder de reis van A naar B in een rechte lijn verlopen omdat dit veel korter is dan de andere mogelijkheden.

Hoe ziet het eruit?

Wat gebeurt er? Reis is nog niet begonnen, reiziger en agent zijn nog op dezelfde plaats.

Reis begint, agent gaat een station vooruit, begint uit te kijken naar veranderingen die de reis kunnen beïnvloeden

Reiziger zit in de trein Agent kijkt uit

10/61


Agent heeft gemerkt dat er verderop in de route een probleem is, en heeft gelijk een nieuwe route bepaald en dit doorgegeven aan de reiziger. Enkele minuten voordat de reiziger aankomt bij het tussenstation krijgt hij nog een melding van de agent hoe hij moet overstappen. Reiziger stapt in de trein, en de agent gaat op dat moment naar de volgende schakel.

Reiziger zit in de trein. Agent kijkt uit.

Enkele minuten voordat de reiziger aankomt bij het tussenstation krijgt hij nog een melding van de agent hoe hij moet overstappen

Reiziger stapt in de trein, en de agent gaat op dat moment naar de volgende schakel. Om daar uit te kijken naar veranderingen.

Enkele minuten voordat de reiziger aankomt bij het eindstation krijgt hij nog een melding van de agent dat hij zo zijn bestemming heeft bereikt.

Het prototype bestaat uit drie programma’s: • RBS, zorgt voor de controle, communicatie,en routes tussen alle verschillende programma’s, hiermee vervult het een server functie, hiervan kan er maar een te gelijk opgestart worden.

11/61


• •

Station, bevat alle informatie van een station(client), hiervan wordt er voor elk station een nieuwe programma opgestart. GSM, wordt gebruikt om het RBS te bellen en een reis in te voeren, laat de voortgang van de reis zien (client), hiervan wordt er ook voor elk gebruiker een nieuwe programma opgestart.

Het RBS programma coördineert de communicatie tussen de afzonderlijke programma’s die het geheel vormen. Definitie van een reis voor dit systeem: De verplaatsing van de gebruiker(en ook de agent) tussen op zijn minst twee stations die zijn aangemeld bij het RBS. De communicatie tussen de programma’s is gebaseerd berichten die verstuurd worden met behulp van winsock en TCP/IP. Hieronder is een minimale opstelling te zien waarin het systeem een reis kan begeleiden. De lijnen 1 en 2 van het RBS naar station B gelden ook voor elk aangemeld station, dus ook voor station A.(om het plaatje niet te ingewikkeld te maken worden de lijnen alleen voor station B getoond) De lijnen 3, 4 en 5 van gelden ook voor elk aangemeld GSM, in dit geval is er maar een GSM aangemeld. 1: maak of verwijder een bestaande agent 2: verplaats agent 3: agent geeft reiziger(GSM-gebruiker) reisinformatie 4: aanmelden/afmelden 5: niet geïmplementeerd, maar zou tracking van reiziger kunnen zijn

12/61


Het prototype maakt gebruikt van de stations hieronder. De verbindingen tussen deze stations zijn rechtlijnig, dus de reizen kunnen alleen over verbindingen van rechte lijnen plaatsvinden. Stations die zijn weergegeven (waartussen dus ook reizen gepland kunnen worden): Amsterdam Alkmaar Arnhem Breda Den Haag Eindhoven Groningen Haarlem Hengelo Kerkrade Leeuwarden Maastricht Rotterdam Utrecht Venlo Vlissingen Zwolle

De werking van het programma is in een demonstratie verwerkt, met alle stappen die genomen moeten worden zie Bijlage III.

2.2 Sterke en zwakke punten van het RBS Sterke punten: 1. Het geheel is gedistribueerd. Dit betekent dat de verschillende programma’s op verschillende computers in een netwerkomgeving kunnen werken. De agent die een reiziger representeert, reist fysiek van het ene naar het andere station. 2. De weergave van de bewegingen van de agent en de reiziger in het GSMprogramma wordt op een duidelijke manier getoond. 3. De dienstregeling kan tijdens de simulatie gewijzigd worden. 4. Het systeem maakt gebruik van een gesimuleerde tijd, welke tijdens de simulatie op elk tijdstip ingesteld kan worden. Hierbij wordt gebruik gemaakt van een tijdversnellingsfactor waardoor de simulaties snel uitgevoerd kunnen worden.

13/61


Zwakke punten: 1. Er is geen overzicht bij de verschillende programma’s. Men kan bijvoorbeeld bij het GSM-programma niet zien hoe de reis zal verlopen. 2. Het wijzigen van treingegevens in de dienstregeling bij het stationprogramma is te langzaam, omdat dit over het netwerk gebeurt. Het RBS moet op de hoogte gesteld worden van de wijziging, dat vervolgens alle andere stations op de hoogte stelt. 3. Er is in het systeem geen manier om een simulatie uit te voeren waarin een bepaald scenario wordt afgespeeld. Men moet alle gegevens handmatig invoeren. Met als gevolg dat er meestal te weinig tijd is om een “goede wijziging” in te voeren om zodoende de kracht van het systeem te tonen. Om honderd reizen tegelijkertijd uit te voeren, moeten er ook daadwerkelijk honderd personen een reis invoeren. 4. De statistiek optie in het menu van het RBS-programma is niet voldoende. Hier zijn geen interessante gegevens te zien. 5. Elk programma in het systeem brengt ook een bepaalde netwerkbelasting met zich mee, omdat elk programma op vaste intervallen controleert of er iets gewijzigd is (IP-polling). 6. Voor elk station moet een programma opgestart worden. Elk programma neemt een gedeelte van het beschikbare geheugen van de computer in beslag. Dit heeft als gevolg dat het systeem traag wordt als de simulatie maar op één of twee computers uitgevoerd wordt. 7. Er is geen logfile aanwezig, zodat alle beslissingen gemaakt door het systeem tijdens een simulatie achteraf bekeken kunnen worden. 8. De gebruiker kan bij het GSM-programma alleen gegevens invoeren in een tekstvakje, en kan uitsluitend iets zeggen als het gevraagd wordt. Met andere woorden: er vindt geen interactie met de gebruiker plaats.

14/61


3. Onderzoek 3.1 Openbaar Vervoer Reisinformatie Openbaar Vervoer Reisinformatie v.o.f. (OVR) is een samenwerkingsverband van NSReizigers, Verenigd Streekvervoer Nederland en de Vereniging van Stedelijke Vervoerbedrijven. Het bedrijf verzorgt de reisinformatievoorziening van en voor het totale openbaar vervoer in Nederland. OVR is in 1991 opgericht en in mei 1992 begonnen met het verstrekken van openbaar vervoerreisinformatie via één telefoonnummer: 0900-9292. Via dit nummer worden jaarlijks meer dan tien miljoen gesprekken afgehandeld. Het overgrote deel daarvan betreft reisadviezen van adres naar adres met alle vormen van openbaar vervoer. Daarnaast geven de ruim 400 medewerkers van 0900-9292 ook informatie over tarieven en bijvoorbeeld de beschikbaarheid van Treintaxi of fietsenstalling. Het belangrijkste hulpmiddel bij het verstrekken van de informatie is de OV Reisplanner, een geavanceerd computerprogramma, waarin onder andere 10.000.000 passeertijden, 210.000 straten, 65.000 halten en zo’n 20.000 bijzondere punten (musea, ziekenhuizen etc) zijn opgenomen. Het aantal bellers naar 0900-9292 stijgt nog steeds. Daardoor neemt de bereikbaarheid af en nemen de wachttijden toe. Om zoveel mogelijk klanten te woord te kunnen staan maakt OVR bij oplopende wachttijden gebruik van de sprekende computer. Tijdens het schrijven van dit verslag is er een nieuwe website van OVR op Internet gekomen. Op deze website is gratis reisadvies te verkrijgen en is het ook mogelijk om met een WAP-toestel een reis te plannen. Zie voor meer informatie over deze nieuwe website Bijlage II.

3.2 Nederlandse spoorwegen Op de NS-website is er reisplanning mogelijk. Deze reisplanner verstrekt uitsluitend reisadviezen van NS-station naar NS-station. Om een idee te krijgen van hoe een reisadvies wordt verkregen van de NS-website, zie voorbeeld reis opvragen op de NS-website in Bijlage I. Het nadeel van deze wijze van reisplanning voor een reisbegeleidingssysteem is dat het gaat om een statisch reisadvies, welke niet naar aanleiding van actuele informatie aangepast wordt. Bijvoorbeeld: “U moet om 11:42 van spoor 9 op Rotterdam CS de intercity richting Den Haag HS hebben”. Maar als de reiziger net te laat op het station is, dan klopt de hele route niet meer. Het enige wat hij op dat moment kan doen is kijken wanneer de volgende trein vertrekt. Het RBS kan via het Internet de reisinformatie opvragen en doorgeven aan de gebruiker. De route wordt bewaakt en als er tijdens de reis ergens een vertraging of

15/61


uitval van een trein plaatsvindt, wordt er direct naar een alternatief gezocht. Deze informatie wordt dan tijdig aan de reiziger gemeld. Als men een “via”-optie gebruikt moet men geografische kennis hebben over de ligging van alle transportmogelijkheden in de omgeving van de storing. Nu kan er een selectie gemaakt worden van de meest gunstige locaties en de daarbij behorende meest gunstige aansluitingen naar het volgende punt in de reis. Bij het gebruik van de “via”- optie gaat men in principe ervan uit dat de reiziger in de tussenplaats wil aankomen en daar een bepaalde tijd wil blijven. Deze verblijftijd kan men dus voor het omzeilen van een storing op nul zetten, want men wil eigenlijk helemaal niet bij de “via”- plaats zijn maar de reis weer voortzetten. Zo kan men dus tijdverlies opdoen doordat men bijvoorbeeld een stoptrein moet nemen om in de “via”- plaats uit te kunnen stappen, terwijl een intercity direct naar het volgende punt van de reis gaat. Met deze gegevens kan men er voor zorgen dat veranderingen vermeden worden door in de buurt van de plaats waar de verandering optreedt te kijken welke plaatsen een alternatief vormen voor deze plaats. Er worden nieuwe routes bepaald met deze alternatieven als tussenpunten, en de gebruiker kan een keuze maken uit de gevonden alternatieven. Voor de werking van een statische routeplanner zijn deze gegevens voldoende. Bij een dynamische routeplanner (realtime) zal het zo zijn dat de actuele dienstregeling gebruikt zal worden en alle wijzigingen al verwerkt zijn in het reisadvies. In hoeverre de huidige routeplanners deze optie om “probleemplaatsen” (dat wil zeggen: plaatsen waar opstoppingen en/of vertragingen optreden) te vermijden is niet bekend. Als men aanneemt dat de NS–website de actuele gegevens gebruikt is het probleem makkelijk opgelost. Bij het optreden van een storing vraagt het systeem opnieuw de route aan vanaf de huidige locatie naar de eindbestemming en volgt men het nieuwe reisadvies. Echter voor een dynamische persoonlijke begeleiding van de route zijn deze gegevens in principe voldoende. Het vermijden van uitval van een station of trein met behulp van de “via” optie is wel mogelijk maar er zijn twee problemen : om te kunnen bepalen wat de dichtstbijzijnde alternatieve plaatsen zijn, is er geografische kennis nodig over de ligging van alle stations voor treinen (maar ook voor alle andere vormen van transport). het gebruiken van de “via” optie garandeert niet de snelste route, het biedt slechts een oplossing voor het vermijden van een vertraging

16/61


3.3 Mogelijkheden met een mobiel telefoon Er kunnen met een mobiele telefoon op een aantal manieren met de gebruiker gecommuniceerd worden: - Spraak, spraakherkenning en spraaksynthese(Alparon) - Tekst, er kan met een mobiele telefoon tekst verstuurd worden (SMS, Short Message Service) - WAP(Wireless Application Protocol), dit is een relatief nieuw protocol en stelt mobiele telefoons onder andere in staat om te kunnen internetten. 3.4 Communicatie Aanwijzingen zijn in principe communicatie één kant op namelijk van systeem naar gebruiker. Passieve communicatie: Voor het bepalen van de locatie van de gebruiker moet er een trackingssysteem gebruikt worden dat bijvoorbeeld met behulp van sensoren het systeem laat weten waar de gebruiker zich bevindt. De gebruiker hoeft hier dus zelf niets voor te doen. Dit gebeurt automatisch. Aanwijzingen plus wijzigingen van gebruiker: Hier is sprake van interactie tussen de gebruiker en het systeem. De gebruiker krijgt tijdens de reis aanwijzingen en keuzes die gemaakt moeten worden, worden aan hem voorgelegd. De gebruiker kan ook nog eens zelf besluiten om de reisparameters te veranderen tijdens de reis( bijvoorbeeld: Reis annuleren en eindbestemming veranderen). Dit is uiteindelijk in het systeem gewenst maar voorlopig gaan we ervan uit dat een reis dat eenmaal gepland is ook uitgevoerd zal worden en wijzigingen tijdens de reis niet plaatsvinden. Als de gebruiker toch besluit om tijdens de reis een andere reis te maken kan dan hij de geplande reis annuleren en een nieuwe reis pl 3.5 Organisatorische problemen Het maken van het systeem zal niet erg moeilijk zijn. De grootste problemen zullen van organisatorische aard zijn omdat er veel partijen zijn die openbaar vervoer bieden en de daarbij horende gegevens beschikbaar moeten stellen. Deze verschillende partijen moeten hun databases/dienstregelingen op een universele manier georganiseerd hebben, zodat een route planner met al deze gegevens overweg kan. De diensten geleverd door het systeem zullen een bepaalde kostprijs met zich meebrengen, hierop kan bijvoorbeeld een abonnement afgesloten worden. Deze abonnement kan op dezelfde manier als de mobiele telefoon(GSM) abonnementen zijn. Men kan vooruit of achteraf betalen wat kosten waren of men betaalt een bepaald bedrag vooruit. Bij het vooruitbetalen moet erop gelet worden dat het systeem niet mag ophouden met werken, omdat niet zeker is hoeveel er voor de reiziger gedaan moet worden kan er dus moeilijk om vooraf te bepalen wat de

17/61


kosten zijn. Achteraf betalen levert kan in principe makkelijk omdat kosten zijn de dienst al is geleverd zijn de kosten ook bepaald. De dienst zou ook opgenomen kunnen worden in de WAP-abonnement of de provider levert het als een dienst. Wat ook kan is, de regering zorgt ervoor dat het gratis wordt aangeboden om de openbaar vervoer te bevorderen Reiskosten: Normaal gesproken heeft een reis vaste prijs, deze prijs is dus in de meeste gevallen wel goed, maar als het systeem de reis verandert, verandert in principe de prijs ook. Deze prijs is dus onbepaald, omdat in het systeem ervan uit wordt gegaan dat er allemaal dingen kunnen gebeuren waardoor de reis een ander verloop heeft, en dus een andere prijs. In zo'n situatie is het ook wenselijk om betalingen via het systeem te laten verlopen, maar dit brengt natuurlijk weer hele andere problemen met zich mee zoals (authenticatie, of er genoeg saldo is, etc.) Een oplossing hiervoor zou kunnen zijn dat je een soort van strippenkaart idee met zone-indelingen van gebied kan gebruiken om binnen een bepaald gebied voor een vast bedrag te kunnen reizen. Voor mensen met een OV-jaarkaart (onder andere studenten) levert het systeem geen prijsverschillen op, omdat deze mensen toch een vast bedrag per jaar betalen.

18/61


4. Eisen en wensen Om verwarring te voorkomen met het eerste prototype is er een nieuwe naam gekozen voor het project. Deze naam is Dynamic Traveler Guidance System of DTGS in het kort. De eisen en wensen zijn opgesteld aan de hand van de opdrachtomschrijving en sterke en zwakke punten van het RBS. 4.1 Eisen De eisen waaraan het DTGS moet voldoen, kunnen worden onderverdeeld in functionele en technische eisen. De eerste zeven punten vormen de functionele eisen. De punten acht en negen zijn de technische voorwaarden. 1. De gegevens in het systeem dienen overzichtelijk getoond te worden. De vragen waarop het systeem een antwoord moet kunnen geven zijn: • Welke reizen vinden er nu plaats? • Welke reizen staan in de wachtrij? • Wat zijn de acties die genomen moeten worden? • Wat zijn de gegevens van een agent? • Een overzicht van aankomende en vertrekkende treinen op een station • Hoe ziet de hele reis eruit? • Wat is de status? (verbinding, bezig, wacht op input, etc. in de vorm van icoontjes) 2. De communicatie tussen alle partijen in het systeem moet volgens een protocol van specifieke berichten lopen, zodat ook alleen met de berichten een simulatie uitgevoerd kan worden. 3. Het systeem moet actuele reisinformatie van de NS-website/database op kunnen vragen, en deze gegevens kunnen verwerken. Er hoort een vertaalschil, een parser, tussen de NS-website/database en het systeem te komen, zodat reisadviezen opgevraagd kunnen worden. Dit is de interface van het systeem naar de dienstregeling. Deze interface dient gemakkelijk aangepast te kunnen worden voor andere bronnen. 4. Omdat het om een simulatie gaat, moet een duidelijk zichtbare tijdsaanduiding aanwezig zijn in elk programma van het systeem. 5. Om een simulatie telkens te kunnen herhalen is het nodig dat er scenario’s gebruikt kunnen worden. Dit hoeft niet speciaal een programma of een gedeelte van een programma te zijn. Dit kunnen ook “scripts” zijn, waarin veel reizen en wijzigingen tegelijkertijd ingevoerd kunnen worden. 6. Het DTGS moet gebruik maken van de voorkeurgegevens van de gebruikers. 7. Het DTGS behoort verschillende onafhankelijke gebruikers met overeenkomende taken te groeperen, zodat pieken en dalen op bepaalde lijnen zichtbaar worden (bijvoorbeeld de spits). 8. De handelingen verricht door het DTGS dienen in een logbestand vastgelegd te worden. Dit in verband met “debuggen” tijdens de bouw en om de resultaten van

19/61


een simulatie vast te leggen. Een logbestand is alleen bij DTGS nodig, aangezien dit het controlesysteem is. 9. De programma’s dienen opgestart te kunnen worden met een configuratiebestand in plaats van de configuratie hard in de code te programmeren of het programma handmatig te moeten instellen.

4.2 Wensen Voor een betere toepassing en gebruiksvriendelijkheid van het DTGS zijn de onderstaande punten wenselijk: 1. De interactie met de gebruiker zou meer moeten toelaten voor de gebruiker, oftewel zou flexibeler moeten zijn. 2. Het gebruiken van kleuren en vormen zoals in verkeerslichten, om bepaalde zaken aan te geven. Zodat vertragingen, beschikbaarheid en dergelijke direct opvallen. 3. De activiteit van het systeem zou zichtbaar kunnen gemaakt worden met behulp van een grafiek of getallen. 4. De agents, reizigers,stations en storingen kunnen grafisch getoond worden. 5. Het systeem zou automatisch de locatie van de reiziger kunnen bepalen.

20/61


5. Ontwerp 5.1 Aannames De reisgegevens worden van de NS-website opgehaald, dus het systeem hoeft zelf geen reisplanning te doen maar vooral reisbewaking. De gegevens zullen in het uiteindelijke systeem op een directere manier van bijvoorbeeld een database gehaald moeten worden. In werkelijkheid is er een punt waar alle wijzigingen binnen komen, en van dit punt in de dienstregeling verwerkt wordt. Er komen in het ontwerp dus alleen de wijzigingen binnen, en hierop kan gereageerd worden door een nieuwe reis te plannen. 5.2 Het gehele ontwerp van buiten bekeken

Zoals in bovenstaand plaatje te zien is bestaat het nieuwe ontwerp uit vier verschillende programma's. • GSM moet het telefoontoestel van de gebruiker voorstellen. • OVR stelt de NS website voor, maar in een werkelijk systeem zal dit een database van de Nederlandse Spoorwegen of van Openbaar Vervoer Reisinformatie moeten zijn. • Change stelt de wijzigingen voor, dus alle treinvertragingen enzovoorts waarop het systeem moet kunnen reageren. • DTGS is het hart van het geheel. Hier wordt alle communicatie tussen de verschillende programma’s geregeld, de reisinformatie bewaakt en reisbegeleiding verzorgd voor de reiziger.

21/61


De verschillende programma’s kunnen met elkaar communiceren door berichten naar elkaar te sturen. Hier zijn alle berichten die tussen alle programma’s verstuurd kunnen worden in een matrix weergegeven. Waar een X staat betekent dat er tussen die twee programma’s geen communicatie plaats vindt. Van Þ Naar GSM

DTGS

OVR CHANGE

GSM X

GeefRouteInformatie GeefAanwijzingen GeefKeuze GeefStatus X X

DTGS ReisPlannen ReisAnnuleren Kies VraagStatus X GeefRoute GeefVerandering

OVR

CHANGE

X

X

VraagRoute VraagRoute met omzeilen van een storing X X (toekomst NSOVR?)

X

X X

Voor hoe de berichten worden opgebouwd, zie bijlage IV.

22/61


5.2 Het DTGS programma van binnen De programma’s GSM, CHANGE en OVR communiceren met het DTGS programma. De objecten agent, route en change corresponderen met de programma’s buiten het DTGS programma.

# 1 2 3 4 5 6 7 8

9

10 11 12 13 14

wat wordt er gedaan De gebruiker brengt een verbinding met het RBS systeem in tot stand en er wordt bepaalt wat de reis moet zijn. Reisaanvraag Reis opvragen bij OVR Reisinformatie terug van OVR Route of routekeuzes Route informatie Informatie voor de begeleiding Veranderingen Keuzes Er komt een verandering binnen Komt dit veranderde reisdetail voor in de geplande reizen? Wijzigingen binnen een periode Geplande reizen waarin verandering voorkomt Vraag welke wijzigingen binnen een bepaalde periode plaatsvinden , dit is nodig bij het bepalen van nieuwe reis, om te kijken of oude wijzigingen invloed hebben. Bij een dynamische reisplanner is dit niet nodig. Kijk of deze verandering de geplande reis beïnvloedt? (en neem acties) Agent heeft bepaald wat de acties zijn, en voert deze acties in de actielijst Timer geeft alle acties uit de actielijst die "Nu" uitgevoerd moeten worden Actie geeft acties die uitgevoerd moeten worden door de Agents Timer geeft aan de Agents door dat het tijd is voor ActieId

23/61


5.3 Beschrijving van de objecten in het DTGS programma Hieronder volgt uitleg waarvoor de verschillende objecten in het DTGS programma dienen. Agent: De agent representeert de gebruiker in het DTGS. De gebruiker brengt een verbinding met het DTGS tot stand. Op dat moment wordt er een nieuwe agent aangemaakt die vanaf dat punt alle communicatie van en naar de gebruiker voor zijn rekening neemt. Tevens zal die met de andere onderdelen van het systeem kunnen communiceren om de reis goed te kunnen plannen en tot een goed einde te kunnen brengen. Als een gebruiker een reis wil plannen stuurt het GSM-programma van de gebruiker een bericht naar een agent in het DTGS programma(Server). De eerste keer dat een bericht wordt ontvangen van een GSM programma wordt een nieuwe agent aangemaakt. Deze blijft bestaan totdat de gebruiker zijn eindbestemming heeft bereikt of de gebruiker de reis annuleert. De agent controleert deze reisaanvraag en stuurt vervolgens een bericht naar het routeobject. Als de route bepaalt is krijgt de desbetreffende agent een bericht terug met de reisinformatie. Het ontvangen bericht wordt gepresenteerd aan de gebruiker door een bericht met de reisgegevens te sturen naar het GSM-programma van de gebruiker. De communicatie zoals hierboven beschreven wordt herhaald totdat de gebruiker de geplande reis accepteert. Als de reisgegevens gepresenteerd aan de gebruiker correct zijn, wordt de reisinformatie gesplitst in acties die op bepaalde tijden ondernomen moeten worden. Deze opgesplitste acties worden in een actielijst bewaard voor alle agents. De acties in de actielijst worden op chronologische volgorde ingevoerd. Doordat de acties van alle agenten in dezelfde lijst worden opgeslagen, kunnen er acties zijn die meerdere keren voorkomen. Als een actie in de lijst ingevoerd moet worden, en deze actie bestaat al, dan wordt er op dat moment een groep gemaakt van agents die hetzelfde moet ondernemen. Er is in het DTGS een timer, die de tijd aangeeft, en elke minuut kijkt in de actielijst of er iets gedaan moet worden. En als het nodig is de agent die wat moet doen een bericht stuurt met de actieId. Het is tijd geworden voor actie want de agent heeft een bericht ontvangen van de timer met een actieId. De agent haalt de actie op en verwijdert deze actie uit de actielijst. Als er een verandering binnen komt van change, wordt er bepaald wat de invloed is op de reis. Dit kunnen drie verschillende dingen zijn. Ten eerste is er een vertraging, maar de vertraging heeft geen invloed op de rest van de reis (er is genoeg overstaptijd bij volgende schakel in reis). In het tweede geval is er een vertraging en de reis wordt nadelig beïnvloed. Bijvoorbeeld een trein heeft een vertraging van vijf minuten waardoor de aansluiting wordt gemist, maar de rest van de reis kan op normale wijze worden vervolgd omdat er bij de volgende schakel meer dan voldoende overstaptijd is. Tot slot is er een verandering en de rest van de geplande reis kan in zijn geheel niet meer vervolgd worden. Er moet een nieuwe route bepaald worden. De verandering wordt altijd doorgegeven aan de gebruiker als ook de consequenties ervan voor de reis. Route: De route krijgt een reisaanvraag van de agent. Vervolgens vraagt de route de reisinformatie op bij OVR en wacht op een antwoord van OVR. Als de reisadvies bepaald kan worden stuurt het een bericht met de reisinformatie naar de agent. Als het een reisadvies is die niet bepaald kan worden stuurt het de agent een bericht om

24/61


de reisaanvraag opnieuw te formuleren. Er wordt een routelijst bijgehouden van reisaanvragen van agents met de daarbij behorende reisinformatie. Als er een verandering van change komt, wordt er in deze lijst gekeken of de verandering voorkomt in de lijst. Het resultaat wordt vervolgens verstuurd naar change met bijbehorende agentId’s. Change: Change is het oor van het systeem dat luistert naar veranderingen. Deze veranderingen kunnen zijn: - vertragingen; een trein heeft een vertraging opgelopen - wijzigingen; een trein rijdt een andere route dan normaal - verwijdering; een trein rijdt helemaal niet meer Als een verandering binnenkomt, vraagt change bij de route of er reizen gepland waren waarop de verandering invloed heeft. Route geeft een antwoord aan change, met of zonder reisdetail. Als in de geplande reizen de verandering geen invloed heeft, houdt change op en wacht op nieuwe veranderingen. Als er een reis bestaat waarvoor de verandering consequenties heeft, stuurt route het reisdetail dat overeenkomt én de bijbehorende agentId. Change stuurt dan de verandering en het reisdetail zoals dat normaal gesproken zou zijn door naar de agent, die op zijn beurt de gebruiker op de hoogte stelt en verdere acties onderneemt. Actions: De actielijst is eigenlijk een soort van prikbord waarop alle agenten hun te ondernemen acties kunnen bewaren. Doordat alle agenten de actielijst gebruiken, kunnen acties ook gedeeld worden zodat agenten met dezelfde acties een groep vormen. Dit zal voor een klein aantal reizigers niet veel schelen in performance. In een werkelijk werkend systeem echter zal bijvoorbeeld tijdens de spits de lijst vele malen korter zijn, omdat er dan veel mensen zijn met dezelfde vertrekplaats en/of dezelfde bestemming. Dit betekent niet dat twee agenten precies dezelfde reis moeten "bewaken" om in dezelfde groep van agents te zitten. De actielijst is een gelinkte lijst van acties die door agenten moeten worden ondernomen op bepaalde tijden. Elementen in de lijst worden alleen aangevuld en verwijderd door agenten. Doordat het een gelinkte lijst is, is het mogelijk de elementen in een chronologische volgorde in te voeren. Bij het invoeren van nieuwe acties worden deze al op de juiste plaats in de lijst ingevoegd.Hierdoor wordt voorkomen dat de lijst niet gesorteerd moet worden of dat er in de lijst gezocht moet worden. Bij het uitvoeren van de acties hoeft er alleen maar bovenin de lijst gekeken te worden. Timer: De timer is de klok van het hele systeem die er voor zorgt dat de acties die uitgevoerd moeten worden ook daadwerkelijk op de juiste tijdstip worden uitgevoerd. De timer heeft een gesimuleerde tijd, dit betekent dat men de tijd voor elk tijdstip kan instellen. De timer heeft ook om de simulaties niet te lang te laten duren een ingebouwde tijdversnellingsfactor waardoor de tijd sneller gaat in het systeem dan in werkelijkheid. De tijdversnellingsfactor is een geheel getal. Bijvoorbeeld als de tijdversnellingsfactor 60 is dan gaan er 60 gesimuleerde seconden per werkelijke seconde voorbij. Met andere woorden één simulatieminuut per werkelijke seconde. In verband met acties die elk minuut uitgevoerd kunnen worden, is het in eerste instantie niet handig om een tijdversnellingsfactor van meer dan 60 te gebruiken. De tijdversnellingsfactor moet in ieder geval kleiner zijn dan het minimum aantal minuten waarschuwingstijd. De waarschuwingstijd is de tijd

25/61


waarop een bericht verstuurd moet worden naar de gebruiker. Een voorbeeld: "Over 5 minuten stapt u uit deze trein." Als de tijdversnellingsfactor 600 (10 minuten) zou zijn, zou het bericht kunnen zijn: "Vijf minuten geleden had u moeten uitstappen" Voor de object modellen van de objecten hiervoor beschreven, zie Bijlage V. 5.3 Groepen Groepen worden dynamisch gevormd en opgeheven aan de hand van de Agent ID die bij een route en/of bij een actie staan: Hier is een voorbeeld te zien van twee reizen, namelijk A-B-C en A-B-D. Het eerste A-B gedeelte is voor allebei de reizen hetzelfde, hier wordt dus een groep gevormd, omdat de gegevens voor dat gedeelte precies hetzelfde zijn voor beide reizen.

Voorbeeld van een geplande route voor Agent A1 en Agent A2 die de zelfde route hebben, op het moment dat Agent A2 RouteQuery vraagt, ziet het OVR object dat het zelfde route al een keer gevraagd was en geeft het resultaat door aan de gebruiker en laat Agent A2 aansluiten bij A1. Een groep is gevormd. AgentId

ROUTE

RouteKeuze

A1,A2 (eventueel meer)

(“10:00”, ”Rotterdam CS”, “Amsterdam CS”)

Station

Tijd

Spoor

Soort

Rotterdam Centraal

V 09:45

8

Sneltrein 2224

Schiedam Centrum Delft Den Haag HS

A 9.50

Leiden Centraal HeemstedeAerdenhout Haarlem Amsterdam Sloterdijk Amsterdam Centraal

Richting/ Eindbestemming Den Haag HS/ Amsterdam Centraal

A 9.57 A 10.05 A 10.16 A 10.30 A 10.36 A 10.47 A 10:52

26/61


Voorbeeld van een geplande actie voor Agent A1 en Agent A2 die dezelfde actie hebben, op het moment dat Agent A2 een actie toevoegt dat al bestaat voor een andere Agent wordt Agent A2 aangesloten bij deze Agent. AgentId

Tijd voor actie

Actie, bericht dat verstuurd moet worden

A1,A2 (eventueel meer)

9:40 (tijd die bepaald wordt aan de hand van voorkeur voorwaarschuwingstijd)

Station

Tijd

Spoor

Soort

Rotterdam Centraal

V 09:45

8

Sneltrein 2224

Richting/ Eindbestemming Den Haag HS/ Amsterdam Centraal

Het eerste actie zal door de Agent vertaald worden naar een bericht en verstuurd worden naar de gebruiker. Bericht wordt zoiets als: “Over vijf minuten moet u de sneltrein van spoor 8 in Rotterdam Centraal station richting Den Haag/Amsterdam Centraal nemen” Zoals in de tabel hierboven te zien is, wordt voor elke voorkeur waarschuwingstijd een nieuwe actie voor elke (te vormen groep aangemaakt). Aangezien in eerste instantie de voorkeurtijden alleen 5,10 of 15 (of iets dergelijks, in ieder geval niet veel waarden) minuten zullen zijn maakt dit voor de grootte van de actietabel niet zoveel uit. In plaats van deze methods hieronder, bij route en Actie een method showGroups(), die zoekt naar alle routes of acties die voor meer dan een agent zijn. Groepsgegevens worden dus niet bij de agenten bewaard maar de in route tabel en actie tabel (kolom AgentId) NotifyGroup(), eigenlijk zelfde als NotifyAgent() met als enige verschil dat het bericht naar een lijst van Agents gaat in plaats van naar een Agent Elke agent bepaald zijn eigen te ondernemen acties zelf en merkt er verder niets van of het al een keer berekend is. Het enige wat er wordt gedaan is bij actie en route, als het al bestaat, dat het maar één keer opgeslagen. 5.4 Persoonlijke voorkeuren Iedereen krijgt een standaardprofiel, dit voorkeurprofiel wordt automatisch aangepast aan de hand van de keuzes gemaakt door de gebruiker. Bijvoorbeeld: als de gebruiker een route kiest uit een aantal reizen waarin duidelijk meer overstappen zijn, wordt er in zijn profiel de voorkeur overstappen een zwaardere gewicht toegekend. De voorkeuren kunnen natuurlijk ook door de gebruiker zelf veranderd worden, dit is echter alleen voor de gevorderde gebruikers. Met behulp van de voorkeuren kan het systeem bij keuzes die door de gebruiker gemaakt moeten worden al een schatting maken naar de meest waarschijnlijke keuze en deze als eerste optie tonen. Telkens als niet de eerste optie is gekozen zal

27/61


er een reëvaluatie van de voorkeuren plaatsvinden, zodat de voorkeuren up-to-date blijven. Deze voorkeuren moeten natuurlijk ook door de gebruiker zelf aan te passen zijn en er moet ook nog een optie in de voorkeuren komen zodat de gebruiker de automatische update van de voorkeuren kan uitschakelen(gevorderde gebruiker)(TRUE/FALSE) De gegevens die in de voorkeuren bewaard moeten worden zijn: - overstaptijden, bijvoorbeeld minimaal vijf minuten - voorwaarschuwingstijd, bijvoorbeeld vijf minuten, deze mag niet te groot zijn - aantal overstappen, bijvoorbeeld ‘zo min mogelijk’ of ‘maakt niet uit’ - begintijd, dit is een cijfer van 0 tot 10 - eindtijd, dit is een cijfer van 0 tot 10 - totale reisduur, dit is een cijfer van 0 tot 10 - lopen, dit is een cijfer van 0 tot 10 - prijs, dit is een cijfer van 0 tot 10 5.5 Route bewaren in het systeem De wijze waarop reisgegevens bewaard worden is zo algemeen mogelijk gehouden. Hieronder is een voorbeeld van een reis van beginpunt A naar eindpunt H. Er is tijdens deze reis een overstap bij punt D. Deze reis is dus opgebouwd uit twee segmenten A-D en D-H. Bij punt D wordt overgestapt om de reis te kunnen vervolgen. Elk segment is op zijn beurt weer opgebouwd uit een aantal stops. Dit zijn de verschillende opeenvolgende schakels in een segment. Men kan hierbij denken aan een stoptrein of een metro. De reiziger stapt pas in dit voorbeeld uit bij punt D en punt H. Het segment A-D is opgebouwd uit de stops B, C en D. Deze stops zijn voor de reiziger niet van belang. Ze worden pas belangrijk bij wijzigingen in de geplande reis, omdat deze stops ook als overstapplaatsen kunnen dienen in de nieuwe alternatieve reis.

voor een overzicht van de gegevens die in het systeem bewaard moeten worden, zie Bijlage VI

28/61


6. Implementatie Ik was begonnen met de implementatie maar kon hier helaas niet mee verder. Er was ook nog niet veel bereikt wat het noemen waard is. Ik heb voor implementatie de programmeertaal Java gekozen om de volgende redenen: - platform onafhankelijk, hoeft dus maar een keer te programmeren voor alle platformen (Unix/Linux/Win98/WinNT) - mogelijkheid om applets te maken die met behulp van een browser uit te voeren zijn, zo kan je via internet de applicaties uitvoeren - objectgeoriënteerd, door gebruik te maken van objecten kan er op een makkelijke manier een model gemaakt worden - hergebruik van code is makkelijk - java is een redelijk goed gestructureerde programmeertaal - veel mogelijkheden, veel basisobjecten kunnen gebruikt worden Een ander belangrijk reden waarom ik voor Java koos is dat er voor de dialoogmanager van de Alparon groep al het een en ander in Java was geprogrammeerd. Waar het DTGS gebruik van kon maken, en om het DTGS te kunnen integreren in het Alparon project. In het ontwerp is ook dan zoveel mogelijk rekening gehouden met de mogelijkheden en beperkingen van Java.

29/61


7. Conclusies en aanbevelingen 7.1 Conclusies Bij het kijken naar verschillende routeplanners is er gebleken dat er tegenwoordig uitsluitend statische routeplanners beschikbaar zijn. Dit houdt in dat de door deze routeplanners geleverde reisadviezen vast zijn en er geen rekening wordt gehouden met actuele dienstregelingen. Om persoonlijk actueel reisbegeleiding tijdens de reis te kunnen verstrekken aan de reiziger met gebruikmaking van een mobiel toestel dient de routeplanner dynamische reisadviezen te leveren. In het Dynamic Traveler Guidance System (DTGS) wordt er een dynamisch routeplanner nagebootst door in een statisch routeplanner de “via”-optie te gebruiken. Door het toepassen van persoonlijke voorkeuren kan dit ontwerp geschikt gemaakt worden voor elk specifieke doelgroep, alsook elk individu. Er is geprobeerd in het ontwerp dat gemaakt is zoveel mogelijk te voldoen aan de functionele eisen. Aan de technische eisen en de wensen kon niet voldaan worden omdat deze pas bij de implementatie aan de orde komen en ik helaas zelf door omstandigheden geen werkend prototype heb kunnen implementeren. De grootste problemen bij het tot stand brengen van dit systeem zullen van organisatorische aard zijn. Dit komt omdat er veel partijen zijn die vervoer bieden en de daarbij behorende gegevens beschikbaar moeten stellen. De verschillende partijen die openbaar vervoer leveren moeten afspraken maken over de wijze waarop ze hun informatie organiseren en hun activiteiten op elkaar afstemmen, zodat één route planner met al deze gegevens overweg kan. Tevens moeten deze partijen afspraken maken over de verdeling van de kosten en baten die dit systeem met zich brengt.

30/61


7.2 Aanbevelingen In het ontwerp is nog niet gedacht aan beveiligingsaspecten van het DTGS. De beveiliging van het systeem is belangrijk voor privacy redenen,in het geval van persoonlijke informatie dat in het systeem bewaard zou kunnen worden “gewoontes” die afgeleid kunnen worden voor personen. Deze gegevens zouden voor een demografish model kunnen dienen voor bepaalde onderzoeken of nieuwe vormen van reclame. Tevens is de beveiliging belangrijk voor financiële redenen, om bijvoorbeeld te voorkomen dat er gereisd wordt op kosten van iemand anders. Voor beveiliging kangedacht worden aan: - Pincode/wachtwoord - Encryptie van de communicatie - Secure connections Het DTGS zou goed van pas komen voor mensen met een drukke agenda, als er een koppeling tussen de agenda(Outlook misschien) en het DTGS gebruikt zou worden om de reizen automatisch van de persoon vooruit te kunnen plannen. Het DTGS kan hiermee gelijk ook een oplossing voor handelsreizigersprobleem zijn, in dit probleem moet een vertegenwoordiger langs een aantal plaatsen reizen en dit zo efficiënt mogelijk doen. Hiervoor is nodig dat er meerdere reizen per persoon tegelijk kunnen bewaakt worden invoeren, dus bijv: “ik wil nu van Rotterdam naar Amsterdam en dan na een uur naar Groningen van Amsterdam” of “ik ben nu in Rotterdam en ik wil vandaag één uur lang in Amsterdam zijn en één uur lang in Groningen zijn en de volgorde is niet belangrijk” Het gebruiken van scenario’s is belangrijk voor een simulator, hierbij moet nog nagedacht worden over wat voor scenario’s gebruikt gaan worden. Er moet bepaald worden welke testgegevens gebruikt zullen worden. Er zijn tegenwoordig veel nieuwe technologische ontwikkelingen op het gebied van mobiele communicatie(spraak en data), hier kan bijvoorbeeld gedacht worden aan UMTS (Universal Mobile Telecomunications System). Een ander trend is de ontwikkeling van handheld computers met goede grafische en datacommunicatie mogelijkheden, een voorbeeld van de handheld computers is de Yopy (http://www.yopy.com). OVR levert tegenwoordig reisadviezen op met WAP, er kan geprobeerd worden om zoveel mogelijk samen te werken. En zoveel mogelijk de reisplanner van OVR op een directe manier te gebruiken.

31/61


8. Literatuur 8.1 Boeken en rapporten Kroon R., Van Waveren J.M.P., Reisbegeleidingssysteem documentatie, 1999 Van Vark R.J., Module Library Source Documentation, Alparon report 97-13, 1997 Van Vark R.J., Dialogue Manager Framework & Test Environment Source Documetation, Alparon report 97-14, 1997 8.2 Internet adressen PITA gerelateerd: Openbaar Vervoer Reisinformatie, http://www.ovr.nl Nederlandse Spoorwegen, http://www.ns.nl Reis informatie op NS, http://www.ns.nl/reisinfo Openbaar vervoer, http://www.9292ov.nl/reiswijzer TRAIL, The Netherlands Research School for Transport, Infrastructure and Logistics, http://www.TRAIL.tudelft.nl SMM, Seamless Multimodal Mobility, http://cttrailf.ct.tudelft.nl/smm/ Alparon project, http://www.kbs.twi.tudelft.nl/Projects/Alparon/ School gerelateerd: Technical University Delft, http://www.tudelft.nl Faculty of Information Technology and Systems at Technical University Delft, http://www.twi.tudelft.nl Department Knowledge Based Systems, http://www.kbs.twi.tudelft.nl Hogeschool Rotterdam & Omstreken, http://www.hro.nl Computer science on Hogeschool Rotterdam & Omstreken, http://www.cs.hro.nl Java: http://java.sun.com

32/61


9. Lijst van afkortingen In dit verslag worden een aantal afkortingen gebruikt. Hieronder staat een lijst weergegeven met de betekenis van de verschillende afkortingen. DTGS GPS GUI HTML KBS KGS NS OVR PITA RBS SMM SMS TCP/IP TRAIL WAP URL

Dynamic Traveler Guidance System Global Positioning System Graphical User Interface Hypertext Markup Language Knowledge Based Systems(KGS in het Engels) Kennis Gestuurde Systemen(KBS in het Nederlands) Nederlandse Spoorwegen Openbaar Vervoer Reisinformatie Personal Intelligent Travel Assistant Reisbegeleidingssysteem Seamless Multimodal Mobility Short Message Service Transmission Control Protocol/Internet Protocol Transport, Infrastructuur en Logistiek Wireless Application Protocol Uniform Resource Locator

33/61

Bijlagen , oktober 2000 Bijlagen: Bijlage I: Voorbeeld reisaanvraag via de NS website _______________________ 35 Bijlage II: Werking en demonstratie van de nieuwe OVR website _____________ 39 Bijlage III: Een voorbeeld van hoe het RBS systeem werkt __________________ 48 Bijlage IV: Communicatie tussen verschillende programma’s in DTGS __________ 55 Bijlage V: Beschrijving objecten in het DTGS programma: ___________________ 59 Bijlage VI: De gegevens in het DTGS programma__________________________ 61

34/61

Bijlagen , oktober 2000

Bijlage I: Voorbeeld reisaanvraag via de NS website Als je op de homepage van NS-reisinformatie (http://www.ns.nl/reisinfo) komt, zie je het volgende scherm.

Vanaf hier laat ik alleen het reisplanning gedeelte zien, je kiest een vertrek plaats en een bestemming, en een tijd om te vertrekken.

35/61

Bijlagen , oktober 2000 De reisplanner kan niet (altijd) direct onderscheiden wat de vertrekplaats en de bestemming zijn, daarom komt er een nieuwe pagina, waar uit lijsten kan gekozen worden van stations die lijken op de eerst ingevoerde waarden.

Je kiest uit de lijsten de juiste plaatsen drukt op “ OK”

36/61

Bijlagen , oktober 2000 Je krijgt nu de beste gevonden routes en tijden te zien, met het beste alternatief extra geaccentueerd:

Verder op dezelfde pagina staan de dezelfde routes en tijden in meer detail beschreven(hier zijn de eerste drie van zes routes weergegeven):

37/61

Bijlagen , oktober 2000 de uiteindelijke gekozen route:

en hier de gekozen route in meer detail, je ziet hier bij welke tussenstations de trein langskomt:

38/61

Bijlagen , oktober 2000 Bijlage II: Werking en demonstratie van de nieuwe OVR website Adres naar adres reisadvies via WAP 9292 breidt haar WAP-service uit Openbaar vervoer-reisinformatie van deur tot deur is per WAP via twee telecom-providers op te vragen: KPN en Telfort. De mobiele service die 9292 Openbaar Vervoer Reisinformatie aanbiedt gaat van adres naar adres in heel Nederland. Hiervoor is het intikken van de postcode van vertrek en aankomstadres voldoende. Een plaatsnaam met een station is ook als invoer mogelijk. Een gedetailleerd en actueel reisadvies met alle vormen van openbaar vervoer (bus, trein, tram, metro en ferry) zijn op deze wijze voor de reiziger onderweg zelf op te vragen. Goedkoop reisadvies De service via Telfort is een uitbereiding van de 9292 ReisWijzer WAP service dat al vanaf november vorig jaar via KPN M-info loopt. Deze WAP-service was in eerste instantie bedoeld voor het zakelijk gebruik, maar door de uitbreiding via Telfort kan de 9292 ReisWijzer WAP nu ook breeduit gebruikt worden door de consument. Bij M-info van KPN Telecom kost het f 2,50 voor een dag onbeperkt gebruik, exclusief mobiele kosten. Bellers via Telfort hoeven niet te betalen voor de informatie die Telfort via haar portal verstrekt. De consument betaalt slechts voor de verbruikte belminuten. Dit kan vanaf f 0,35 per minuut. Hoe werkt het? WAP staat voor Wireless Application Protocol. Oftewel Internetten per mobiele telefoon. Via een menu van een provider kan de beller contact leggen met de ReisWijzer van 9292. Hoe WAP werkt? Heel simpel. Op het vraagscherm toetst de klant de postcode of de stationsnaam van vertrek en aankomstadres in. De ReisWijzer geeft dan twee reisadviezen voor de eerstvolgende mogelijkheden. Een later tijdstip of een latere datum kan ook. Als het reisadvies niet op één scherm past, kan de beller 'scrollen'. Actief informeren In de toekomst wil 9292 ook actief gerichte reisadviezen gaan verstrekken. Bijvoorbeeld aan forensen die een elke dag een vast traject afleggen. Gebruiksaanwijzing WAP Via het M-info menu van KPN, de WAP portal van Telfort en het Whepp menu van Libertel kan deze dienst gestart worden. KPN: start het M-info menu zoals dat door de provider aangegeven wordt. Kies in het mneu achtereenvolgens : Onderweg; Openbaar vervoer; 9292 (OVR)

39/61


Telfort: Vervoer: 9292 OV reisadvies De 9292 ReisWijzer WAP is gemaakt om een OV reisadvies op te vragen voor de eerste reismogelijkheid. Voor vertrek (van) en aankomst (naar) kan een postcode, of minimaal 3 letters van een plaatsnaam met een treinstation worden ingevoerd.

Standaard wordt de huidige datum en tijd genomen voor het maken van een reisadvies. Als de gebruiker deze zelf wilt invoeren kan dat door de keuze “invoer tijd/datum” te gebruiken. Er worden twee reisadviezen gegeven en voor elk worden de vertrektijd, de reisduur en het aantal overstappen gegeven. Meer informatie over het eerste of de tweede reisadvies kan opgevraagd worden door op de betreffende onderstreepte vertrektijd te klikken. Tevens staan onder in het scherm de mogelijkheden om twee eerdere of twee latere reizen op te vragen. Het is eenvoudig om met de standaard Terug toets (rechts) van het WAP toestel terug te gaan naar het vraag scherm zonder dat de reeds ingevoerde gegevens verloren gaan. De WAP reiswijzer geeft van de reis de hiernaast weergegeven details.

40/61

Bijlagen , oktober 2000 Handige tip voor gebruikers van ReisWijzer Internet en WAP Reist u vaak van station naar station? Met onderstaande lijst van station-verkortingen kunt u vanaf nu nog sneller en efficiënter gebruik maken van ReisWijzer Internet. Ook is deze lijst van verkortingen handig voor WAP (Wireless Application Protocol)-gebruikers. van station naar station Vul de afkortingen in 'van' en 'naar' en u krijgt in zeer korte tijd een reisadvies 'van station naar station' op uw scherm. van een station naar een adres Gebruikers van ReisWijzer Internet kunnen ook 'van een station naar een adres' reisadvies opvragen: Vul dan bij 'van' de afkorting van het station in en in 'naar' het volledige adres van bestemming in. En andersom natuurlijk. Demo van de ReisWijzer Internet Hieronder een voorbeeld van een reisadvies dat gegeven wordt via ReisWijzer Internet. Voor deze demonstratie is een fictief adres gebruikt. Stel u heeft een reis gepland van Capelle aan den IJssel naar de Jaarbeurs in Utrecht. U bent van plan om de reis met het Openbaar Vervoer te maken. U kunt vooraf alle informatie over de reis al door via het Internet een reisadvies op te vragen. Naast een handige route planner beschikt u ook over gedetailleerde plattegronden van de vertrek en aankomst omgeving. Ook de tarieven kunt u op vragen. Deze gegevens zijn handig om onderweg mee te nemen. Via de button reisadvies komt u terecht in onderstaand scherm.

U vult de juiste gegevens in en klikt op zoek.

41/61


U krijgt direct de resultaten op het scherm te zien. Deze kunt u uitprinten. U kunt ook aanvullende informatie opvragen.

42/61


43/61


44/61


Ook de tarieven informatie.

45/61


Ook kunt u de een plattegrond van de aankomstplaats (en ook vertrekplaats) opvragen en uitprinten. Er zijn teven in- en uitzoom mogelijkheden zodat het ideale kaartje samengesteld kan worden.

46/61


Wat is ReisWijzer? ReisWijzer is een product van Openbaar Vervoer Reisinformatie B.V. (OVR). OVR biedt reizigers een actueel en geïntegreerd reisadvies van adres naar adres, voor alle vormen van openbaar vervoer in Nederland. Het vraagformulier Geldigheid ReisWijzer is altijd voorzien van actuele dienstregelinggegevens. Aan de bovenzijde van het vraagformulier is de geldigheidsperiode van ReisWijzer aangegeven. Meestal worden de gegevens tien dagen voor het einde van de geldigheid vernieuwd en wijzigt de geldigheidsdatum automatisch. Van - Naar - Datum - Tijd Wanneer u ReisWijzer oproept, verschijnt na het openingsscherm een eenvoudig vraagformulier waarmee u een reisadvies kunt opvragen na het invullen van de volgende gegevens: •

van

•

naar

•

datum

•

tijd

47/61

Bijlagen , oktober 2000 Bijlage III: Een voorbeeld van hoe het RBS systeem werkt RBS programma: Om het systeem te laten werken moet als eerste het RBS programma opgestart worden. Hier krijg je copyrightmelding en een versie nummer te zien:

Na het drukken op “OK” start het RBS programma op, het werkt echter nog niet. Om het programma te late werken moet er in het menu, FileàSetup gekozen worden. En de juiste poorten voor het programma deze poortnummers staan standaard al ingevoerd, maar je kan desnoods andere poorten kiezen.

Na het klikken op “OK” vershijnt er in het venter een bericht winsock begonnen is, en het programma begint met het luisteren naar stations en GSM-users.

48/61

Bijlagen , oktober 2000 In het RBS venster is telkens te zien wat er gebeurt. Als er een station verbinding maakt of verbreekt is dit te zien.

Er kunnen ook statistieken bekeken worden in het programma, door in het menu HelpàStats te kiezen.

Het RBS programma heeft een gesimuleerde tijd en deze kan ingesteld worden door in het menu EditàSet time te kiezen.

49/61

Bijlagen , oktober 2000 Het einde van RBS waarin alle stations de verbinding verbreken en waarin boven in het venster nog het begin gedeelte van een reis te zien is.

Station programma: Het station programma wordt opgestart en ziet er als volgt uit.

In het menu FileàConnect kiezen, Hier kunnen 4 dingen ingevoerd worden: - het station(let op er kan niet een station gekozen worden dat al aangemeld is bij het RBS systeem) - de contact poort van het station ( hoe kan het RBS dit station bereiken?) - IP-adres plus de poort waarop het RBS luistert naar stations (hoe kan het station het RBS bereiken?)

50/61


Nu is het station opgestart en kan een reis naar en van dit station plaatsvinden, hier in dit voorbeeld zie je ook wat voor foutmeldingen je kan krijgen als winsock de verbinding niet kan maken omdat de gegevens niet kloppen. Er is hier ook te zien hoe een reiziger wordt begeleid. Om het gehele systeem goed te laten werken moet elk station aangemeld worden bij het RBS. Want met slechts een station kan je geen reis plannen of begeleiden.

Er kan vanaf elke station een trein in het land vertraagd of verwijderd worden, hier is een voorbeeld van hoe een trein wordt vertraagd. Kies in het menu TrainàDelay Arrival Kies in het menu de station en datum en klik op “OK”.

51/61

Bijlagen , oktober 2000 Nu kan je kiezen welke trein een vertraging krijgt en hoelang de vertraging zal zijn.

GSM Programma Het GSM programma start op en er moeten eerst de gegevens van het RBS ingevoerd worden door in het menu FileàOn te kiezen. Dit komt overeen met het aanzetten van de mobiele telefoon.

Nu moet er contact gemaakt worden met het RBS, door in het menu FileàCall RBS te keizen. Hier moet het IP-adres van RBS ingevoerd worden. Hier moet IP adres van RBS en de poort waarop RBS luister naar GSM applicaties.

52/61

Bijlagen , oktober 2000 De GSM is nu verbonden met het RBS en komt met de vragen: - “Waar wilt u heen?” - “Van waar wilt u reizen?” - “hoe laat wilt u vertrekken?” - bevestigingsvraag: “U wilt van Rotterdam naar Denhaag en om 11:00 vertrekken, is dit correct?” Opmerking: Hierboven staat Denhaag aan elkaar geschreven. Dit is echter geen fout, maar zo wordt in het programma de stad Den Haag genoemd. de antwoorden van de gebruiker kunnen in het balkje onderaan ingevoerd worden en met een klik op de button “Say” of door op “Enter” te drukken op het toetsenbord.

53/61


Bij het begin van de reis zie je op de kaart bij Denhaag een blauwe en een groene stip, de blauwe stip stelt de agent voor en de groene de reiziger. Als de reis begint gaat de Agent naar Rotterdam en wacht daar op de reiziger en houdt alle treinen die van belang zijn voor de reiziger in de gaten (in dit geval is dat niet nodig omdat de reis maar tussen twee stations is). Tijdens de reis kan de reiziger zijn locatie op kaart zien door het groene stipje te volgen. Enkele minuten voor aankomst bij het eindstation geeft de Agent een melding ”Bij het eerst volgende station stapt U uit” Bij het bereiken van de eindstation een afsluitende zin “U heeft het eindstation bereikt, een prettige dag verder”.

54/61

Bijlagen , oktober 2000 Bijlage IV: Communicatie tussen verschillende programma’s in DTGS

GSMà àDTGS ReisPlannen Parameter(s) Pre Post Beschrijving Return

Vertrekplaats, bestemming, datum, tijd, via_plaats Bestaande stations, Datum en tijd Route aanvraag opgestuurd Route aanvragen bij DTGS systeem, en wachten op Route informatie dat via DTGS bij OVR wordt opgevraagd True:gelukt False:niet gelukt

Kies Parameter(s) Pre

Post Beschrijving Return

Kiesopties (twee of meer opties waaruit gekozen moet worden) Er is iets waarvan het systeem niet zelf kan bepalen wat er gekozen moet worden, Bijvoorbeeld welke route uit de verschillende routes bij de route aanvraag Keuze is gemaakt en bekend bij DTGS Route aanvragen bij DTGS systeem, en wachten op Route-informatie dat via DTGS bij OVR wordt opgevraagd True:gelukt False:niet gelukt

VraagStatus Parameter(s) Pre Post Beschrijving Return

GSM_ID GSM is aangesloten op DTGS systeem De status voor de gebruiker wordt getoond Hiermee kan de gebruiker zien wat de status is van zijn reis, Plannen,wachten,bezig enz. True:gelukt False:niet gelukt

ReisAnnuleren Parameter(s) Pre Post Beschrijving Return

RouteId Een route moet voor de GSM gebruiker gepland zijn De geplande route is verwijderd uit het DTGS systeem Een reis annuleren om wat voor reden dan ook. True:gelukt False:niet gelukt

ReisWijzigen Parameter(s) Pre Post Beschrijving

Return

RouteId, Vertrekplaats, bestemming, datum, tijd, via_plaats Route moet bestaan De geplande route voor gebruiker is gewijzigd De route aanvraag is veranderd, effectief is dit hetzelfde als ReisAnnuleren + ReisPlannen, alleen de instellingen gaan mee naar de nieuwe reis True:gelukt False:niet gelukt

55/61


DTGSà àGSM: GeefRouteInformatie Parameter(s) Pre Post Beschrijving Return

Route Route was aangevraagd en GSM gebruiker wacht op een route Route informatie aan gebruiker doorgegeven Geef de route-informatie door aan de gebruiker. True:gelukt False:niet gelukt

GeefKeuze Parameter(s) Pre Post Beschrijving Return

Een aantal mogelijkheden waaruit een keuze gemaakt moet worden. Er zijn een aantal opties waaruit de gebruiker moet keizen. De keuze is aan de gebruiker voorgelegd. Geef de keuze die gemaakt moet worden aan de gebruiker. True:gelukt False:niet gelukt

GeefAanwijzingen Parameter(s) Pre Post Beschrijving Return

Aanwijzing(text) Het is tijd voor een aanwijzing om de reis te begeleiden. De aanwijzing is naar de gebruiker gestuurd. Geef aanwijzingen die nodig zijn om de reis uit voeren. True:gelukt False:niet gelukt

GeefStatus Parameter(s) Pre Post Beschrijving Return

Status, een getal of een code De Status van het systeem is bekend. De status is doorgegeven aan de GSM-programma om te kunnen tonen aan de gebruiker. Geef de status van het systeem door. True:gelukt False:niet gelukt

DTGSà àOVR: VraagRoute Parameter(s) Pre Post Beschrijving Return

Reisaanvraag Er is door een agent een reis aangevraagd. De reisvraag is bij het OVR programma bekend. Een door een agent gevraagde reis is, naar het OVR programma gestuurd. True:gelukt False:niet gelukt

56/61


VraagRoute(omzeilen) Parameter(s) Pre Post Beschrijving Return

Reisaanvraag Er is door een agent een reis aangevraagd. De reisvraag is bij het OVR programma bekend. Een door een agent gevraagde reis is, naar het OVR programma gestuurd. True:gelukt False:niet gelukt

OVRà àDTGS: GeefRoute Parameter(s) Pre Post Beschrijving Return

Route, AgentId Er was een reisaanvraag vanuit DTGS, de reisaanvraag is opgevraagd uit de externe reisplanner, en verwerkt in een route(object). De opgehaalde route is doorgegeven aan DTGS. De reisaanvraag is opgevraagd en het resultaat is verwerkt en doorgegeven aan DTGS. True:gelukt False:niet gelukt

CHANGEà àDTGS: GeefVerandering Parameter(s) Pre Post Beschrijving Return

Change Er is verandering/wijziging opgetreden(ingevoerd), wat invloed kan hebben op de geplande reizen. De wijziging is verwerkt en doorgegeven aan DTGS. Geef de veranderingen die binnen komen door aan DTGS. True:gelukt False:niet gelukt

Bij GSM,OVR, en Change Connect Parameter(s) Pre Post Beschrijving Return

Ip-adres DTGS, DTGS_PORT, LOCAL_PORT Er moet een internet verbinding mogelijk zijn op de computer en de poort die gebruikt gaat worden is beschikbaar Er is een verbinding met het DTGS syteem Een verbinding maken met het DTGS systeem True:gelukt False:niet gelukt

Disconnect Parameter(s) Pre Post Beschrijving Return

Connection(verbinding) Er is een verbinding met het DTGS systeem De verbinding met het DTGS systeem is verbroken Een verbinding verbreken met het DTGS systeem True:gelukt False:niet gelukt

57/61


Disconnect (met een reden) Parameter(s) Pre Post Beschrijving Return

Connection(verbinding), reden voor disconnect Er is een verbinding met het DTGS systeem De verbinding met het DTGS systeem is verbroken Een verbinding verbreken met het DTGS systeem True:gelukt False:niet gelukt

Send Parameter(s) Pre Post Beschrijving Return

Connection, MessageId, Bericht Er is een verbinding, Het bericht is verstuurd naar Een bericht versturen naar het DTGS systeem True:gelukt False:niet gelukt

Receive Parameter(s) Pre Post Beschrijving Return

Connection, MessageId, Bericht Er is een verbinding, En er komt een bericht van DTGS Het bericht is ontvangen en gereed voor behandeling Een verbinding ontvangen van DTGS en gereed maken voor afhandeling, en ervoor zorgen dat het bij het juiste object aankomt. True:gelukt False:niet gelukt

Bij GSM,OVR, en Change Listen(Service) Parameter(s) Pre Post Beschrijving Return

DTGS_PORT, Service Er moet een internet verbinding mogelijk zijn op de computer en de poort die gebruikt gaat worden is beschikbaar Het DTGS systeem luistert op een bepaalde poort naar de Service (GSM,OVR,Change) De Service_Object voor desbetreffende service is gecreëerd en luistert True:gelukt False:niet gelukt

58/61


Bijlage V: Beschrijving objecten in het DTGS programma: Agent: Properties: - IP/telefoon/WAP -nummer van gebruiker - Voorkeursgegevens van gebruiker, zoals minimale waarschuwingstijd - Reisgegevens van gebruiker Methods: - Listen(), de agent doet niets. Wacht op input van gebruiker of andere objecten in het systeem - Say(), stuur een bericht door naar gebruiker - AskRoute(), vraag reisgegevens aan OVR - GetRoute(), haal de routegegevens op van OVR - RouteChanged(), de route is gewijzigd. Vraag een nieuwe route met gewijzigde parameters - UpdateRoute(), maak de route actueel na het ontvangen van een nieuwe route - CreateActionList(), maak een lijst van acties die ingevoerd kunnen worden in de actionList ROUTE: Properties: - IP-nummer/URL van OVR-programma waar de vragen gesteld kunnen worden. - Lijst van routes met bijbehorende agentId’s en gevraagde routeaanvragen. Methods: - Listen() - GetRoute(), haal de reisgegevens op bij het OVR-programma dat op zijn beurt weer van de NS-website (NS-database of routeplanner programma) - GiveRoute(), geef de reisinformatie aan de agent Reisgegevens van gebruiker - UpdateRoute(), route met vertragingen/calamiteiten actualiseren

CHANGE: Properties: - IP-adres/URL van CHANGE - Lijst van wijzigingen Methods: - Listen(), luister of er wijzigingen binnenkomen - GetChange(), krijg de wijzigingen van externe CHANGE bron - CreateAction(), bereken wat de actie zou geweest zijn zonder de wijziging - CompareAction(), vergelijk de actie van voor de wijziging met de actielijst - NotifyAgent(), geef de wijziging

59/61

Bijlagen , oktober 2000 Actions: Properties: - Tijd waarop actie ondernomen moet worden - AgentId, dit kunnen meerdere Id’s zijn in verband met groepsvorming - Actie, hierin staat wat er gedaan moet worden Methods: - Insert(), voeg een actie toe aan de lijst - Update(), verander een actie die in de lijst zit - Delete(), verwijder een actie uit de lijst Timer Properties: - huidige tijd (in de simulatie een gesimuleerde tijd) - tijdsversnellingsfactor Methods: - Time(), geef de huidige tijd van het systeem - SetTime(), verander de tijd van het systyeem - SetAcceleration(), verander de tijdsversnellingsfactor - CheckActions(), kijk welke acties die “Nu” uitgevoerd moeten worden, en geef dit door aan de agents die het in de lijst hebben geplaatst.

60/61

Bijlagen , oktober 2000 Bijlage VI: De gegevens in het DTGS programma

61/61

DTGS Een ontwerp voor een dynamisch reisbegeleidingssysteem

Recommend Documents