Avtale om Digitale Tjenester v. 2.0

Owned by Degerdalen Tommy (Unlicensed)
Last updated: Feb 15, 2023 by Monika Zidonyte
13 min read

Beskrivelse av den tilbudte tjenesten

Denne avtalen regulerer utvekslingen av data mellom en Tjenesteyter, som regel et operatørselskap for mobilitetstjenester, og Ruter As (heretter kalt Tjenestemottaker), som er administrasjonsselskap for mobilitetstjenester i Oslo-regionen.

Tjenestemottaker har en Digital Plattform (RDP), hvor det produseres aggregerte tjenester for brukerne av mobilitetstilbudet. Disse tjenestene baserer seg på data fra kjøretøy/fartøy og mobilitetskunder. Tjenesteyter har ved inngåelse av en Transporttjenestekontrakt (TTK) forpliktet seg til å levere data i henhold til Avtale om Digitale Tjenester. For at tjenesteyter og Tjenestemottaker i samarbeid skal kunne produsere best mulig tjenester, regulerer denne avtalen kvalitetskrav til dataproduksjonen/-utvekslingen mellom Tjenesteyter og Tjenestemottaker.

Ruters Avtale om Digitale Tjenester er gjenstand for oppgraderinger i henhold til et versjoneringsregime. Ruter ønsker å motivere Tjenesteytere til å oppgradere til nyere versjoner i takt med Ruters egne versjonslanseringer.

Tjenesteyter forplikter seg til å kople seg til Ruters digitale tjenester slik som de er beskrevet her på enten siste eller nest siste major versjon, men står selv fritt til å bestemme migrasjonstakten. For eksempel kan flåten migreres til nyere avtale-versjon kjøretøy for kjøretøy, depot for depot, eller alt på én gang. Avtaleforpliktelsene gjelder per kjøretøy ut fra den avtale-versjonen som kjøretøyet til enhver tid har jobbet mot.

Inneværende avtale dekker API v2.0.

Kontaktpunkt hos Tjenestemottaker

Alle feilmeldinger og annen teknisk kontakt skal rettes til rdp-support@ruter.no.

Alle Tjenesteytere må, som del av utført SIT-test, innrapportere en tilsvarende kontaktadresse til Tjenestemottaker.

Tjenesteyter forplikter seg til enhver tid å sørge for at Tjenestemottaker har korrekt kontaktinformasjon både for tekniske henvendelser og henvendelser relatert til oppfølging av denne avtalen.

Løsningsarkitektur

Tjenesteyter og Tjenestemottaker

Datakommunikasjon

Sanntidsdata mellom Tjenesteyter og -mottaker bruker i hovedsak en felles infrastruktur for utveksling av sanntidsdata til og fra kjøretøy/fartøy. MQTT-data passerer gjennom Tjenestemottakers MQTT-server, og tjenestekvaliteten måles umiddelbart bak denne. For å holde forsinkelse av dataleveranse og feil i datatransport lav ønsker og anbefaler Tjenestemottaker færrest mulig ledd mellom kjøretøyets/fatøyets og Tjenestemottakers MQTT-broker.

Tjenestemottakers applikasjon RuterSalg gjør i tillegg et antall REST-kall mot baksystem hos Tjenestemottaker og dennes underleverandører.

Tjenestemottakers DPI-applikasjon skal ha tilgang til nedlasting av statiske filer fra Tjenestemottakers CDN. Se nærmere beskrivelse under «Spesielle krav til DPI».

Maskinvare

All maskinvare, installasjoner og tjenesteproduksjon ombord i kjøretøy/fartøy, skal være i henhold til spesifikasjonene i ITxPT. Utstyr og tjenester skal ha bestått godkjenning og være utstyrt med ITxPT-merking i henhold til prosessen beskrevet under https://itxpt.org/technology/itxpt-labeling/.

For noe utstyr som ikke er helt eller delvis omfattet av ITxPT standarden kan spesielle krav til maskinvare være beskrevet i denne avtalen under egne punkter.

Dataelementer

Sanntidsdata

De aller fleste dataemnene som ønskes overført i sanntid over MQTT, er hentet fra ITxPT sin emnestruktur. Enkelte emner er imidlertid Ruter-spesifikke. Dokumentasjon av API-et er beskrevet i eget versjonert dokument.

Plandata for turer og vognløp

