Avtale om Digitale Tjenester v. 3.0

• Innledning

o Overordnet

o Kontaktpunkt for avtalen

o Beskrivelse av plattformen

• Funksjonsnivåer

• Sanntidsdata

• Oppdrag og plandata

o Plandata for rutesatte turer og vognløp

o API for plandata eksport til operatører

o Oppdrag for bestillingstransport

▪ Tjenestemottakers Førerapplikasjon

▪ SUTI

▪ Y2M (tjenesteYter2tjenesteMottaker)

• Krav til løsninger

o Spesielle krav til Salg/billettering

o Spesielle krav til kortlesere for validering av reiserett

o Spesielle krav til Dynamisk Passasjerinformasjon (DPI)

o Spesielle krav til MQTT

o Spesielle krav til Signalprioritering (TSP)

o Spesielle krav til lydsignal ved utløsning av stoppknapp

o Spesielle krav til passasjertelling (APT)

o Spesielle krav til Bluetooth Beacons (BLE)

• Ytelseskrav til funksjonsnivåer

o Generelle krav

o Ytelsesnivåer

• Ruterlogg API

• Godkjenning av dataprodusenter

o SIT (Site Integration Test)

o CAT (Customer Acceptance Test)

o VV (Vehicle Verification)

• Versjons- og livsløpshåndtering

o Versjonshåndtering

▪ Minor versjon

▪ Major versjon

o Livsløpshåndtering

o Oppstart av ny leveranse

• Endringsbestemmelse for avtalen

• Sanksjoner

o Definisjoner

Innledning

Overordnet

Denne avtalen regulerer og beskriver Xxxxxx krav til digitale tjenester i tilknytning til sin produksjon. Avtalen beskriver 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, og deler av Viken.

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 livsløpet til avtalen i henhold til et eget versjonshåndterings regime. Tjenestemottaker ønsker å motivere Tjenesteytere til å oppgradere til nyere versjoner i takt med Xxxxxx egne versjonslanseringer. Versjons- og livsløpshåndtering er beskrevet i eget kapittel.

Kontaktpunkt for avtalen

Alle feilmeldinger og annen teknisk kontakt skal rettes xxx-xxxxxxx@xxxxx.xx.

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.

Beskrivelse av plattformen

Avtale om Digitale tjenester beskriver i denne versjonen i hovedsak leveranser av digitale tjenester for to varianter av persontransport. Rutesatt og bestillingstransport.

Rutesatt transport baserer seg i stor grad på planlagte oppdrag mellom faste punkter basert på tidtabeller.

Bestillingstransport er mer dynamisk av natur, og lar planlegges enten ad-hoc eller med kort tidshorisont.

Ruters digitale plattform støtter begge variantene, men kan benytte forskjellig type teknologi og grensesnitt.

Illustrasjon, grensesnitt Tjenestemottaker/Tjenesteyter Rutesatt transport

Illustrasjon, eksempler på grensesnitt Tjenestemottaker/Tjenesteyter Bestillingstransport

Funksjonsnivåer

Noe forskjellig funksjonalitet mellom transporttypene og kjøretøykategoriene gjør det nødvendig å stille forskjellige krav til forskjellige kjøretøy. Tjenestemottakers transporttjenestekontrakter kan derfor inneholde en beskrivelse av hvilket funksjonsnivå hver enkelt kjøretøytype skal levere.

Hvis kjøretøyet skal levere flere funksjonstyper, skal kjøretøyet levere på alle dataemner til sammen beskrevet i funksjonsnivåtabellen.

Tjenestemottakers transporttjenestekontrakter kan inneholde en beskrivelse av hvilke funksjonsnivåer som skal oppfylles. Komplette funksjonssett gjelder hvis ikke annet er definert.

*) Funksjoner med spesialkrav utover det som er definert i ITxPT.

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.

API v. 3.0

Oppdrag og plandata

Plandata for rutesatte 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 (blocks) 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.

Den operative plandatabasen er den autoritative kilden til produksjonssatt trafikk, og vil til enhver tid være oppdatert med plandata for de neste 14 dager. Det er Tjenesteyters ansvar å validere datasettets innhold mot sin produksjon.

Identifikatorer for block, 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 Blocknummer kan ingen referanser brukt i planleggingsfasen regnes som korrekte.

