(Indsæt selv en lang saga om DSB her)
Hvor svært kan det egentlig være at lave et rejsekort ?
Kravene er egentlig helt simple:
Datatilsynet og brugere skal acceptere designet.
Kortet må ikke kunne bruges til berigelseskriminalitet.
Det skal kunne være i drift før DSB bliver færdigt med deres kort.
Hvem kommer med det mest kreative bud ?
phk
Man køber en færdig løsning hos et firma der har prøvet det før.
MIFARE-kortene fra NXP Semiconductors er kommet i en plus-udgave, der i modsætning til den gamle "classic" udgave rent faktisk har kryptering på kortet (128 bit AES). Der er tale om kendt teknologi, der bruges i bl.a. London og Singapore - og som dermed også er en hyldevare der kan implementeres lige så hurtigt som det er muligt at sætte automater op.
Men den tilgang er jo desværre ikke normen i den gamle etat...
Et grundkrav til et Rejsekort er at det understøtter Digital Cash, så det ikke bliver ligesom PBS bloreker for at sikre betalingssiden på de nye trådløse betalingsmodeller.
Ingen tvivl om, at rejsekortet er sat alt for ambitiøst op, og at dette er den direkte årsag til, at dette som alle andre store projekter, fejler.
Man skal dog heller ikke tro, at det bare er et simpelt plastikkort, og så derudad.
Til rejsekortets forsvar taler:
• Det er en landsdækkende løsning, hvor takstsystemet alt andet lige vil være mere kompliceret end i et enkelt storbysystem. • Det er ikke bare DSB’s løsning - flere regionale trafikselskaber er med (men faktisk ikke alle endnu). • Kollektiv trafik er ganske reguleret, hvorfor der krav til prisfastsættelse og substitution fx af SU-kort, efterlønskort m.v. • Leverandøren – som først og fremmest er franske Thales - er ganske erfaren på området.
Det, som jeg synes er forkert, kan kort udtrykkes med, at man forsøger at genopfinde den dybe tallerken, ved:
• At designe et nyt takstsystem, som er hidtil uset kompliceret – og formentlig unødvendigt. • At der allerede findes løsninger i regional drift i Danmark – fx på Fyn – som man ikke inddrager erfaringerne og resultaterne fra.
Jeg ville tro, at hvis man tog udgangspunkt i en eksisterende løsning og et kendt takstsystem og så måske tilkøbte noget fikst fransk hardware – så var det blevet langt billigere og hurtigere færdigt.
Det vigtige er at man ikke låser alle de trådløse betalignspunkter omkring en lukket "standard" som ikke kan opgrades og ikke er åben for konkurrence.
Hvem i alverden siger at man kun skal have en type kort? Hvad med mobiltelefonene, kreditkort, sikre betalingskort med digital cash etc.
Som repræsentant for en NFC producent, skal jeg jo næsten foreslå NFC. Tanken med NFC er bla. at kunne bruge en telefon som betalingsmiddel - der bliver for tiden kørt forsøg med teknologien i Londons Undergrund og i San Fransico's Bart.
Om det så kan opfylde Pouls krav vil jeg være op til læseren, men her er et par videoer mm.: http://www.nfc-forum.org/resources/presentations/
Living in a Contactless World: Going Mobile http://www.contactless-intelligence.tv/060a_video.php
"Som repræsentant for en NFC producent, skal jeg jo næsten foreslå NFC. Tanken med NFC er bla. at kunne bruge en telefon som betalingsmiddel - der bliver for tiden kørt forsøg med teknologien i Londons Undergrund og i San Fransico's Bart."
Så vidt jeg har forstået rejsekortet, skal det også kunne tilbyde en passende rabat for folk der rejser meget på forskellige og skiftende ruter.
NFC ville som et minimum stadig kræve en database til dette formål.
Men hvordan forestiller du dig at mobiltelefonen skulle virke ? Vi skal jo videre end til at købe underlige papirstykker som rejsehjemmel.
Hvad kigger togkontrolløren efter når jeg rækker min mobil frem som bevis på at jeg har betalt ?
Poul-Henning
Et andet overkill i rejsekortet er jo også at det skal gøres til en form for alternativt betalingskort. I stedet skal man jo koncentrere sig om kerneopgaven som Poul-Henning siger, nemlig bare at fungere som en elektronisk rejsehjemmel.
Og før nogen politikere nu bestiller en studierejse til London og San Fransisco – ja så behøver man ikke at rejse længere end til Fyn
Løsningen med mobilen er begrænset – men den kører i øvrigt ved siden af den fulde løsning med kontaktfrie chipkort.
PS: Fyn er den ø der ligger mellem lillebæltsbroen og storebæltsbroen.
Ikke flere typer kort, og ikke konkurrence for konkurrencens skyld.
Til sådan noget som det her, skal det være simpelt, ikke fleksibelt.
Færdig.
Ikke noget pjat med flere systemer, eller ektra kompleksitet, fordi en eller anden har besluttet sig for at det skal kunne anvendes til alt muligt andet.
Hej Poul. Det er ikke sådan, at jeg har en grydeklar løsning til dig, men når det kan lade sig gøre for de to eksempler (Underground/BART) mon så ikke man kan strikke noget sammen til rejsekortet også? Jeg ved ikke konkret hvorfor rejsekortet er så meget mere kompliceret, men et rabatsystem og et zonesystem lyder som problemer der kan løses. Din rejsehistorie kan vel gemmes i kortet med passende mængder kryptografi?
De to eksempler ser ud til at bruge telefonen som erstatning for kontaktløst betalingskort, men NFC åbner dog muligheden for mere eksotiske løsninger. Ikke at jeg tror det vil være påkrævet for rejsekortet, men NFC vil inden for få år være at finde i mange telefoner.
Kontrolløren, ja han må jo så have en passende læser med (f.eks. en NFC telefon =)
Martin.
.. for rejsekortets skyld. Det er simpelthen ikke investeringen værd.
Det vi taler om er en gradvis overgang til trådløse betalingsformer, dvs. en kickstarter.
Selve takstopkrævningen har tydeligvis givet anledning til en masse problemer, men de er isoleret til applikationssiden. Det har INTET med betalingssiden at gøre.
Problemet skabes, hvis man gentager PBSs monopolkontrol med betalignspunkterne og ikke sikrer semantisk åbne kontaktpunkter, så alle former for trådløse betalinger kan køre igennem alle steder. Så bliver det bare til endnu et PBS-style monopol uden at skabe værdi for nogen.
Jeg kunne sagtens agitere for den bedste RFID-model eftersom RFIDsec (som jeg var med til at starte) producerer zeroknowledge-baseredet kort som er alt andet i markedet overlegent på sikkerhedsområdet.
Men vi har IKKE behov for EN lukket standard, men for ÅBNE interfaces til FORSKELLIGE modeller, der kan tilpasse sig behovene.
NFC bygger på ISO 14443a, men er bagved designet til blot at være en ny version af kreditkort med en eller anden gatekeeper in control. Nu vil teleselskaberne også på banen være Kalif i stedet for Kaliffen. Ligesom DSB har/havde den samme drøm.
Kravet er meget enkelt - åbne interfaces ved klip, så alle betalingsformer kan køre igennem. Den bedste måde at validere det på er at at Digital Cash skal kunne køre igennem, dvs. kontrolen må ikke ligge i selve kontaktpunktet eller ske via IDENTIFIKATION af et kort/en device - det skal løftes til at kunne ske rent semantisk, dvs. som et vilkårligt kryptografisk bevis der kan være transaktions-anonymt.
På den måde lever man op til alle de nævnte hensyn - istedet for som sædvanligt i Damark at reducere mennesker til ting, man flytter rundt på - og markeder til noget man udsteder monopoler til.
Når Offentlig/Privat samarbejde reduceres til at udlicitetere monopoler og magt over borgere fordi statsmagten ikke evner at tænker blot 2 uger ud i fremtiden er en sikker vej til fiasko.
Det er jo ikke så underligt at konkurrencen fungerer at h.. til i Danmark. Den offentlige planøkonomi tænker præcis som private karteller/monopoler. Hvad der ser billigt ud, er nok det bedste - konsekvensen er at vi alle skal betale langt mere for det samme - og betale med sikkerhed of blokering for innovation.
Valget er meget enkelt - åbne interfaces for at skubbe udviklingen konstruktivt eller spilde 2 mia kroner på noget som allerede er forældet.
Det kan vel forholdsvis nemt løses med eksisterende teknologi: SMS/MMS og 2D stregkoder.
Opret brugere der vil benytte systemet centralt, så alle bestillinger kan verificeres med pinkode. Lav et takstsystem der er baseret på f.eks. postnumre. Send en SMS med til, fra og billettype. Bestillingen bekræftes så med pin-kode. Herefter modtager man så en 2D stregkode på MMS. Den kan konduktøren så scanne ind. Med en simpel kodning af billetterne vil konduktøren ikke engang behøve at være online for at kontrollere billettens gyldighed.
For mig virker det underligt at vi skal udstyres med endnu mere elektronik for at kunne begå os i dagligdagen.
Det kan da gøres endnu enklere.
Hvorfor ikke lade DSB bare opkræve på basis af vores færden? Et overvågningskamera på hver station komblet med automatisk ansigtsgenkendelse eller en chip i nakken, så er den klaret.
Hvis man er lidt smart så kobler man det med direkte opkrævning hos arbejdsgiveren via det kommende NETFAKTURA, så det trækkes før du selv får mulighed for at disponere over din løn.
Super nemt - ingen brugerinvolvering, just pay-as-you-go.
"Hvorfor ikke lade DSB bare opkræve på basis af vores færden?"
Det vil da være tåbeligt ikke at udnytte muligheden for samtidigt at få 1. en brugervenlig flexibel digital betalingsløsning, 2. en betalingsmodel, der baserer sig på faktisk rejsestrækning så brugeren kan ombestemme sig undervejs, f.eks. ved transportmidlets forsinkelse/nedbrud. Sådan virker f.eks. BART i San Fransisco. 3. sparer udgifter og besvær til kontrol under rejsen. 4. giver trafikselskaberne mulighed for radikal forbedring af dynamisk og statisk kapacitetsstyring og ruteplanlægning.
Og det burde med dagens teknologi kunne lade sig gøre uden at DSB eller nogen anden central myndighed identificerer og analyserer den enkelte rejsende. Det skal seføli være et fast krav til løsningen.
"• At designe et nyt takstsystem, som er hidtil uset kompliceret – og formentlig unødvendigt."
En af årsagerne til rejsekortet, er HT's zonesystem. Der har været stor utilfredshed med dette system. Ofte, koster turen forskelligt, afhængigt af, om du rejser fra A til B - eller B til A. Dette giver forståelsesproblemer for befolkningen, på samme måde, som de ikke forstår mikrosofts operativsystemer (eks. hvis program A og B indstalleres, er resultat forskellig fra hvis de indstalleres i omvendt rækkefølge). Åbentbart er tendens til, at den almene befolkning ikke accepterer og forstår dette. Kun dataloger, forstår noget sådant, og har navn for sådan logik.
Rejsekortet indfører et nyt system, hvor det koster det samme at rejse fra A til B og B til A. Samtidigt, skulle prisen bedre afspejle den reelle rejses længde, og ikke være afhængig af manglen på en direkte forbindelse. Derfor klippes både når der stiges af og på således rejsens længde bestemmes udfra dette.
DSB's rejsekort er ikke "ny innovation". Det er tale om helt almindelige kommercielle RFID kort, som er præget med rejsekortets udseende, og som er lavet til den type formål. Aflæserne, er også almindeligt kommerciel RFID aflæsere, og atter er det igen udseendet (design), som er specielt. Elektronikken, er normalt købeelektronik.
Dertil, er rejsekortet forsynet med eget software. Et program, til håndtering af disse ting, er ikke specielt stort, eller kompleks at udvikle. Dog, kan det gøres stort, og dette er sandsynligvis sket her, da man fra starten besluttede størrelsen af opgaven. Herefter sikrer "leverandørene" jo oftest, at der kan trækkes flest mulige penge ud.
Formålet er selvfølgeligt, at komme bort fra zonesystemet, og tilrette pris mv. til det ønskede.
Det er naturligvis dyrt, at investere i nye klippekortsaflæsere overalt, og dette er sandsynligvis den dyreste investering. Dertil kommer lidt udvikling af software til formålet. Normalt, vil jeg tro en DTU studerende kunne gøre dette på et mindre projekt. Men, ofte går det politik i den slags, og så er prisen, og arbejdskraften ikke enkel - og kodestørrelsen svulmer måske op. Ellers er det ikke andet end en lille maskinkode program til kortet, samt lidt kode - enten i maskinkode eller C, til aflæseren, der bedst konstrueres med en simpel mikrocontroler.
Hvis noget gør rejsekortet dyrt, skyldes det sandsynligvis nogle forsøger at "malke" projektet, ved at have designet overflødigt kompleks elektronik der er dyrt, eller ved at gøre softwaren unyttig kompleks og dyr. Det er meget almindeligt, at konsulentvirksomheder og udviklingsvirksomheder gør dette, for at tjene kassen.
Leverandøren har jo givet en fast pris på de opstillede krav i udbuddet (herunder netop check-ud sluser på selv det mindste trinbræt).
Men det er vel således ikke nu i leverandørens interesse at forsinke projektet og dermed betale bod og vente på sin betaling.
Leverandøren søger ikke at malke projektet. Hvis nogen søger det, er det deres software ansatte, eller dem de hyrer til kodning.
Det kan så diskuteres, om de får yderligere indtægt, da projektet måske går i vasken.
Rejsekortet har nu selv svaret:
http://www.rejsekort.dk/presse/nyheder/2008/myter+og+misforståelser+om+...
Læses beskrivelsen på CW http://www.computerworld.dk/art/43951?cid=4&q=rejsekort&sm=search&a=cid&... fås det indtryk, at hovedproblemet er ustabilitet: Nogle gange udregnes en tur til 20 kroner, andre gange samme tur til 10 kroner - lidt afhængigt af hvordan vinden blæser. Måske glemmer den, at detektere udstempling, og tager 50 kroner. Eller systemet er bare "gået ned".
Disse problemer, må skyldes enten HW eller SW. Selvom DSB beskriver problemet som besværligt osv. kan jeg ikke tro, at det har noget med det at gøre. Den bør under alle omstændigheder, gøre ens hver gang. Har en programmør været i tvivl om metode og algorithme, er det ikke rette måde, at lade en tilfældighedsalgorithme afgøre hvilken algorithme der skal bruges. Det burde syntes logisk. Alligevel, ser ud til, at det er det som sker.
Jeg er næsten helt sikker på, at DSB ikke har skrevet algorithmen, og ladet tilfældigheder afgøre prisen. Det er simpelthen franskmændene der ikke kan kode. Hvis DSB havde indtastet en lille algorithme i eksempelvis basic, f.eks. på en gammel lommeregner, så havde den nok fungeret.
Algoritmen skal også understøttes af ganske mange parametre: Rejselængde (fra a til b via c og d), rejsetid, omstigning eller ej, aldersklasse (barn, voksen, pensionist, cykel, personale…), rejseklasse (business), pristabeller, rabatsatser, bonus…..
Den skal foretages dels her og nu baseret på data på kortet og data i en af flere tusinde apparater, som måske eller måske ikke er opdateret med seneste parametre – og programversioner.
Den skal også kunne efterregnes, korrigeres og suppleres back-office, og formentlig ikke med samme program som i apparaterne.
Opgaven er ikke helt uden sværhed.
Dog ser jeg ikke nødvendigheden af, at der tages hensyn til data i tusinder af datamater ved udregning af pris. Denne sker udfra en formel. Normalt, vil forløbet som rejsekortet har været udsat for (rejsens start, sidst udstemplet mv.) sandsynligvis stå på rejsekortet. Derfor er ikke nødvendigt at aflæse alle automater.
Det er muligt, at alle terminaler tilføjer data til en database, så snart de har mulighed for at gå online. Hvis det er brug for data fra andre terminaler, eller de ønskes valideret, så gøres det på baggrund af denne database, og ikke ved at kontakte samtlige terminaler.
Uanset opgavens sværhed, hører problemstillinger som ustabilt software, og priser der regnes tilfældigt ud, ikke under DSB. De har næppe specificeret at tingene skulle fungere sådant.
Opgaven er forholdsvis nem at definere, og kræver i sidste ende sikkert en række tabeller og en algorithme. Det kan gøres på en gammel lommeregner med basic.
Jeg tror opgaven vil være for lille til en studerendes eksamensprojekt (hvis vi alene ser på prisudregning).
Det er jo ærgerligt, at de studerende sådan falder af på det, når de har fået deres eksamen – når nu et korps på adskillige færdiguddannede ingeniører ikke allerede har knækket den nød.
Det er i øvrigt stadig ikke DSB (alene) der har specificeret opgaven, det er rejsekortselskabet, som også omfatter en række regionale trafikselskaber med en flåde af busser. Det er så rigtigt, at DSB vist nok specificerede nogle særkrav til interaktion med deres udstyr og systemer, som ikke gør opgaven mindre kompleks.
Jeg kender ikke Thales løsning på opgaven – men den med at kontakte alle andre apparater, tror jeg heller ikke på. Der indgår formentlig data på kortet samt data i apparatet, der håndterer den pågældende check-ud. Om disse apparater er permanent online er højest tvivlsomt. De sidder jo i kørende busser, står på vindblæste trinbræt eller hærværkseksponerede stationer. Synkronisering af parametre og programversioner samt indsamling af konsistente data fra disse enheder må være en udfordring.
For at anskueliggøre kompleksiteten i opgaven følgende eksempel. Jeg står på toget på Kbh H. Biip. Rejser på business til Århus H. Biip. Holder et møde på en time. Står på toget på Århus H. Biip. Rejser tilbage til djævleøen igen, men står af i Roskilde (selvom jeg hader det). Biip. En simpel algoritme opkræver mig fra Kbh H til Roskilde. Jubii.
Opgaven er ikke helt enkel, men jeg mener den er løst. I princippet kan vi sige, at vi har en funktion f, der som input tager rejsen på vores rejsekort (tilbage til hvor der er for lang rejseafbrydelse), og udregner prisen efter dette. Hver eneste gang vi stempler ind/ud skrives det foreløbige beløb, og dette modificeres så, efterhånden som rejses. Det interessante er, at det er en algorithme, der fuldkommen afhænger af rejsen som input, fra rejsekortet.
Problemerne (ifølge det omtalte på CW), ligger i, at selv samme rejse, ikke hver gang udregnes ens. Ovenstående algorithme, virker altid ens, for samme rejse.
Derfor har fejlene intet med den advancerede kalkulation af pris at gøre, trods prisen regnes forkert, og tilfældigt fra gang til gang. Algorithmen indeholder jo ingen tilfældighed, men er direkte f(rejsekort-sidste tur), og der er ingen tilstandsvariable, andet end dataene på rejsekortet (inputparametre). Derfor er det en utrolig simpel opgave, selvom det måske er lidt svært at forhandle sig til prisstrukturer, og udregne hvordan det skal gøres.
Programmeringsteknisk er det utroligt simpelt, og kan ikke give anledning til tilfældighed.
Hvis derimod, at rejsekortet ikke altid stemples, at der gemmes forkerte bits, eller input på anden måde er noget "vås", så kan komme forkert output. Dette er ikke DSB's problem.
Netop, at rejsekortet ikke altid stemples ved udgangen, trods den stemples, tyder på, at det ikke er DSB's problem, men et ustabilitetsproblem eller et rækkevideproblem i billetautomaten. Dette er et hardware problem, eller system software problem. Og er langt fra det, som DSB har leveret.
Jens, du har jo ret – og når disse problemer opstår på en teststrækning mellem Tølløse og Roskilde, og de sammenholdes med de andre komplikationer i fuld skala – så er der vist langt fra teori til praksis. Det er jo den ønskede kompleksitet i opsætningen, der er roden til den manglende stabilitet. Det er jo ikke bare et biip – men en ganske kompliceret transaktion der skal udfører mens en morgentravl passager lader sit kort suse forbi læseren.
"Det er jo den ønskede kompleksitet i opsætningen, der er roden til den manglende stabilitet."
Naturligvis indeholder opgaven flere dele - sandsynligvis kommunikation fra terminaler til "database", og fra database videre evt. til internet, samt kort og betalingssteder, og billetautomater, hvor rejsen kan udskrives. Deruodver er mulighed for opfyldning i automater mv. Måske er disse dele defekte, men den store del, vedrører ikke stempling og beregning af prisen fra A til B.
Vi kan derfor korte det ned til, at vi ved noget er galt, ved billetautomaten, samt den måde, den beregner turen på. Nu er opgaven simpel. Denne del, er i det store hele standard teknologi fra Thales - en RFID kortaftaster/gemmer, samt lidt software. Sikkert samme software som i Frankrig og resten af verden.
Min teori er, at det simpelthen ikke fungerer. Det har intet med DSB at gøre. Automaten fungerer intet sted i europa, eller resten af verden.
Problemet er kun, at DSB's prisberegning har afsløret fejlen. Alle andre steder, får kunderne bare rabat, og er tilfredse. De fleste ture detekteres nok ikke.
Thales må have et stort problem.
Det nuværende system har mange særheder, ikke kun at rejsen kan koste noget andet end tilbagerejsen.
Når du bruger billetter eller klippekort, så tæller du 'relative zoner', forstået på den måde, at rejsens pris bestemmer af den zone, der ligger længst væk - målt i zoner - fra påstigningsstedet.
Når du har periodekort, så tæller du derimod absolutte zoner - dvs kortet skal eksplicit være gyldigt til alle de zoner du rejser igennem.
Pendler man derfor imellem Ballerup og Høje Taastrup, så sætter man ofte penge til ved at have periodekort (5 eller 6 zoner), istedet for klippekort (3 zoner).
Rejsekortet skulle i stedet udregne efter afstand - smuk retfærdighed, der i 99 % af tilfældene vil betyde, at rejsen bliver dyrere end før.
/esni
"Rejsekortet skulle i stedet udregne efter afstand - smuk retfærdighed, der i 99 % af tilfældene vil betyde, at rejsen bliver dyrere end før."
Rejsekortet betyder ikke stor prisstigning. Det er rigtigt, at der vil komme noget prisstigning, men det vil det også uden rejsekortet.
I princippet, skal de samme penge ind, men på en mere retfærdig måde, og dertil skal så lægges den normale prisstigning for tog og busser, samt prisen for rejsekortet. I længden, kan det nemt blive billigere.
Når nu DSB allerede har rejseplanen som korrekt regner en rute ud med skift, zoner og pris, så virker det helt hen i vejret at rejsekort-systemet ikke kan benytte samme metode.
Alle rejser gemmes simpelthen som en rejse fra punkt A til punkt B, og så udregnes prisen for hver rejse når regnskabet skal gøres op. På den måde kan det gøres fuldstændigt uafhængigt af zoner og priser. Så kunne DSB også starte ud med at bruge det nuværende system og så bekymre sig om nye "smarte" zoner senere - man kan argumentere om de nuværende priser er fair, men de fleste danskere der bruger bus, tog eller metro bare en gang imellem er fuldstændig inde i hvordan zone-systemet virker. If it ain't broken, don't fix it.
Problemet er ikke prisberegningen, men at systemet er ustabilt - samme tur, giver ikke altid samme pris, trods klippet samme steder og samme tur. Dette skyldes ikke DSB's prissystem, men at systemet er ustabilt.
Jeg tvivler på, at DSB har skrevet selve koden til prisberegningen. Hvis de har, vil det typisk være en script eller lign. og ikke i C eller C++, da det er for farligt. Der sættes masser af krav, når der kodes stabile systemer, og i praksis kan kundeimplementeringer højst laves som fortolkning.