Det er svært viktig at dataintegriteten mellom Tjenesteyter og Tjenestemottaker er så høy som mulig. Begge parter skal derfor synkronisere rute- og vognløpsdata til sine operative systemer fra Tjenestemottakers operative ruteplandatabase. hver gang det er publisert en endring. Data publiseres på NeTEx (planlagte data) og SIRI ET (akutte endringer)-format. Identifikatorer for vognløp, tur og turmønster skal ikke manipuleres.

Merk at dette ikke er det samme datasettet som er brukt i forbindelse med planlegning av rutetilbudet mellom Tjenesteyter og Tjenestemottaker. Utenom Vognløpsnummer kan ingen referanser brukt i planleggingsfasen regnes som korrekte.

SIRI-ET i henhold til norsk SIRI profil:

NeTEx i henhold til nordisk NeTEx profil:

Spesielle krav til Salg/billettering

Tjenestemottaker kjører sitt eget system RuterSalg for salg ombord i kjøretøy/fartøy. Følgende krav til kapabiliteter stilles til Tjenesteyter:

  • Salgsenheten skal benytte Android operativsystem, versjon 7.0 eller nyere.

  • Oppgradering til nyere versjon av operativsystem skal utføres når oppdragsgiver har behov for dette, senest innen tretti (30) virkedager fra dato oppdragsgiver melder slikt behov.

  • Salgsenheten skal ikke kjøre andre applikasjoner enn RuterSalg.

  • Når oppdragsgiver produksjonssetter nye versjoner av RuterSalg-applikasjonen, skal enheten oppdateres med den nye versjonen innen ti (10) virkedager fra dato oppdragsgiver gir melding om at ny versjon er tilgjengelig.

  • I kjøretøyet/fartøyets kommunikasjonsgateway må det åpnes for REST-oppslag fra RuterSalg mot følgende baksystem:

    • NOD for billett-tjenester

    • Okta for innlogging- og autentiseringstjenester

    • Ruter PSS for flyt og styring av forretningsregler

  • NFC enheten må være kompatibel med ISO/IEC18092 standarden og ha support for skriving til og lesing fra MIFARE Desfire og MIFARE Ultralight, og skal støtte konfigurerbar tilbakemelding til kunde. NFC enheten skal ha skjerm, med diagonal størrelse 2,5” – 4,5”, og være i stand til å vise tekst, minimum 32 tegn, vendt mot kunden.

  • Kvitteringsskriver må ha støtte for tilkobling av salgsenhet, og skal ha en utskriftshastighet på minimum 50 mm/sek. Skriveren skal kunne skrive ut QR-koder, og ha en papirstørrelse mellom 58 og 80 mm bredde.

  • Kvitteringsskriver skal ha støtte for Bluetooth 3.0 eller høyere.

Spesielle krav til Dynamisk Passasjerinformasjon (DPI)

Tjenestemottaker kjører sitt eget system for DPI ombord. Følgende krav til kapabiliteter stilles:

Krav til skjermer

  • Skjermen skal ha automatisk lysjustering ut fra omgivelsene

  • Skjermen skal være ikke-reflekterende

  • Skjermen skal ha en synsvinkel på 178 grader både horisontalt og vertikalt.

  • Skjermen skal ha minimum oppløsning på 1920 piksler i bredden.

  • Alle skjermer må laste inn DPIs webapplikasjon og kjøre den i en nettleser, anbefalt av type Chrome/Chromium.

  • Skjermplayeren må støtte følgende tekniske kapabiliteter:

    • HTML 5

    • CSS 3

    • ECMAScript 6

    • Websockets

    • Webworkers / Serviceworkers

    • HTML video i H.264-format opp til 1080P

    • Canvas / SVG

    • WebGL

    • IndexedDB

    • Local storage

  • Alle data lagret av DPI-applikasjonen skal vedvare mellom restart og skal aldri slettes av en operatørprosess

  • Skjermene må konfigureres med forhåndsdefinerte visninger tilpasset skjermens forholdstall (aspect ratio), funksjon og plassering

  • Skjermene skal alltid vise den riktige skjermkonfigurasjonen ved oppstart

  • Operatøren skal overvåke at playeren viser en html side levert av Ruter

  • Operatøren skal laste inn applikasjonen på nytt om det skulle oppstå problemer

  • Kjøretøyet skal ha en web-server ombord som skjerm-playerene kan laste inn DPI applikasjonen og annet statisk innhold fra