Tjenestemottaker presiserer at SIRI ET er tenkt brukt primært til overføring av ekstraoppdrag, men vil varsle aktuelle Tjenestetilbydere før grensesnittet tas i bruk.

SIRI-ET i henhold til norsk SIRI profil: xxxxx://xxxxxxx.xxxxxxxxx.xxx/xxxx/xxxxxx/XXXXXX/xxxxx/000000000/XxxxxxxxxxXXXXxxxxxxxx

NeTEx i henhold til nordisk NeTEx profil: xxxxx://xxxxxxx.xxxxxxxxx.xxx/xxxx/xxxxxx/XXXXXX/xxxxx/000000000/XxxxxxxXxXXxxXxxxxxx

API for plandata eksport til operatører

Ruter tilgjengeliggjør plandata på NeTEx-format slik at operatørene kan bruke Ruters data for pålogging. Dataen tilgjengeliggjøres i form eksportfiler på NeTEx-format som operatørene kan laste ned fra et API. API-et skal gjøre det mulig å overføre plandata i en automatisert prosess og sikre at hver operatør kun har tilgang til sine egne data.

Det blir tilgjengeliggjort nye plandataeksporter i API-et ukentlig. Det blir laget en eksport per kontrakt og eksportene inneholder data for gjeldende kontrakt i de kommende to ukene.

Diagrammet under illustrerer hvordan man henter plandata for én kontrakt:

Id og versjon

Hver eksport har en id og en versjon. Iden er id-på kontrakten, og versjonen er et firesifret løpenummer. Kombinasjonen av id og versjon er unik og angir en bestemt eksportfil. Når det lages en ny eksport for en kontrakt inkrementeres versjonen.

Autentisering

API-et krever autentisering med token for å få tilgang til data. Hver operatør har kun tilgang til eksportene for egne kontrakter.

Endepunkter

POST https://xxxxx-xxxxxx.xxxxxxxx.xx/{api-version}/token

Endepunktet brukes for å hente et autentiseringstoken som er nødvendig for å få tilgang til de andre endepunktene i API-et.

GET https://xxxxx-xxxxxx.xxxxxxxx.xx/{api-version}/contracts/

Endepunktet brukes for å finne id på kontraktene man er interessert i. Endepunktet returnerer alle kontraktene operatøren har tilgang til med id og navn.

GET https://xxxxx-xxxxxx.xxxxxxxx.xx/{api-version}/contract/{contract-id}/status

Endepunktet brukes for å sjekke om det har kommet oppdateringer av plandataen på en bestemt kontrakt. Endepunktet returnerer versjonen på alle tilgjengelige eksporter av gjeldende kontrakt. For å kunne sjekke om det har kommet oppdateringer må operatøren selv vite hva den siste versjonen de har lastet ned er. Da kan operatøren bruke endepunktet til å finne ut hva som er siste tilgjengelige versjon og sammenligne den mot versjonen de har lagret.

GET https://xxxxx-xxxxxx.xxxxxxxx.xx/{api-version}/contract/{contract-id}/version/{version-id}

Endepunktet brukes for å hente en URL som gir tilgang til en eksport med en bestemt versjon for en bestemt kontrakt.

GET {signed-URL}

For å laste ned filen må operatøren gjøre en ny request mot URL-en endepunktet returnerer. URL-en er gyldig i en time.

En enkelt eksport inneholder plandata for en bestemt kontrakt innenfor de neste to ukene. Eksporten består av et filsett som er zippet til en zip-fil. I filsettet er det en XML-fil per linje i kontrakten og en XML-fil for felleselementer som kan gjenbrukes på tvers av alle linjene.

Linjefilene inneholder linjen filen gjelder for, turer med tilhørende turmønstere, ruter og mer. Fellesfilen inneholder stoppesteder, blokker og mer. Hver XML-fil består av en publication delivery med ulike frames for dataelementer i henhold til Enturs NeTEx-modell.

Testing

API-et er tilgjenglig for testing i staging-miljøet til Ruter. Erstatt xxxxx://xxxxx- xxxxxx.xxxxxxxx.xx med xxxxx://xxxxx-xxxxxx.xxxxx.xxxxxxxx.xx. I stage kreves det en egen client id og secret.

Oppdrag for bestillingstransport

