DRAFT] - Avtale om Digitale Tjenester v2.1

[DRAFT] - Avtale om Digitale Tjenester v2.1

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. Xxxxx ønsker å motivere Tjenesteytere til å oppgradere til nyere versjoner i takt med Xxxxxx 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.1

Kontaktpunkt hos Tjenestemottaker

Alle feilmeldinger og annen teknisk kontakt skal rettes til 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.

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

API v2.1 [Ikke klart]

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: Norwegian SIRI profile NeTEx i henhold til nordisk NeTEx profil: Nordic NeTEx Profile

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.

• Salgsenheten skal ha en ytelse tilsvarende AndroidPassmark score 2000 eller bedre.

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

o NOD for billett-tjenester

o Okta for innlogging- og autentiseringstjenester

o Ruter PSS for flyt og styring av forretningsregler

• Salgsenheten må ha en skjermstørrelse i området fra 5.5” til 10”

• NFC-enhet skal ha NFC-lese og -skrivekapabilitet, og må være kompatibel med ISO/IEC18092 standarden og ha support for MIFARE Desfire/Ultralight og ISO 14443 A/B kort.

• Eksterne NFC enheter 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 og ha en papirstørrelse mellom 58 og 80 mm bredde.

• Kvitteringsskriver skal støtte utskrifter av QR koder, Model 2 med Error correction level M

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

• Kvitteringsskriver skal støtte kansellering av utskrift

• Salgsenheten skal være dimensjonert for å minimum støtte tilkobling for ytterlige to periferienheter, som betalingsterminal eller liknende

Funksjonstest RuterSalg

Før innfasing av nye enheter for RuterSalg skal tjenesteyter stille til rådighet for tjenestemottaker en komplett fysisk testrigg av hver implementasjon, inkludert salgsenhet, skriver og kortleser.

Minimum 4 måneder før driftssetting skal testriggen ha gjennomgått en fullstendig funksjonstest med tjenestemottaker. Funksjonstesten innebærer kontroll av at alle enheter fungerer i henhold til kravene. Hvis kravene ikke oppfylles, skal tjenestetilbyder finne alternative enheter for godkjenning.

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:

o HTML 5

o CSS 3

o ECMAScript 6

o Websockets

o Webworkers / Serviceworkers

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

o Canvas / SVG

o WebGL

o IndexedDB

o 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 Xxxxx 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 ytelses- og funksjonalitetsnivå

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

Funksjonsnivåer

Enkelte oppdrag kan være av en art at Tjenestemottaker ikke ser det fordelaktig med leveranse på alle elementer i denne avtalen.

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

Hvis transporttjenestekontrakten ikke henviser til noen funksjonstype, skal man levere på komplette data

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

Av og Pålogging av

Posisjon

Odometer

Klokke

Passasjertelling

Temperaturdata

Dørstatus

Stoppsignal

Vindusviskerstatus

Akselerometer

Energiforbruk

Batterinivå (SOC)

Ladestatus

Innvendig display

Automatisk opprop

RuterSalg

Eksternt skilt

TSP

Rutesatt Basis

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Rutesatt

x

x

x

x

x

x

x

x

x

x

x

x

x

x

Bestillingstransport Basis

x

x

x

x

x

x

x

x

Bestillingstransport

x

x

x

x

x

x

x

x

x

x

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
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 dataemnene til utarbeidelse av statistikk og innsikt. /di/assignment_attempt/block/oi/current_vehicle_journey/state /di/assignment_attempt_rejection/block /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. Xxxxxxx 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	Maksimal frekvens på posisjons-meldinger er 1/sekund 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.
Sensors	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	Maksimal frekvens på odometer-meldinger er 1/sekund 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.	Hvis et eller flere kriterier ikke er oppfylt.

		Oppdateringsfrekvens og trigger oppgis i dataemne /mi/provider_clients/<client_id>/provided_topics	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. Odometer skal ikke nullstilles eller gjøre «roll-over» i løpet av et Kjøreoppdrag (Block).
Sensors	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 Kvalitetsvviket 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.
Sensors	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 et eller flere kriterier ikke er oppfylt.
Sensors	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/01000002	Maksimal frekvens på kabintemperaturmeldinger er 2/min 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 temperatur-meldinger som overstiger 10 minutter regnes som et brudd i datastrømmen. Det tillates 2 brudd i løpet av en avgang.	Hvis et eller flere kriterier ikke er oppfylt.
Sensors	Normal	Utendørstemperatur Utendørs temperatur brukes for å forbedre prognose på avgangstider og kalibrering/analyse av passasjertellinger. /sensors/telemetry/01000009	Maksimal frekvens på utendørstemperatur er 2/min 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 temperatur-meldinger som overstiger 10 minutter regnes som et brudd i datastrømmen. Det tillates 2 brudd i løpet av en avgang.	Hvis et eller flere kriterier ikke er oppfylt.

Sensors / PE	Normal	Dørstatus Dørstatus brukes for å gi bedre sanntidsinformasjon, å styre trafikkprioritering samt å validere at passasjertellere fungerer. /sensors/door /pe/doors_individually	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.
Sensors	-	Stoppsignal Stoppsignal brukes for å gi bedre passasjerinformasjon ombord samt å forbedre fremdrifts-status på turer og vognløp. /sensors/stop_button	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.
Sensors	-	Vindusviskerstatus Vindusviskerstatus brukes for å forbedre prognose på avgangstider og kalibrering/analyse av passasjertellinger. /sensors/telemetry/01000007	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.
Sensors	Normal	Akselerometer Akselerometer brukes for å skape ny innsikt om generell kundekomfort, sikkerhet og veikvalitet. /sensors/telemetry/01000008	Maksimal frekvens for akselerometer-meldinger er 1/minutt. 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.
Sensors	Normal	Energiforbruk (kWh) Energiforbruk brukes til å samle miljø-innsikt om leveranse av rutetilbudet. /sensors/telemetry/0100000A	Maksimal frekvens for energiforbruk-meldinger er 1/minutt 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.
Sensors	Normal	Batterinivå (SOC, kun elbuss)	Maksimal frekvens for energiforbruk-meldinger er 1/minutt Gjennomsnittlig intervall mellom batterinivå-meldinger skal ikke overskride 2 minutter i løpet av en avgang.	Hvis et eller flere kriterier ikke er oppfylt.

		Batterinivå brukes for å samle operativ innsikt om bruk av el-busser i rutetilbudet. /sensors/telemetry/01000005	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.
Sensors	-	Ladestatus (kun elbuss) Ladestatus brukes for å gi bedre sanntidsinformasjon samt å samle operativ innsikt om bruk av el-busser i rutetilbudet. /sensors/telemetry/0001FF25 inkludert subid 10003, 10004 og 10005	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.
PE	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: 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.
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.
	-	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.

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.