Oppdatering av statisk innhold

  • DPI-applikasjonen skal holdes oppdatert når Ruter publiserer nye versjoner av applikasjonen eller media-filene applikasjonen er avhengig av. Disse gjøres tilgjengelig som pakker i ZIP-format og blir beskrevet i en manifest-fil tilgjengelig på definerte URLer for produksjons-miljøet og pre-produksjonsmiljøet.

  • Operatøren skal regelmessig sjekke om nye versjoner av DPIs nedlastbare pakker er tilgjengelige i Ruters produksjons-kanal

  • Når nye pakker er tilgjengelige skal operatøren laste disse ned og påse at alle kjøretøyer har fått installert det nye innholdet innen de begynner å kjøre den påfølgende morgen

  • Operatøren skal validere at pakken er lastet ned riktig og pakket ut på riktig måte

  • Minst 16 GB lagringsplass må være tilgjengelig for å lagre Ruters innhold om bord på kjøretøyet

  • Operatøren skal laste ned planlagte nye versjoner fra en pre-prod kanal i et test-miljø og påse at versjonen testes før den settes i produksjon

Lydmeldinger

  • Når kjøretøyet mottar en MQTT-melding med lydinnhold skal operatøren spille av lyden som kommer enten i OPUS- eller MP3-format

  • Unntaksvis, hvis meldingen definerer en levetid som er forbi, må lydinnholdet ikke spilles

  • Når en melding inneholder flere lydfiler må disse spilles av i rekkefølgen de forekommer i meldingen

  • Behandling av MQTT-meldinger med lydinnhold skal skje synkront og nye meldinger spilles kun etter at de foregående er ferdigspilt

Spesielle krav til MQTT

Arkitekturskisse for MQTT

  • Alle Tjenesteyters kjøretøy/fartøy skal rute datatrafikken gjennom en MQTT broker med bridging mot Tjenestemottaker. Dataemner skal her oversettes mellom kjøretøyets/fartøyets lokale adresser og Tjenestemottakers globale adresser. Tjenestemottaker leverer en konfigurasjonsfil med disse oversettelsene for alle nødvendige dataemner.

  • MQTT-broker skal kunne kommunisere med DPI-applikasjonen og RuterSalg-applikasjonen over Websockets.

  • Kun MQTT versjon 3.1.1 og 5.0 er støttet av Tjenestemottaker

  • All MQTT-kommunikasjon skal være kryptert med TLS v1.2

  • All MQTT infrastruktur må spesifikt støtte bridging av meldinger med retain-flagg satt

 

Spesielle krav til Signalprioritering (TSP) (gjelder ikke båt)

  • Tjenestemottaker skal konsumere dataemnet pe/tsp og umiddelbart sende det 7 bits hex-kodede telegrammet på en VHF-sender i kjøretøyet i henhold til standarden VDV R09.16

  • Frekvens 154.725000MHz

  • Signalstyrke 1 W

  • Modulasjon FFSK, 2400 baud

Krav til ytelsesnivå per avgang

Ytelseskravene er utarbeidet for å sikre at Tjenestemottager kan levere sine verdier til sine kunder og eiere. Ved utarbeidelsen av ytelseskrav til tjenestene er følgende prinsipper fulgt:

  • Kravene skal være mulig å oppfylle med standard teknologi og normale kvalitetsrutiner.

  • Kravene skal baseres på Tjenestemottakers erfaringer fra innsamling av lignede data.

  • Kravene skal tillate et normalt bortfall i forhold utenforliggende hendelser.

  • Kravene skal ha handlingsrom for forbedring av tjenesten for Tjenesteyter.

  • Kravene skal være målbare av både Tjenesteyter og Tjenestemottaker basert på utvekslede data.

  • Kravene skal være begrunnet i forhold til verdien de har for Tjenestemottaker

Generelle krav til API-bruk

Alle dataemner beskrevet i API-dokumentet skal produseres av respektive Tjenesteyter eller Tjenestemottaker dersom annet ikke er oppgitt. Dokumentets avsnitt 1.4 List of topics beskriver denne ansvarsfordelingen. Tjenesteyter plikter å produsere alle dataemner, korrekt utfylt, merket med Producer: Vehicle.

Ytelsesnivåer