For funksjonskategoriene i bestillingstransport finnes det forskjellige måter å formidle data og oppdrag. Funksjonsmatrisen beskriver de forskjellige varianter som er gyldige for hvilken type bestillingstransport.

Tjenestemottakers Førerapplikasjon

Tjenestemottaker publiseres oppdrag og kjørelister gjennom en forhåndsavtalt applikasjon. Fører registrerer påbegynt oppdrag og de faktiske hente- og leveringstider.

Tjenesteyter skal til enhver tid ha avtalt versjon av applikasjon installert på sine enheter.

SUTI

For kjøretøy i funksjonskategori M2Y (B2B) vil all overføring av oppdrag, herunder avbestillinger, nye bestillinger og øvrige endringer gjennom hele døgnet fortløpende utveksles gjennom tjenestemottakers SUTI endepunkt.

Tjenesteyter skal fortløpende bekrefte og rapportere tilbake, gjennom samme grensesnitt, mottak av oppdrag, oppdrag tildelt løyve (bil) og de faktiske hente- og leveringstider, inkludert GPS- posisjon.

SUTI i henhold til beskrivelse på XXXX.xx .

SUTI selvdeklarasjon: xxxxx://xxxxx.xxxxxxxxx.xxx/x/x/XXXxxxx0

Y2M (tjenesteYter2tjenesteMottaker)

Dette funksjonsnivået benyttes i konfigurasjoner hvor Tjenesteyter er den initierende parten i oppdragsutveksling og rapportering. Dette er typisk i kontrakter der Tjenesteyter selv sitter med bestillingsmottaket, enten direkte i kjøretøyet (praiing) eller gjennom eget kjørekontor.

Tjenestemottaker vil tilby Tjenesteyter grensesnitt både for oppslag og rapportering. Grensesnittet kan benyttes både av tjenesteyters kjørekontor og ombord i kjøretøyet. Ved bestilling gjennom Tjesteyters kjørekontor, kan Tjenesteyter gjøre oppslag på:

• Kundeinformasjon

• Antall tilgjengelige turer

• Egenandel, inkludert evt. oppnådd tak

Når kunde setter seg i bil, skal Tjenesteyter gjøre oppslag fra kjøretøyets takstameter og be om oppdaterte oppdragsdetaljer, i tilfelle dette har endret seg siden den opprinnelige bestilling.

Tjenesteyter initierer avtatalt identifiseringsflyt med passasjer, som bekrefter turen på sin mobiltelefon. For spesielt skjermede passasjerer vil det utarbeides egne flyter som hensyntar dette.

Ved endt tur skal det – uten opphold – leveres rapporteringsdata som beskriver turen. Nødvendige datafelter er beskrevet i beskrivelsen av grensesnittet. xxxxx://xxxxx.xxxxxxxxx.xxx/x/x/X00Xx0xX

Krav til løsninger

All maskinvare, installasjoner og tjenesteproduksjon ombord i kjøretøy/fartøy, skal være i henhold til spesifikasjonene i ITxPT S01 og S02. Utstyr og tjenester skal ha bestått godkjenning

og være utstyrt med ITxPT-merking i henhold til prosessen beskrevet under xxxxx://xxxxx.xxx/xxxxxxxxxx/xxxxx-xxxxxxxx/.

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

For kjøretøy som kun betjener funksjonskategorier for bestillingstransport og/eller er definert som personbil tillates dataleveranser fra utstyr uten ITxPT-merking der tjenesteyter finner det formålstjenlig.

Spesielle krav til Salg/billettering

Spesielle krav til Salg/billettering vedlikeholdes i et vedlegg til denne avtalen. Vedlegg – Xxxx Xxxx/Billettering

Spesielle krav til kortlesere for validering av reiserett

I kontrakter hvor det kravstilles validering av reiserett i andre posisjoner enn ved fører, er det behov for kortlesere.

Tjenestemottaker vil levere ferdigkonfigurerte kortlesere klare til førstegangsinstallasjon hos tjenesteyter.

Tjenesteyter skal besørge montering i henhold til vedlagt spesifikasjon, herunder både strøm og nettverk. Kortleserne skal ha tilgang til nødvendige endepunkter – både om bord, og backoffice.

