Flexus, HB206 & Interoperabilitet. ITS Norge 28 september 2010

Transkript

1 Flexus, HB206 & Interoperabilitet ITS Norge 28 september 2010 Interoperabilitetstjenester AS Postboks 623 Sentrum 0106 Oslo Jørn Hanssen

2 Interoperabilitet i Oslo/Akershus Oslo og Akershus er i realieteten ett reisemarked Stort antall pendlere over fylkesgrensen Mange av disse er avhengige av både NSB og Ruter Billetteringssamarbeid var veletablert før elektronisk billettering ikke mulig å tilby ny løsning uten tilsvarende funksjonalitet Funksjonell interoperabilitet et kundekrav Bruk av en og samme billett for majoriteten av reiser, uavhengig av transportør Tilgang til abonnementsavtaler Tilgang til ulike former for kundesupport på tvers av selskapsgrenser

3 HB206 Et rammeverk for interoperabilitet Eksisterende versjon adresserer i hovedsak teknisk interoperabilitet Standardisert kortlayout og transaksjonsformat Teknisk interoperabilitet er nødvendig men ikke tilstrekkelig for å imøtekomme krav i markedet, jfr situasjonen i Oslo/Akershus Funksjonell interoperabilitet innebærer også blant annet Systemene må kunne kommunisere med hverandre Eksistens av produkter som virker på tvers av systemgrenser Eksistens av betalingsmidler som virker på tvers av systemgrenser som igjen fordrer organistorisk interoperabilitet Avtaler mellom de ulike partene som bla regulerer Bruk av felles kodeverk, sikkerhetselementer ol Vilkår og prosedyrer for tilslutning / utmelding Merkantile forhold Forhold knyttet til personopplysninger

4 Elementer i Flexus-samarbeidet Samsvar med tekniske krav i HB 206 Kjente avvik som ønskes rettet opp ifm overgang til nytt takst og sonesystem i Oslo/Akershus Produktinteroperabilitet Stored Value som ad-hoc betalingsmiddel Basert på ISO Public Transport Interoperable Fare Management System Nivå 3 (PTO) Nivå 4 (IO) informasjonsutveksling Behov for justeringer for å oppfylle krav i ny versjon av HB 206 Organisatorisk samordning på flere områder: Driftsforum Sentralt endringsråd Felles forvalting av spesifikasjoner for interoperabilitet Test og godkjenning Sikkerhet Personvern

5 IOs rolle i Flexus-samarbeidet Tiltrodd tredjepart ansvarlig for Sikkerhetsfunksjoner, herunder: Generering og distribusjon av kortnøkler Sertifikatutsteder ifm bruk av digitale signaturer for transaksjonsutveksling Registrar Collection and Forwarding agent Clearing operator Dokumentforvalter Test og godkjenningsinstans

6 Oppgjør ved bruk av StoredValue CardIssuer (NSB) 1. Kunden lader opp Flexus med 1000 kr hos SVLoadAgent (Ruter) 3 2. SVLoadAgent sender TX til IO 4 ClearingOperator IO 5 3. IO videresender TX til CardIssuer 4 Kunde 2 StoredValue LoadAgent (Ruter) 1 Penger Informasjon 4. IO genererer en rapport ihht oppgjørsregler sender til involverte parter 5. Ruter betaler 1000 kr til NSB ihht til oppgjørsregler

7 Kjøp av produkt betalt med StoredValue - Trinn 1 ProductOwner (Ruter) CardIssuer (NSB) 1. Kunden kjøper et Oslo 30 dgr med pris 570 kr. betalt med SV. ProductRetailer er Ruter ProductRetailer sender TX til IO ClearingOperator IO IO videresender TX til CardIssuer og ProductOwner 4. IO genererer en rapport ihht oppgjørsregler sender til involverte parter 4 Kunde ProductRetailer (Ruter) 1 Penger Informasjon 5. NSB (CardIssuer) betaler 570 kr til Ruter (Product Retailer) ihht til oppgjørsrapport 5. ProductRetailer anses å være finansielt grensesnitt mot kunden uansett!

8 Kjøp av produkt betalt med StoredValue - Trinn 2 NSB ServiceProvider (NSB) 1. IO sender en oppgjørsrapport til involverte parter, basert på vedtatte fordelingsregler ClearingOperator IO ProductRetailer betaler ut til involverte parter i henhold til oppgjørsrapport. Rapporten innholder både interne oppgjør innen forretningsenheten og eksterne oppgjør mellom forretningsenheter. Kun oppgjør mellom forretningsenheter effektueres i praksis ProductOwner (Ruter) 1 Ruter 2 ServiceProvider (Ruter) ProductRetailer (Ruter) 2 Generell regel for fordeling ifm salg: ProductOwner: a % ProductRetailer b% ServiceProvider 1 c% ServiceProvider 2 d %..sum %- andel = 100% Penger Informasjon

9 Kommentarer til eksemplet Behov for avtaleregulering ifm finansielle oppgjør: Infrastruktur for transaksjonsutveksling og sperrelistedistribusjon må være på plass Samordningen av regler for oppgjør mellom partene må også regulere risikooverganger, eksempelvis ifm Tap/tyveri av kort som kan erstattes ihht avtale: Risikoovergang kunde kortutsteder Kortutsteder har sperret kort, men ServiceProvider har ikke mottatt sperreliste

10 Test og godkjenning Test og godkjennelsesprosedyrer inngår i ulike sammenhenger: Nye systemer kobles opp i nettverket; Verifisere kortlayout ihht krav i HB206 Verifisere at kort oppdateres ihht krav i HB206 ved ulike typer basisoperasjoner Ulike typer interoperabilitetstester avhengig av samordningsnivå Verifisere at transaksjoner genereres med struktur og innhold som definert i HB206 Ved systemendringer på eksisterende systemer Testdekning må besluttes etter risikoanalyse

11 Testfasiliteter i IO Test og sertfiseringshåndbok utarbeidet i samarbeid med DNV Egen testlab med alle relevante utstyrstyper Oppkoblig mot testservere på nivå 4 Dedikert QA-miljø med samme konfigurasjon som produksjonsanlegg Egenutviklet card-browser med forskjellige nyttige kapasiteter Lesing, kopiering og lagring av innhold på kort på alle trinn i testgjennomføring Automatisk rapportering av endringer på kort mellom hvert steg i testscenarier Verifisere at transaksjoner genereres med struktur og innhold som definert i HB206 Gjør det mulig å gjennomføre distribuerte tester ved å utveksle card-dumps via mail mellom flere parter

12 Browser View

13 Test case overview

14 Spørsmål?