Tjenestemottakers transporttjenestekontrakter kan inneholde økonomiske insentiver som helt eller delvis kan basere seg på ytelsene definert i denne avtalen. Det er definert tre ytelsesnivåer som kan benyttes til å regulere insentiver.

  • Absolutt: Dataemner som ved bortfall gjør det umulig å benytte andre dataemner og dermed fører til bortfall av digital kundeopplevelse.

  • Kritisk: Dataemner som ved bortfall forringer digital kundeopplevelse sterkt, samt Ruters mulighet til å følge opp produksjonen.

  • Normal: Dataemner som ved bortfall forringer digital kundeopplevelse uten at det går ut over Ruters mulighet til å følge opp produksjonen.

Alle ytelsesnivåene måles pr avgang. Hvis en avgang etterfølger en tomkjøring i sitt vognløp, inngår tomkjøringen i kravet til ytelsesnivå for avgangen. Altså stilles samme ytelseskrav til tomkjøringer som til ruteavganger.

Definisjoner

Kjøreoppdrag (Block): Et vognløp kan bestå av et eller flere kjøreoppdrag hvor kjøreoppdrag er en sammenhengende periode i tjeneste for Ruter som kan inneholde både tomkjøringer og avganger uten pauser imellom. Et typisk kjøreoppdrag strekker seg fra utkjøring fra depot til retur til depot men andre varianter kan finnes. 

 

Kategori

Ytelsesnivå

Dataemne

Krav

Terskel for at avgangen skal merkes med
SLA-brudd

Driver Interaction (DI)

Absolutt

Pålogging og avlogging av kjøretøy

Pålogging og avlogging av kjøretøy er en svært kritisk funksjon som binder alle dataemner som  produseres av et kjøretøy til Tjenestemottakers digitale kundetjenester samt er det som muliggjør utnyttelse av de samme datamennene til utarbeidelse av statistikk og innsikt.

/di/assignment_attempt/block
med respons /oi/current_vehicle_journey/state eller /di/assignment_attempt_rejection/block.

Gyldig pålogging skal være mottatt:

·         Før kjøretøyet starter et Kjøreoppdrag (block) men tidligst 30 minutter før planlagt start. Normalt ved utkjøring fra depot.

·         Så snart et kjøretøy skal overta for et annet på samme vognløp.

·         Ved avkortning av vognløp så snart et kjøretøy foretar avkortningen.

Gyldig avlogging skal være mottatt:

·         Senest 15 min. etter at kjøreoppdrag (block) er slutt. Normalt når kjøretøyet ikke skal kjøre flere turer og returnerer til depot.

·         Så snart et vognløp avbrytes før det er ferdigstilt. Gjelder også hvis et annet kjøretøy skal overta.

Hvis et eller flere kriterier ikke er oppfylt.

Sensors

Kritisk

Posisjon

Posisjon brukes av Tjenestemottaker til å generere fremdrifts-status på turer og vognløp. Denne fremdrifts-statusen brukes til å gi kunder sanntidsinformasjon om avganger, ankomster, forsinkelser og avvik. Fremdrifts-status er også viktig for å kunne utarbeide statistikk og innsikt om avviklingen av Tjenestemottakers tjenester.

/sensors/gnss/location

·         Gjennomsnittlig intervall mellom posisjons-meldinger skal ikke overskride 2 sekunder i løpet av en avgang.

·         Gjennomsnittlig forsinkelse ved mottak av posisjons-meldinger skal ikke overskride 2 sekunder i løpet av en avgang.

·         Intervall mellom posisjons-meldinger som overstiger 10 sekunder regnes som et brudd i posisjons-strømmen. Det tillates 3 brudd i løpet av en avgang.

·         Informasjon om satellittdekning og vertikal nøyaktighet skal alltid sendes med posisjons meldinger. Presisjonen på posisjoner skal alltid være med høyeste mulige presisjon i henhold til de rådende forhold gitt av disse parameterne.

·         Ved mangel på dekning skal det fremdeles sendes meldinger i samme intervall men merket at det ikke er dekning eller eventuelt om det benyttes projeksjon (dead-reconing) for å gi posisjon.

Hvis et eller flere kriterier ikke er oppfylt.

Kritisk

Passasjertelling (APC)

Passasjertelling brukes av Tjenestemottaker for å vite fyllingsgrad av avganger i sanntid for å kunne gi bedre informasjon til reisende samt å utarbeide trafikkstatistikk for Tjenestemottakers nettverk. Passasjertelling brukes også til å validere at dørsensorer fungerer.