Tjenesteyter skal aktivt overvåke enhetene, både gjennom elektronisk overvåkning i tillegg til daglig visuell inspeksjon.

Tjenestetyter har ansvar for at alle avganger blir kjørt med det korrekte antall fungerende kortlesere.

Bytte av kortleser skal rapporteres inn til Tjenestemottaker så snart enheten er skiftet ut. Innmeldingen skjer elektronisk ved at Tjenesteyter melder inn byttet på webportal. Sammendrag fra innmeldt skjema skrives ut og klistres på defekt enhet, og legges i kasse for defekte deler på lager.

Tjenestemottaker sørger for at Tjenesteyter har tilgang på tilstrekkelig antall fungerende kortlesere til sitt reservedelslager, basert på Tjenesteyters løpende rapportere behov.

Tjenestemottakers valg av leverandør og/eller kortlesermodell vil kunne endres i løpet av avtalens løpetid.

Vedlegg – Ruters monteringsveiledning - Kortleser, v1.0

Spesielle krav til Dynamisk Passasjerinformasjon (DPI)

Spesielle krav til Dynamisk passasjerinformasjon vedlikeholdes i et vedlegg til denne avtalen Vedlegg – Krav Dynamisk passasjerinformasjon

Spesielle krav til MQTT

For kjøretøy i funksjonskategorier omfattet av MQTT, skal 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 både Websockets og standard MQTT protokoll.

• Kun MQTT versjon 3.1.1 og 5.0 er støttet av Tjenestemottaker. Tjenestemottaker gjør oppmerksom på at versjon 5.0 vil være minimumsversjon i neste hovedversjon av ADT.

• 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

• Broker skal konfigureres med støtte meldingsstørrelser opp til 4096 kB

Spesielle krav til Signalprioritering (TSP)

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

Spesielle krav til lydsignal ved utløsning av stoppknapp

Tjenestemottaker tilgjengeliggjør en lydfil gjennom sin CDN. Tjenesteyter skal laste ned og benytte den til enhver tid publiserte filen som eneste lydvarsling i passasjerområdene.

Spesielle krav til passasjertelling (APT)

Sensorer som benyttes skal kategorisere av- og påstigende i kategoriene definert i gjeldende API- dokument.

Tjenestemottaker skal motta kategoriene BIKE, PRAM og WHEELCHAIR i tillegg til ADULT og CHILD.

For sensorer som benytter høyde som et element i kategoriseringen, definerer Tjenestemottaker følgende verdier.

Kategori	Høyde
ADULT	≥1200 mm
CHILD	<1200 mm

Tjenestemottaker godtar sensorprodusents dokumenterte deteksjon av andre kategorier

Spesielle krav til Bluetooth Beacons (BLE)

I kontrakter hvor tjenestemottaker kravstiller beacons, skal tjenesteyter anskaffe, montere og drifte beacons på lik linje med annet utstyr. Tjenesteyter skal vedlikehold hvilke beacons som tilhører hvilket kjøretøy i tjenesteyters vognregister. Beacons skal monteres slik at alle deler av kjøretøyet har god dekning fra minst ett aktivt beacon.

• Beacons skal være av typen Bluetooth Low Energy Beacons .

• Beacons skal støtte både iBeacon og Eddystone-

• Beacons skal ha støtte for programmering av UUID.

• Beacons skal ha støtte for OTA firmwareoppdatering.

Ytelseskrav til funksjonsnivåer

Ytelses- og funksjonalitetskravene 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.

• Xxxxxxx 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

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

Tjenesteyter skal selv være i stand til å overvåke og måle kvalitet på leveransen av egne tjenester.

Tjenestemottaker kan ved behov gjøre tjenesteyter oppmerksom på elementer ved leveransekvaliteten som bør utbedres. Tjenesteyter skal undersøke årsak og utbedre de bakenforliggende elementene i henhold til nærmere avtalte frister.

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.

Intensjonen med ytelsesnivåene er å fokusere på de viktigste dataemnene først, siden dataemnene på nivåene under har liten eller ingen verdi uten data på nivåene over.

