Research and Development 1/^Archief/2007-2008/projecten/Automatisering OV betalingsverkeer/Product

Uit Werkplaats
Ga naar: navigatie, zoeken

Naam

P2D


Eisen die wij wel/niet stellen aan ons eigen systeem

De punten waarop wij operationaliseren:

  • Gebruiksgemak - Aantal tevreden gebruikers
  • Gebruiksgemak - De lengte van een betaaltransactie in seconden
  • Gebruiksgemak - Het aantal gebruikers dat het nieuwe systeem gebruikt t.o.v. het oude
  • Veiligheid - Het aantal gebruikers dat zich niet veilig voelt
  • Veiligheid - Het aantal malen dat er misbruik van het systeem gepleegd wordt t.o.v. het aantal malen dat dit probleemloos gaat
  • Veiligheid - Het aantal malen dat privacy van gebruikers wordt geschonden
  • Veiligheid - De mogelijkheid om saldo van gebruikers te stelen met huidige technieken
  • Personeel - Aantal werknemers benodigd om het OV-systeem te laten werken zoals het is bedoeld

Het is natuurlijk aan te bevelen op elk punt de beste score te halen, om aan de eisen voor een goed ov-betaalsysteem te voldoen.


Wel

  • Gemakkelijk in gebruik, dus zo min mogelijk handelingen om een transactie te voltooien.
  • Snel
  • Persoonlijke pas
  • Chip - nog niet eerder gekraakt (bron nodig)
  • Poortjes om het station
  • Anoniem reizen

Niet

  • Contactloos
  • Ruimte voor het ouderwetse kaartjessysteem
  • Poortjes bij busstations

Ideeën?

Een soort van pas blijft een goede oplossing, de gebruiker moet immers een vorm van vervoersbewijs bij zich dragen. Daarbij ook goed want beveiligbaar tegen zwartrijden. Zoals stated in onderzoeksdeel 2, is dit belangrijk. Systeem met mobiel moet ook ff onderzocht worden (dit gebruiken ze in duitsland toch/plannen om te gebruiken), en het britse systeem, wat net als dat van ons is oid, maar dan werkt t wel en ook in de praktijk.

Opbouw systeem

  • Server
  • Een machine om reis te plannen (en dus "een kaartje te halen")
  • Persoonlijke pas
  • Paslezer
  • Database met saldo => dit geeft beveiliging tegen kopieren pas (en dus van het saldo)
  • Draadloze verbinding tussen database en paslezer

Uitwerkingen per onderdeel

  • Pas

Op de pas slaan we op: reizigersinfo, en de geplande reis.

  • Paslezer

Deze leest de gegevens op de pas uit, en kijkt of de eigenaar betaald heeft voor de reis.

  • Pasautomaat

Hierop wordt een reis gepland (trein) De chauffeur geeft aan hoeveel betaald moet worden voor de reis (bus) Deze werkt verder net zoals een chipautomaat. De pasautomaat staat in verbinding met de server, en schrijft het saldo af.

In het geval van de trein staat een pasautomaat buiten de poortjes. De gebruiker voert zijn pas in, selecteert naar welk station hij/zij wil, en drukt op OK. De interface kan dan hetzelfde blijven als de huidige NS automaten. De automaat berekent de kosten van de reis.

In het geval van een bus, of evt metro, voert de chauffeur de reiskosten in, en de gebruiker drukt dan wederom op OK.

De gebruiker blijft eindverantwoordelijk, als deze niet op OK drukt mag hij/zij ook niet reizen, want er is niet betaald. (Verder uitwerken nodig)

  • Server

Hierop staan alle gegevens van de gebruiker, en zijn saldo.

  • Draadloze verbinding

GSM-UMTS netwerk

Anonimiteit

De verschillende opties die we hebben om anoniem te kunnen reizen

  • Prepaid passen die zonder legitimatie te verkrijgen zijn (Eamonnnnnnnn) prepaid
  • Reisinfo alleen gebruiken om kosten te bereken, en niet opslaan (Robbbbbbbb) kosten opslaan
  • Informatie wel opslaan, maar niet direct koppelen aan de gegevens van de gebruiker. Dit maakt nazoeken mogelijk, maar directe informatie zien over de gebruikers niet. (Joooooosstttt) reisinfo opslaan

Wat kan er fout gaan?

  • Geen verbinding met database
  • Geen saldo
  • Geen pas


Powerpoint

[1]