/sensors/apc_sensors/<sensor-id>

·         APC-melding må sendes pr. dør til Oppdragsgiver etter at dørstatus for døren har blitt endret fra “åpen” til “lukket”, og må mottas maksimalt 30 sekunder etter endring av dørstatus. Det tillates inntil 1 manglende meldinger pr. avgang.

·         Det tillates et avvik mellom av og påstigende i løpet av en avgang på 5% etter formelen
absolutt(påstigende-avstigende)/((påstigende+avstigende)/2). Avviket måles over hele vognløpet og blir likt for alle avganger i vognløpet hvis det er flere enn 500 påstigende eller avstigende. Hvis det er færre legges foregående vognløp til kjøretøyet, ett eller flere, til beregningen inntil antallet påstigende eller avstigende overstiger 1000.

Hvis et eller flere kriterier ikke er oppfylt.

Kritisk

Odometer

Odometer brukes av Tjenestemottaker som en redundant løsning for posisjon der mottaksforholdene for posisjon er vanskelige eller satellittdekning ikke er tilgjengelig.

/sensors/odometer

Oppdateringsfrekvens oppgis i dataemne

/mi/provider_clients//provided_topics

·         Gjennomsnittlig intervall mellom odometer-meldinger skal ikke overskride 2 sekunder i løpet av en avgang.

·         Gjennomsnittlig forsinkelse ved mottak av odometer-meldinger skal ikke overskride 2 sekunder i løpet av en avgang.

·         Intervall mellom posisjons-meldinger som overstiger 10 sekunder regnes som et brudd i posisjons-strømmen. Det tillates 3 brudd i løpet av en avgang.

·         Odometer skal ikke nullstilles eller gjøre «roll-over» i løpet av et Kjøreoppdrag (Block).

Hvis et eller flere kriterier ikke er oppfylt.

Normal

Klokke

Klokkesignalet brukes for å synkronisere tidsfremvisning på enheter som brukes til publikumsinformasjon slik som DPI skjermer.

/sensors/clock

 

·         Gjennomsnittlig intervall mellom klokkemeldinger skal ikke overskride 1 minutt målt av DPI-diagnose modulen ombord i kjøretøyet/fartøyet i løpet av en avgang.

Hvis kriteriet ikke er oppfylt.

Normal

Kabintemperatur

Kabin temperatur brukes for å kunne gjøre en faktabasert behandling av kundeklager samt å utarbeide statistikk for overvåkning av eventuelle andre krav til klima i kjøretøyet.

/sensors/telemetry

·         Gjennomsnittlig intervall mellom temperatur-meldinger skal ikke overskride 2 min i løpet av en avgang.

·         Gjennomsnittlig forsinkelse ved mottak av temperatur -meldinger skal ikke overskride 5 sekunder i løpet av en avgang.

·         Intervall mellom posisjons-meldinger som overstiger 10 minutter regnes som et brudd i posisjons-strømmen. Det tillates 2 brudd i løpet av en avgang.

Hvis et eller flere kriterier ikke er oppfylt.

Normal

Utendørstemperatur

Utendørs temperatur brukes for å forbedre prognose på avgangstider og kalibrering/analyse av passasjertellinger.

/sensors/telemetry

·         Gjennomsnittlig intervall mellom temperatur-meldinger skal ikke overskride 2 min i løpet av en avgang.

·         Gjennomsnittlig forsinkelse ved mottak av temperatur -meldinger skal ikke overskride 5 sekunder i løpet av en avgang.

·         Intervall mellom posisjons-meldinger som overstiger 10 minutter regnes som et brudd i posisjons-strømmen. Det tillates 2 brudd i løpet av en avgang.

 

Hvis et eller flere kriterier ikke er oppfylt.

Normal

Dørstatus

Dørstatus brukes for å gi bedre sanntidsinformasjon, å styre trafikkprioritering samt å validere at passasjertellere fungerer.

·         Dørstatus pr dør sendes umiddelbart ved åpning og lukking. Status skal sendes i en gitt sekvens. Åpen status skal etterfølges av lukket status og lukket status skal etterfølges av åpen status. Det tillates inntil 2 meldinger utenfor sekvens pr dør på kjøretøyet/fartøyet pr. avgang. For alternative konfigurasjoner kan dørstatus indikere tilgjengelighet for om bord- og avstigning. F.eks. landgang på ferger.