1 (Absolutt)	Dataemner som ved bortfall gjør det umulig å benytte andre dataemner og dermed fører til bortfall av digital kundeopplevelse samt Ruters mulighet til å følge opp produksjonen.
2 (Kritisk)	Dataemner som ved bortfall gjør det vanskelig å benytte andre dataemner og dermed kan føre til bortfall av digital kundeopplevelse samt Ruters mulighet til å følge opp produksjonen.
3 (Viktig)	Dataemner som ved bortfall sterkt forringer digital kundeopplevelse og Ruters mulighet til å følge opp produksjonen.
4 (Normal)	Dataemner som ved bortfall forringer digital kundeopplevelse og Ruters mulighet til å følge opp produksjonen.

Alle ytelsesnivåene måles pr blokk, dvs fra signon til signoff. Både tomkjøringer og ruteavganger i blokken har samme ytelseskrav. Begrunnelsen for dette er å kunne gi god kundeopplevelse og følge opp produksjonen også på tomturer. Dessuten er dette vesentlig enklere å implementere enn målinger per tur.

Kate- gori

Ytelsesni vå

Dataemne og intensjon

Krav

Terskel for at avgangen skal merkes med

SLA-brudd

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 dataemnene til utarbeidelse av statistikk og innsikt.

Intensjon

Intensjonen er at pålogging og avlogging skal sendes når et kjøretøy starter å betjene og avslutter å betjene et kjøreoppdrag (block).

Det skal unngås å sende fiktive manuelle eller systemskapte av- og pålogginger.

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 kjøreoppdrag.

• Ved avkortning av kjøreoppdrag 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 kjøreoppdrag avbrytes før det er ferdigstilt. Xxxxxxx også hvis et annet kjøretøy skal overta.

Hvis et eller flere kriterier ikke er oppfylt.

Senso rs

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.

Intensjon

Intensjonen er at posisjon skal sendes 1 gang/sekundet med beste kvalitet under rådende forhold. For å ta høyde for dårlig mobildekning tillater vi enkelte brudd i posisjons- strømmen. For å ta høyde for QoS 0 tillater vi at frekvensen på posisjonsmeldinger kan være noe lavere enn ønsket innstilling

• Gjennomsnittlig intervall mellom posisjons- meldinger skal være innenfor et toleransevindu på 0,9 - 2,0 sekunder i løpet av en avgang.

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

o Hvis intervallet overstiger 60 sekunder vil man begynne på neste brudd, slik at f.eks. et intervall på 3 minutter og 10 sekunder regnes som 4 brudd og utilgjengelig tjeneste. Flere brudd på over 10 sekunder innenfor en sammenhengende periode på 60 sekunder regnes som 1 brudd.

• Gjennomsnittlig intervall mellom posisjons- meldinger skal ikke overskride 2 sekunder 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 med samme intervall men merket at det ikke er dekning eller eventuelt om det benyttes projeksjon (dead-reckoning) for å gi posisjon

Hvis et eller flere kriterier ikke er oppfylt.

Senso rs

Odometer

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

Intensjon

Intensjonen er at odometer skal sendes 1 gang/sekundet med beste kvalitet under rådende forhold. For å ta høyde for dårlig mobildekning tillater vi enkelte brudd i datastrømmen. For å ta høyde for QoS 0 tillater vi at frekvensen på meldinger kan være noe lavere enn ønsket innstilling.

Odometerverdien skal reflektere kjøretøyets totale kilometerstand der det er mulig

• Gjennomsnittlig intervall mellom odometer- meldinger skal være innenfor et toleransevindu på 0,9 - 2,0 sekunder i løpet av en avgang.

• Intervall mellom odometer-meldinger som overstiger 10 sekunder regnes som et brudd i datastrømmen. Det tillates 3 brudd i løpet av en avgang.

• Gjennomsnittlig intervall mellom odometer- meldinger skal ikke overskride 2 sekunder 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.

Senso rs

Passasjertelling (APC)

Passasjertelling brukes av Tjenestemottaker for å vise fyllingsgrad på avganger i sanntid, for å kunne gi bedre informasjon til reisende, for å planlegge rutetilbudet, for å vurdere behov for innsatsbusser samt å utarbeide trafikkstatistikk for Tjenestemottakers nettverk. Xxxxxxxxx kan bli delt eksternt etter utarbeidede prinsipper for å sikre kundene en mer helhetlig og sømløs reise på tvers av mobilitetsleverandører.

Passasjertelling brukes også til å validere at kjøretøyets dørsensorer fungerer.

• APC-melding må sendes pr. dør til Tjenestemottaker etter at dørstatus har blitt endret fra anyDoorOpen til allDoorsClosed, og må mottas maksimalt 30 sekunder etter endring av dørstatus. Det tillates inntil tre (3) manglende meldinger pr. tur eller APC-melding fra 90% av holdeplasser betjent med dørlukking.

• Kravet er 95% presisjon mellom avstigende og påstigende pr. kjøretøy pr. block. For beregning av presisjon tillates det avviket som gir minst tellefeil i løpet av en block. Avviket måles på enten inntil ti (10) personer eller 5% etter formelen

absolutt (påstigende-avstigende)/(påstigende+avstigende)

•

• Hvis en block ikke tilfredsstiller kravet til presisjon, regnes presisjonen som underkjent for alle avganger i blocken.

Hvis et eller flere kriterier ikke er oppfylt.

Senso rs

Klokke

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

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

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

Senso rs

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.

Intensjon

Intensjonen er at temperaturmålinger skjer regelmessig, og kan sendes maksimalt 4 ganger i minuttet, men minst en gang i minuttet. med beste kvalitet under rådende forhold. For å ta høyde for dårlig mobildekning tillater vi enkelte brudd i posisjons- strømmen. For å ta høyde for QoS 0 tillater vi at frekvensen på meldinger kan være noe lavere enn ønsket innstilling.

Gjennomsnittlig intervall mellom temperaturmeldinger skal være innenfor et toleransevindu på 14-65 sekunder i løpet av en avgang.

• Intervall mellom temperaturmeldinger som overstiger 120 sekunder regnes som et brudd i datastrømmen. Det tillates 2 brudd i løpet av en avgang

o Hvis intervallet overstiger 120 sekunder vil man begynne på neste brudd, slik at f.eks et intervall på 6 minutter regnes som 3 brudd og utilgjengelig tjeneste.

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

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

Intensjonen er å innføre krav til ytelse i neste major release.

Senso rs

Utendørstemperatur

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

Intensjon

• Gjennomsnittlig intervall mellom temperaturmeldinger skal være innenfor et toleransevindu på 14-65 sekunder i løpet av en avgang.

• Intervall mellom temperaturmeldinger som overstiger 120 sekunder regnes som et brudd i datastrømmen. Det tillates 2 brudd i løpet av en avgang

o Hvis intervallet overstiger 120 sekunder vil man begynne på neste brudd, slik at f.eks. et intervall på 6 minutter regnes som 3 brudd og utilgjengelig tjeneste.

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

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

Intensjonen er å innføre krav til ytelse i neste major release.

Senso rs / PE

Dørstatus

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

For alternative konfigurasjoner kan dørstatus indikere tilgjengelighet for om bord- og avstigning. F.eks. landgang på ferger.

• Dørstatus pr dør sendes umiddelbart ved åpning og lukking. Status skal sendes i en gitt sekvens.

o Å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.

• Se for øvrig krav til Passasjertelling

Hvis et eller flere kriterier ikke er oppfylt.

Senso rs

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.

Senso rs

Vindusviskerstatus

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

• Sendes ved hver tilstandsendring av vindusviskerfunksjon, ikke ved hver viskerbevegelse.

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

Senso rs

Akselerometer

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

Intensjon

Intensjonen er at akselerometermeldinger skal sendes 1 gang i minuttet med beste kvalitet under rådende forhold. For å ta høyde for dårlig mobildekning tillater vi enkelte brudd i datastrømmen. For å ta høyde for QoS 0 tillater vi

at frekvensen på meldinger kan være noe lavere enn ønsket innstilling.

• Gjennomsnittlig intervall mellom meldinger skal være innenfor et toleransevindu på 55-125 sekunder i løpet av en avgang.

• Intervall mellom meldinger som overstiger 300 sekunder regnes som et brudd i datastrømmen.

Det tillates 2 brudd i løpet av en avgang

o Hvis intervallet overstiger 300 sekunder vil man begynne på neste brudd, slik at f.eks et intervall på over 600 sekunder regnes som 2 brudd og utilgjengelig tjeneste.

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

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

Intensjonen er å innføre krav til ytelse i neste major release.

Senso rs

Energiforbruk (kWh)

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

Intensjon

Intensjonen er at energiforbruksmeldinger skal sendes 1 gang i minuttet med beste kvalitet under rådende forhold. For å ta høyde for dårlig mobildekning tillater vi enkelte brudd i datastrømmen. For å ta høyde for QoS 0 tillater vi

at frekvensen på meldinger kan være noe lavere enn ønsket innstilling.

• Gjennomsnittlig intervall mellom meldinger skal være innenfor et toleransevindu på 55-125 sekunder i løpet av en avgang.

• Intervall mellom meldinger som overstiger 300 sekunder regnes som et brudd i datastrømmen.

Det tillates 2 brudd i løpet av en avgang

o Hvis intervallet overstiger 300 sekunder vil man begynne på neste brudd, slik at f.eks et intervall på over 600 sekunder regnes som 2 brudd og utilgjengelig tjeneste.

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

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

Intensjonen er å innføre krav til ytelse i neste major release.

Senso rs

Batterinivå (SOC, kun elbuss)

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

Intensjon

Intensjonen er at SOC skal sendes 1 gang i minuttet med beste kvalitet under rådende forhold. For å ta høyde for dårlig mobildekning tillater vi enkelte brudd i datastrømmen. For å ta høyde for QoS 0 tillater vi at frekvensen på meldinger kan være noe lavere enn ønsket innstilling.

• Gjennomsnittlig intervall mellom meldinger skal være innenfor et toleransevindu på 55-125 sekunder i løpet av en avgang.

• Intervall mellom meldinger som overstiger 300 sekunder regnes som et brudd i datastrømmen.

Det tillates 2 brudd i løpet av en avgang

o Hvis intervallet overstiger 300 sekunder vil man begynne på neste brudd, slik at f.eks. et intervall på over 600 sekunder regnes som 2 brudd og utilgjengelig tjeneste.

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

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

Intensjonen er å innføre krav til ytelse i neste major release.

Senso rs

Ladestatus (kun elbuss)

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

• 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.

Dynamisk passasjerinformasjon (DPI)

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

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

• Xxxxxx xxxxxxxx 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.

Salg av billetter

Salg av billetter er viktig for å gi inntektssikring for Tjenestemottaker

RuterSalg-diagnosemodulen om bord i kjøretøy/fartøy måles hvert minutt under en avgang. På hver holdeplass/stoppested måles det at følgende krav er oppfylt:

• At sjåfør/operatør av billettsalget er pålogget

Hvis en sjåfør kjører på en faktisk

tur uten å være pålogget regnes dette som avvik.

Sjåføren skal være pålogget på alle stoppesteder gjennom hele turen, f.o.m. første holdeplass

t.o.m. siste.

Avvik regnes dersom sjåføren ikke er pålogget på en av holdeplassene i løpet av turen.

Validering/aktivering av reiserett *

Validering av reisrett bidrar til Tjenestemottakers inntektssikring

*: Dette dataemnet vil få ytelsesnivåkrav lik

“Normal” fra neste hovedversjon av Avtale om Digitale Tjenester

Xxxxxxxxx rapporterer hvert minutt diagnostikkdata gjennom MQTT

Når en eller flere kortlesere ikke rapporterer tilgjengelighet gjennom en hel 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.

Oppdragsutveksling Konsentra Førerapp

Fører benytter førerapplikasjon i henhold til avtalt prosedyre.

Hvis et eller flere kriterier ikke er oppfylt.

Oppdragsutveksling SUTI

Oppdragsbekreftelse gjelder overføring, oppdatering og avslutning av aktuelle oppdrag.

Tjenesteyter må bekrefte mottatt oppdrag gjennom SUTI- Grensesnittet

Tjenesteyter melder tilbake tildelt bil (løyve)

Kjøretøyet registrerer faktiske hente- og leveringstider, inkludert GPS posisjon.

Hvis et eller flere kriterier ikke er oppfylt.

Oppdragsrapportering Y2M

Tjenesteyter utveksler data i henhold til grensesnitt beskrevet for funksjonsnivå Y2M

Hvis et eller flere kriterier ikke er oppfylt.

Ruterlogg API

Ruterlogg er oppdragsgivers system for logging av trafikkhendelser og avvik. Tjenesteyter vil få tilgang til både en web-versjon av dette for manuell registrering av hendelser, og til et API for maskinell registrering. Hvilke saker som skal logges avtales nærmere mellom oppdragsgiver og tjenesteyter, men det kan f.eks. gjelde innstillinger, forsinkelser eller problemer med datakvalitet.

API beskrivelse kommer her.

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.

For rene BackOffice to BackOffice integrasjoner, avtales testløp fra gang til gang.

SIT (Site Integration Test)

Før oppstart og ved signifikante endringer i infrastruktur hos Tjenesteyter skal det kjøres en SIT test.

• Testing av nettverkstilkobling mellom Tjenesteyter og Tjenestemottaker

• Velformethet for meldinger og rapporter både M2Y, Y2M og MQTT

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.

Versjons- og livsløpshåndtering

Versjonshåndtering

Avtale om Digitale Tjenester endres gjennom versjonering og tjenestemottaker kan velge å gi ut to typer nye versjoner, major og minor. Versjonene er nummerert som [major].[minor] i avtalen.

Minor versjon

Tjenestemottaker kan velge å gi ut nye minor versjoner av avtalen og tilhørende dokumentasjon for å ivareta nye leveranseavtaler eller piloter som inkluderer f.eks. nye kjøretøy klasser eller funksjoner. En minor versjon endrer ikke funksjonalitet og krav fra foregående versjoner med samme major versjon.

Ved nye minor versjoner er Tjenesteyter ikke forpliktet til å levere på denne med unntak av når en ny leveranseavtale spesifiserer at dette er minimumsversjonen som kan benyttes eller at det er inngått en avtale utover leveranseavtalen som spesifiserer dette. Tjenesteyter kan selv velge å implementere en minor versjon hvis ønskelig. Hvis ikke annet er oppgitt er det rimelig å anta at ny funksjonalitet i en minor versjon vil bli inkludert i en major versjon på et senere tidspunkt.

Major versjon

Tjenestemottaker gir ut en major versjon når man ønsker å legge til eller endre funksjoner for leveranser knyttet til denne avtalen

Tjenesteyter forplikter seg til å kople seg til Ruters digitale tjenester slik som de er beskrevet i denne avtalen på enten siste eller nest siste major versjon, men står selv fritt til å bestemme migrasjonstakten. Endringsbestemmelse for versjons oppgradering er beskrevet i eget punkt.

Livsløpshåndtering

Tjenesteyter har totalansvar for livssyklusforvaltning av utstyr, programvare og andre ytelser som er nødvendig for å opprettholde er høyt tjenestenivå.

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

Oppstart av ny leveranse

I forbindelse med oppstart av ny leveranseavtale hvor det er spesifisert at denne avtalen kommer til anvendelse vil det også være angitt versjonen som skal benyttes ved oppstart av leveransen.

Tjenesteyter kan ikke velge og levere på et lavere versjonsnivå en angitt i leveranseavtalen. Dette er uavhengig om det er en major eller minor versjon som er oppgitt.

Uavhengig av minimumsversjon angitt i transporttjenestekontrakten, vil avtaleversjonen som legges til grunn for beregning av eventuelle incitament være seneste, samt nest seneste versjon av denne avtalen.

Endringsbestemmelse for avtalen

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.

Sanksjoner

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

Definisjoner

Begrep

Kontekst

Betydning

Kjøreoppdrag (Block)

Rutesatt transport

Bestillingstransport: heltidsinnleid

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/garasje men andre varianter kan finnes.

Kjøreoppdrag

Bestillingstransport: timesinnleid

For kjøretøy uten fast innleietid regnes hver enkelt tur som et oppdrag

Avgang	Rutesatt transport	Kjøring fra et forhåndsdefinert startstoppested til et forhåndsdefinert endestoppested, med stopp for på- og/eller avstigning på mellomliggende stoppesteder langs en fastsatt trasé/kjørevei.
Avgang	Bestillingstransport: heltidsinnleid	Enkeltoppdrag innenfor kjøreoppdrag
Avgang	Bestillingstransport: timesinnleid	Se Kjøreoppdrag
Kortleser	Kjøretøy	Avleser for validering av reiserett, ikke tilkoblet RuterSalg.

Document Metadata

Table of Contents

Avtale om Digitale Tjenester v. 3.0

Document Metadata