·         Ved mottak av passasjertelling skal det være sendt en dørstatus for lukking for samme dør maksimalt 30 sekunder før. Det tillates inntil 1 manglende meldinger pr. avgang.

Hvis et eller flere kriterier ikke er oppfylt

 

 

Stoppsignal

Stoppsignal brukes for å gi bedre passasjerinformasjon ombord samt å forbedre fremdrifts-status på turer og vognløp.

·         Stoppsignal sendes umiddelbart når reisende aktiverer dette hvis kjøretøyet/fartøyet har stoppsignal.

Kravet inngår ikke i ytelseskrav for incentiv ordninger men er omfattet av generelt krav til bruk av API.

 

 

Vindusviskerstatus

Vindusviskerstatus brukes for å forbedre prognose på avgangstider og kalibrering/analyse av passasjertellinger.

/sensors/telemetry/01000007

·         Sendes ved hver tilstandsendring av vindusvisker.

 Kravet inngår ikke i ytelseskrav for incentiv ordninger men er omfattet av generelt krav til bruk av API.

 

Normal

Akselerometer

Akselerometer brukes for å skape ny innsikt om generell kundekomfort, sikkerhet og veikvalitet.

/sensors/telemetry/01000008

·         Gjennomsnittlig intervall mellom akselerometer-meldinger skal ikke overskride 2 minutter i løpet av en avgang.

·         Gjennomsnittlig forsinkelse ved mottak av akselerometer-meldinger skal ikke overskride 5 sekunder i løpet av en avgang.

·         Intervall mellom akselerometer-meldinger som overstiger 10 minutter regnes som et brudd i akselerometer -strømmen. Det tillates 2 brudd i løpet av en avgang.

Hvis et eller flere kriterier ikke er oppfylt.

 

Normal

Energiforbruk (kWh)

Energiforbruk brukes til å samle miljø-innsikt om leveranse av rutetilbudet.

/sensors/telemetry

·         Gjennomsnittlig intervall mellom energiforbruk-meldinger skal ikke overskride 2 minutter i løpet av en avgang.

·         Gjennomsnittlig forsinkelse ved mottak av energiforbruk -meldinger skal ikke overskride 5 sekunder i løpet av en avgang.

·         Intervall mellom energiforbruk -meldinger som overstiger 10 minutter regnes som et brudd i energiforbruk -strømmen. Det tillates 2 brudd i løpet av en avgang.

Hvis et eller flere kriterier ikke er oppfylt.

 

Normal

Batterinivå (SOC, kun elbuss)

Batterinivå brukes for å samle operativ innsikt om bruk av el-busser i rutetilbudet.

/sensors/telemetry/01000005

·         Gjennomsnittlig intervall mellom batterinivå-meldinger skal ikke overskride 2 minutter i løpet av en avgang.

·         Gjennomsnittlig forsinkelse ved mottak av batterinivå -meldinger skal ikke overskride 5 sekunder i løpet av en avgang.

·         Intervall mellom batterinivå -meldinger som overstiger 10 minutter regnes som et brudd i batterinivå-strømmen. Det tillates 2 brudd i løpet av en avgang.

Hvis et eller flere kriterier ikke er oppfylt.

 

 

Ladestatus (kun elbuss)

Ladestatus brukes for å gi bedre sanntidsinformasjon samt å samle operativ innsikt om bruk av el-busser i rutetilbudet.

/sensors/telemetry

·         Sendes ved hver tilstandsendring av ladning

Kravet inngår ikke i ytelseskrav for incentiv ordninger men er omfattet av generelt krav til bruk av API.

 

Kritisk

Dynamisk passasjerinformasjon (DPI)

Fremvisning av korrekt informasjon til passasjerene om bord er viktig for Tjenestemottaker

/pe/dpi_diag

DPI-diagnosemodulen om bord i kjøretøy/fartøy måler hvert minutt under en avgang at følgende krav er oppfylt:

·         Antall skjermer som rapporterer stemmer med antallet Operatøren har oppgitt for kjøretøyet

·         Skjermene har seneste versjon av både DPI-applikasjonen og mediepakken

·         Reiseinformasjon vist på skjermene stemmer med reiseinformasjon publisert av Ruter til operatør

·         Skjermene er i stand til å lagre informasjon over tid, uavhengig av på-/avlogging

·         Skjermene er satt opp med riktig skjermtype ift. Oppløsningen

Når et av kravene ikke oppfylles på mer enn 2 minutter i løpet av en avgang regnes dette som et brudd.

Det tillates inntil 2 brudd på kriteriene pr. avgang.

 

 

Eksternt skilt

Fremvisning av korrekt informasjon til passasjerene om bord er viktig for Tjenestemottaker

 

·         Ekstern skilt-melding sendes umiddelbart når eksterne skilt endres uavhengig om det er grunnet fjernstyring eller manuell overstyring.

Kravet inngår ikke i ytelseskrav for incentiv ordninger men er omfattet av generelt krav til bruk av API.

Proprietary Extensions (PE)

Absolutt

Salg av billetter

Salg av billetter er viktig for å gi inntektssikring for Tjenestemottaker
/pe/sales_diag

RuterSalg-diagnosemodulen om bord i kjøretøy/fartøy måler hvert minutt under en avgang at følgende krav er oppfylt:

·         At sjåfør/operator av billettsalget er pålogget

Når et av kravene ikke oppfylles på mer enn 2 minutter i løpet av en avgang regnes dette som et brudd.

Det tillates inntil 2 brudd på kriteriene pr. avgang.

Alle ovennevnte ytelsesmålinger og registreringer av brudd på avtalen fanges automatisk opp av Tjenestemottakers systemer med unntak av der det nevnes spesifikt at det ikke fanges.

Tjenesteyter vil selv kunne gjøre tilsvarende målinger for å verifisere Tjenestemottakers funn ved å logge datastrømmer i den felles MQTT-infrastrukturen eller om bord i kjøretøy/fartøy.

For brudd på krav som ikke har et definert ytelsesnivå kan Tjenestemottaker følge opp disse i henhold til andre avtaler/kontrakter som benytter seg av denne avtalen.

Godkjenning av dataprodusenter

Før et kjøretøy/fartøy kan starte sine dataleveranser til Tjenestemottakers produksjonsplattform, skal en sekvens av tester ha blitt gjennomført og godkjent, i riktig rekkefølge. Dette bidrar til å sikre gode og stabile tjenesteleveranser.

SIT (Site Integration Test)

Dette er den første testen som en Tjenesteyter må gjennomgå. Den skal i utgangspunktet kun utføres én gang per Tjenesteyter, og inneholder:

·         Testing av nettverkskonnektivitet mellom Tjenesteyter og Tjenestemottaker

·         Velformethet for MQTT-meldinger

Ved signifikante endringer i infrastruktur hos Tjenesteyter (bytte av IT-leverandør eller liknende) skal det utføres ny SIT.

CAT (Customer Acceptance Test)

CAT skal utføres for hver kjøretøytype som skal settes i produksjon, og forutsetter godkjent SIT. Testen utføres i samarbeid mellom Tjenesteyter og Tjenestemottaker, og skal kvalitetssikre at alle relevante data produseres og konsumeres om bord i denne kjøretøytypen.

VV (Vehicle Verification)

VV er en test som utføres av Tjenesteyter på hvert enkelt kjøretøy som skal gå i produksjon. Den forutsetter at kjøretøytypen er godkjent gjennom en CAT, og rapporteres i et onlineskjema som tilgjengeliggjøres av Tjenestemottaker.

Sanksjoner

Sanksjoner for brudd på avtalens ytelsesnivå kan defineres i Tjenestemottakers transporttjenestekontrakter.

Livssyklusforvaltning

Tjenesteyter har totalansvar for livssyklusforvaltning av utstyr, programvare og andre ytelser som er nødvendig for å opprettholde det til enhver tid avtalte tjenestenivå.

Tjenesteyteren skal aktivt sørge for at leveransen er tidsmessig i tiden fra driftssetting og gjennom hele kontraktsperioden.

Endringsbestemmelser

Tjenesteyter forstår at den ytelse som leveres er dynamisk av natur. Det ligger innenfor avtalen at Tjenesteyter forplikter seg til å oppdatere sin plattform hver gang ny major versjon av API/plattform-versjon slippes fra Tjenestemottakers side, Dette avstedkommer intet krav på økt godtgjørelse med unntak for de situasjoner der en ny versjon krever vesentlig oppgradering av Tjenesteyters plattform uten at dette burde vært forutsett av Tjenesteyter.

 

Avtale om digitale tjenester på engelsk: