Avtale om Digitale Tjenester v. 3.1
Avtale om Digitale Tjenester v. 3.1
Innledning
Overordnet Kontaktpunkt for avtalen
Beskrivelse av plattformen Funksjonsnivåer Sanntidsdata
Oppdrag og plandata
Plandata for rutesatte turer og vognløp Oppdrag for bestillingstransport
Tjenestemottakers Førerapplikasjon
SUTI
Y2M (tjenesteYter2tjenesteMottaker) Ruterlogg
Krav til løsninger
Spesielle krav til Salg/billettering
Spesielle krav til kortlesere for validering av reiserett Spesielle krav til Dynamisk Passasjerinformasjon (DPI) Spesielle krav til MQTT
Spesielle krav til lydsignal ved utløsning av stoppknapp Spesielle krav til passasjertelling (APT)
Ytelseskrav til funksjonsnivåer Generelle krav
Ytelsesnivåer
Beregning av datakvalitet Begreper
Hvilke avganger måles Måleperiode
Måling av assignment-tjenesten Datakvalitet for en måleperiode Datakvalitet for en avgang
Ytelseskrav
Godkjenning av dataprodusenter SIT (Site Integration Test)
CAT (Customer Acceptance Test) VV (Vehicle Verification)
Versjons- og livsløpshåndtering Versjonshåndtering
Minor versjon Major versjon
Livsløpshåndtering Oppstart av ny leveranse
Endringsbestemmelse for avtalen Sanksjoner
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 (ADT) er gjenstand for oppgraderinger i livsløpet til avtalen i henhold til et eget versjonshåndteringsregime. 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:
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 (blokks) 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.
Traffic plan - Ruters Digitale Plattform
API for den operative plandatabasen:
Identifikatorer for blokk, 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: Nordic SIRI Profile NeTEx i henhold til nordisk NeTEx profil: Nordic NeTEx Profile
Oppdrag for bestillingstransport
For funksjonskategoriene i bestillingstransport finnes det forskjellige måter å formidle data og oppdrag på. Funksjonsmatrisen beskriver de forskjellige varianter som er gyldige for hvilken type bestillingstransport.
Tjenestemottakers Førerapplikasjon
Tjenestemottaker publiserer 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å
SUTI selvdeklarasjon:
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 avtalt 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.
Digital TT Card / Y2M-Interface description
Ruterlogg
Ruterlogg er oppdragsgivers system for logging av trafikkhendelser og avvik. Tjenesteyter vil få tilgang til et API for maskinell registrering av hendelser.
Kvalitetsproblemer som skyldes forhold utenfor tjenesteyters kontroll unntas gebyr dersom det registreres korrekt i Ruterlogg. Eksempler på slike forhold kan være at hele mobilnettet faller ut eller feil som skyldes tjenestemottaker. Forhold som må anses som normale gir ikke unntak for gebyr, f.eks. problemer med operatørens IT-utstyr eller dårlig mobildekning på visse geografiske områder. Slike forhold er innarbeidet i ytelseskravene.
Hendelser der operatør påberoper seg fritak for gebyr skal logges korrekt i Ruterlogg slik at det kan behandles maskinelt av Tjenestemottaker. Dette er obligatorisk for operatørene i kategori “Rutesatt transport” men valgfritt for operatørene i kategori “Bestillingstransport”.
Dette gjelder:
Innstilte avganger Forsinkelser
Brudd på datakvalitet
Ruterlogg API: Traffic Event Reporting API
Krav til løsninger
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 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 5.0 er støttet av Tjenestemottaker for ADT 3. 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 Xxxxxx skal konfigureres med støtte meldingsstørrelser opp til 4096 kB
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 |
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 for veigående materiell og normale kvalitetsrutiner. Kravene skal baseres på Tjenestemottakers erfaringer fra innsamling av lignende 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.
Kravene brukes til økonomiske incitamenter som skal belønne forbedringer av datakvaliteten.
Ytelseskravene skal evalueres minst årlig og justeres dersom de ikke fungerer etter intensjonen, så lenge justeringen er i tråd med uttalt intensjon.
Generelle krav
Alle dataemner beskrevet i APIet skal produseres av respektive Tjenesteyter (PUB) eller Tjenestemottaker (SUB) dersom annet ikke er oppgitt. Tjenesteyter plikter å produsere alle dataemner, korrekt utfylt, merket med PUB.
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 3 ytelsesnivåer som kan benyttes til å regulere insentiver.
Intensjonen med ytelsesnivåene er å insentivere tjenesteyter til å fokusere på de viktigste dataemnene først, siden dataemnene på nivåene under har liten eller ingen verdi uten data på nivåene over.
Beregning av datakvalitet
Begreper
En blokk er en del av et vognløp. Den består av flere avganger og går som regel fra garasje til garasje. Blokkene og vognløpene defineres av operatørene i planleggingsfasen.
Hvilke avganger måles
Operatøren definerer hvilke avganger den har som intensjon å betjene i signon-meldingen under “service-vinduet”. Det er disse avgangene som måles.
Eksempler
Dersom denne intensjonen senere endrer seg skal det sendes en oppdateringsmelding, som igjen endrer hvilke turer som blir målt.
Måleperiode
Mottak av signon definerer starten av en måleperiode. Mottak av signoff definerer slutten av måleperioden.
Hele måleperioden har samme ytelseskrav. Det er flere grunner til det:
Tidspunktene for når en ruteavgang faktisk begynte og sluttet beregnes basert på innsamlede data, slik at å basere målingene på dette vil være kompliserende.
Data både før og etter ruteavgangene viktige for å kunne gi god kundeopplevelse og følge opp produksjonen.
Tjenestemottaker vil tilstrebe at ytelsen bare måles der det er relevant og at ytelseskravene for de ulike dataemnene tar høyde for operativt arbeid mellom ruteavganger.
Eksempel
Hvis signoff ikke sendes slutter måleperioden 2 timer etter planlagt ankomst på siste holdeplass i intensjonen som er definert av service- vinduet:
Måling av assignment-tjenesten
Se ytelseskravene i tabellen under.
Eksempler
Xxxxxx er mottatt under 20 minutter etter avgang fra første avgang og signoff er mottatt under 2 timer etter ankomst siste avgang. Alle avgangene er godkjent.
Xxxxxx som sendes mer enn 20 minutter etter planlagt avgang i turen godkjennes ikke.
Xxxxxx som sendes etter dette godkjennes ikke turene som er sendt for sent.
Måleperiodene brukes for å definere når de andre tjenestene måles. De måles over hele perioden og gjelder for alle turene definert av service-vinduet.
Datakvalitet for en måleperiode
Datakvaliteten beregnes til mellom 0 og 1 som følger:
Dersom ytelsesnivå 1 ikke er godkjent → 0 poeng
Dersom ytelsesnivå 1 er godkjent går man videre til neste ytelsesnivå.
Dersom ytelsesnivå 2 ikke er godkjent → 0,5 poeng
Dersom ytelsesnivå 2 er godkjent: 0,5 poeng + poengene for neste ytelsesnivå.
Dataemnene på ytelsesnivå 3 har ulik vekting, og poengene oppsummeres som følger: Godkjent DPI gir 0,25 poeng
Godkjent Rutersalg gir 0,10 poeng Godkjent APC gir 0,05 poeng
Resterende dataemner gir: antall godkjente dataemner / antall dataemner * 0,1 poeng Ikke målte dataemner teller som godkjent.
Eksempler
Ytelsesnivå 1 | Ytelsesnivå 2 | Ytelsesnivå 3 | Poeng |
Pålogging og avlogging: Ikke godkjent | Teller ikke. | Teller ikke. | 0 |
Pålogging og avlogging: Godkjent | Posisjon: Ikke godkjent. | Teller ikke. | 0,5 |
Pålogging og avlogging: Godkjent | Posisjon: Godkjent | DPI: Ikke godkjent. Ingen andre dataemner målt. | 0,5 + 0,10 + 0,05 + 0,025 = 0,675 |
Pålogging og avlogging: Godkjent | Posisjon: Godkjent | DPI: Godkjent Rutersalg: Godkjent APC: Ikke godkjent Resterende dataemner: 1 godkjent, 3 ikke godkjent, 10 ikke målt. | 0,5 + 0,25 + 0,10 + 11/14 * 0,1 = 0,928 |
Datakvalitet for en avgang
Avgangen får samme datakvalitet som måleperioden den er en del av.
Dersom flere måleperioder er registrert på samme avgang vil den beste telle. Dette kan f.eks. skje hvis mer enn 1 kjøretøy betjente samme avgang.
Konsekvensene for brudd og eller overoppnåelse av ytelseskrav er definert i transporttjenestekontrakt operatøren har inngått med Ruter.
Ytelseskrav
Ytelsesnivå | Dataemne | Intensjon | Ytelseskrav | Beregning av datakvalitet |
1 | 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. | Pålogging Pålogging skal sendes senest 5 minutter før kjøretøyet starter på en avgang. For første avgang i blokken ønsker vi dette senest ved utkjøring fra depot. Pålogging skal sendes så snart et kjøretøy skal overta for et annet på samme blokk. Det skal sendes ny pålogging for hver blokk hvis det er flere blokker i vognløpet. Det skal ikke sendes pålogginger utover dette. Avlogging Avlogging skal sendes når et kjøretøy ikke lenger skal betjene avgangene det er logget inn på. Oppdatering Oppdatering skal sendes når et kjøretøy kun skal betjene deler av avgangene det er logget inn på. Unnlatelse | Gyldige meldinger Pålogging og avlogging skal bruke korrekte referanser som er definert i Ruters operasjonelle plandatabase. Pålogging skal angi en gyldig API versjon. Denne API versjonen skal brukes i all kommunikasjon med kjøretøyet. Pålogging skal være mottatt: Senest 20 minutter etter planlagt avgang fra første holdeplass. Avlogging skal være mottatt: Senest 2 timer etter planlagt ankomst på siste holdeplass. Ved bytte av kjøretøy i en blokk skal eksisterende kjøretøy sende avlogging. Nytt kjøretøy sender ny pålogging før det starter på kjøreoppdraget. Dersom det nye kjøretøyet sender pålogging av type REPLACEMENT vil det gamle kjøretøyet logges ut. Dette teller som en godkjent avlogging. | En avgang blir godkjent hvis og bare hvis den har korrekt pålogging og avlogging. |
Hvis operatøren av ulike grunner ikke kan gjennomføre, eller planlegger å sløyfe en tur, skal turen ikke tildeles et kjøretøy, men registreres som utelatt. Unnlatelse skal sendes så snart operatøren planlegger å sløyfe en tur. | ||||
1 | Oppdragsutveksling Ruter Førerapp | Fører benytter førerapplikasjon i henhold til avtalt prosedyre. | Godkjent dersom alle krav er godkjent. | |
1 | 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. | Godkjent dersom alle krav er godkjent. | |
1 | Oppdragsrapportering Y2M | Tjenesteyter utveksler data i henhold til grensesnitt beskrevet for funksjonsnivå Y2M. | Godkjent dersom alle krav er godkjent. | |
2 | 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, både om bord i kjøretøyet, men også i andre kundekanaler. Fremdrifts-status er også viktig for å kunne utarbeide statistikk og innsikt om avviklingen av Tjenestemottakers tjenester. | Posisjon skal konfigureres opp til å sende 1 gang/sekundet med beste kvalitet under rådende forhold. For å ta høyde for dårlig mobildekning tillater vi noe datatap. For å ta høyde for at meldingen sendes over mqtt med QoS=0 telles ikke kortere brudd i datastrømmen. For å ta høyde for at strøm blir skrudd av mellom passasjerturer, feks. ved en pause ignoreres brudd som skjer der kjøretøyet sto stille. Da kan også messageNumber resettes til 0. Brudd i datastrømmen der kjøretøyet stod stille ignoreres. | messageNumber skal øke med 1 for hver sendte melding. Hvis messageNumber ikke øker regnes ikke meldingen som korrekt mottatt. To påfølgende meldinger skal mottas med et intervall på 0,9 - 3,5 sekunder. I praksis at 2 meldinger kan falle bort under sending. For intervall større enn 3,5 sekunder regnes 1 melding som ikke korrekt mottatt per påbegynte sekund det mangler posisjoner etter 3,5 sekunder. Brudd i datastrømmen der odometer viser at kjøretøyet flyttet seg mindre enn 10 meter ignoreres. Dette gjelder også for messageNumber. 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å GPS-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 | Godkjent dersom >95% av alle posisjoner er korrekt mottatt. |
3 | Dynamisk passasjerinformasjon (destinasjon, journey, neste stopp, lydmelding) Fremvisning av korrekt informasjon til passasjerene om bord er viktig for Tjenestemottaker. | Verifiser at: Utstyret har strøm All software er oppdatert til riktig versjon, konfigurert og kjører korrekt Sending og mottak av data fungerer som det skal | Eksternt skilt Valider at vi får kvitteringsmelding tilbake fra operatør på: ExternalDisplay Operatør er pliktig til å sende en kvitteringsmelding fra kjøretøyet så raskt meldingen har blitt mottatt. Kvitteringer etter 60 sek forkastes. Beregnes fra eventTimestamp i original melding. kvitteringen skal inneholde referanse til TraceId og tidsstempel fra opprinnelig melding Opprop Valider at vi får kvitteringsmelding tilbake fra operatør på: AudioMessage Operatør er pliktig til å sende en kvitteringsmelding fra kjøretøyet så raskt meldingen har blitt mottatt. Kvitteringer etter 60 sek forkastes. Beregnes fra eventTimestamp i original melding. kvitteringen skal inneholde referanse til TraceId og tidsstempel fra opprinnelig melding Innvendige skjermer Underveis på reise Valider at vi får kvitteringsmelding tilbake fra hver enkelt skjerm på: Journey NextStop Ruter skal motta: kvitteringsmeldinger fra hver enkelt skjerm | Hver gang Tjenestemottaker sender Journey, NextStop eller ExternalDisplay skal vi motta kvitteringsmelding fra hver skjerm om at meldingen er mottatt. Godkjent dersom Ruter har mottatt kvittering for minst 97% av sendte meldinger. |
Kvitteringer etter 60 sek forkastes. Beregnes fra eventTimestamp i original melding. DPI-klienten er ansvarlig for å produsere kvitteringsmeldingen. Ved oppstart / power on Verifiser at følgende er korrekt: Browserversjon Persistens / lagringsmuligheter Korrekte software-versjoner ombord på kjøretøy: DPI-klient Mediapakkeversjon Ressurspakkeversjon Riktig skjermvisning (url) Tilgang til internett DPI-klienten er ansvarlig for å rapportere disse dataene ved oppstart. Operatør er ansvarlig for å synce filer, overvåke nettverk / hardware, overvåke browser fungerer osv. | ||||
3 | Salg av billetter Salg av billetter er viktig for å gi inntektssikring for Tjenestemottaker | Sjåføren skal være pålogget på alle stoppesteder gjennom hele avgangen, f.o.m. første holdeplass t.o.m. siste. | På hver holdeplass/stoppested måler RuterSalg-diagnosemodulen at følgende krav er oppfylt: At sjåfør/operatør av billettsalget er pålogget | Godkjent dersom minst 95% av målte stoppesteder er godkjent. |
3 | 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 tjeneste APC-melding må sendes pr. dør til Tjenestemottaker etter at dørstatus har blitt endret fra anyDoorOpen til allDoorsClosed. Melding må mottas maksimalt 30 sekunder etter endring av dørstatus. For beregning av tjeneste tillates det avviket som gir færrest manglende meldinger i løpet av en måleperiode. Det tillates enten inntil tre (3) manglende meldinger pr. måleperiode eller melding fra 90% av betjente holdeplasser med dørlukking. APC presisjon Presisjon mellom avstigende og påstigende måles per måleperiode. Hvis en måleperiode ikke tilfredsstiller kravet til presisjon, regnes presisjonen som underkjent for alle avganger i måleperioden. Avviket må være mindre enn ti (10) personer, eller 10 % etter formelen for prosentvis avvik: absolutt(påstigende-avstigende) / ((påstigende+avstigende)/2) For beregning av presisjon tillates det avviket som gir minst tellefeil i løpet av en måleperiode. | Godkjent dersom alle krav er godkjent. | |
3 | 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. Å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. måleperiode. Se for øvrig krav til Passasjertelling. | Godkjent dersom alle krav er godkjent. | |
3 | 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. | Godkjent dersom alle krav er godkjent. | |
3 | Validering/aktivering av reiserett Xxxxxxxxxx av reisrett bidrar til Tjenestemottakers inntektssikring | Det skal være mulig å validere reiseretter, og eventuelt ha enkel dialog med kunden, på alle stoppesteder gjennom hele avgangen, f.o.m. første holdeplass t.o.m. siste. | (Spesifiseres senere i.h.t. intensjonen.) | (Spesifiseres senere i.h.t. intensjonen.) |
3 | Odometer Odometer brukes av Tjenestemottaker som en redundant løsning for posisjon | Odometer skal konfigureres opp til å sende 1 gang/sekundet, med høyeste oppløsning gitt av sensoren. | messageNumber skal øke med 1 for hver sendte melding. Hvis messageNumber ikke øker regnes ikke meldingen som korrekt mottatt. | Godkjent dersom >95% av alle odometer-meldinger er korrekt mottatt og det ikke gjøres en «roll- |
der mottaksforholdene for posisjon er vanskelige eller satellittdekning ikke er tilgjengelig. | For å ta høyde for dårlig mobildekning tillater vi noe datatap. For å ta høyde for at meldingen sendes over mqtt med QoS=0 telles ikke kortere brudd i datastrømmen. For å ta høyde for at strøm blir skrudd av mellom passasjerturer, feks. ved en pause ignoreres brudd som skjer der kjøretøyet sto stille. Da kan også messageNumber resettes til 0. Odometerverdien skal reflektere kjøretøyets totale kilometerstand der det er mulig. Brudd i datastrømmen der kjøretøyet stod stille ignoreres. | To påfølgende meldinger skal mottas med et intervall på 0,9 - 3,5 sekunder. I praksis at 2 meldinger faller bort under sending. For intervall større enn 3,5 sekunder regnes 1 melding som ikke korrekt mottatt per påbegynte sekund det mangler posisjoner etter 3,5 sekunder. Brudd i datastrømmen der odometer viser at kjøretøyet flyttet seg mindre enn 10 meter ignoreres. Dette gjelder også for messageNumber. Odometerverdien skal ikke nullstilles eller gjøre «roll-over» i løpet av en måleperiode. | over» av odometerverdien i løpet av måleperioden. | |
3 | Innetemperatur / Kabintemperatur Innetemperatur kan brukes for å forbedre kundeopplevelse gjennom forbedret etterlevelse av krav til temperatur og mulighet for bedre forvaltning og styring av materiell. Innetemperatur kan også benyttes til bedre informasjon til reisende. | Temperaturmålinger skal skje regelmessig og sendes hvert 10. sekund, med ett målepunkt per sensor. Brudd i datastrømmen der kjøretøyet stod stille ignoreres. | Gjennomsnittlig intervall mellom temperaturmeldinger per sensor skal være innenfor et toleransevindu på 8-12 sekunder i løpet av en måleperiode. Intervall mellom temperaturmeldinger på mellom 12 - 60 sekunder regnes som 1 brudd i datastrømmen. Det tillates 3 brudd i løpet av en avgang. Eks: Et intervall på 3 minutter og 11 sekunder regnes som 3 brudd i datastrømmen. Eks: Et intervall på 3 minutter og 12 sekunder regnes som 4 brudd og er ikke godkjent. Brudd i datastrømmen der odometer viser at kjøretøyet flyttet seg mindre enn 10 meter ignoreres. | Godkjent dersom alle krav er godkjent. |
3 | Utendørstemperatur Utendørstemperatur kan brukes for å forbedre prognose på avgangstider og kalibrering/analyse av passasjertellinger. Utendørstemperatur kan også brukes til å følge opp krav til inneklima. | Temperaturmålinger skal skje regelmessig og sendes hvert 60. sekund. Brudd i datastrømmen der kjøretøyet stod stille ignoreres. | Gjennomsnittlig intervall mellom temperaturmeldinger skal være innenfor et toleransevindu på 55-65 sekunder i løpet av en måleperiode. Intervall mellom temperaturmeldinger på mellom 65 - 120 sekunder regnes som 1 brudd i datastrømmen. Det tillates 3 brudd i løpet av en avgang. Eks: Et intervall på 7 minutter og 4 sekunder (120+120+120+64 sekunder) regnes som 3 brudd i datastrømmen. Eks: Et intervall på 7 minutter og 5 sekunder (120+120+120+65 sekunder) regnes som 4 brudd og er ikke godkjent. Brudd i datastrømmen der odometer viser at kjøretøyet flyttet seg mindre enn 10 meter ignoreres. | Godkjent dersom alle krav er godkjent. |
3 | Vindusviskerstatus Vindusviskerstatus brukes for å forbedre prognose på avgangstider og kalibrering/analyse av passasjertellinger. | Sendes ved hver tilstandsendring av vindusviskerfunksjon. Brudd i datastrømmen der kjøretøyet stod stille ignoreres. | Sendes ved hver tilstandsendring av vindusviskerfunksjon. Brudd i datastrømmen der odometer viser at kjøretøyet flyttet seg mindre enn 10 meter ignoreres. | Godkjent dersom alle krav er godkjent. |
3 | Akselerometer Akselerometer kan brukes for å skape ny innsikt om generell kundeopplevelse, sikkerhet og veikvalitet. Det kan også brukes til å bedre følge opp kundehenvendelser. | Akselerometermeldinger skal sendes regelmessig og hvert 10. sekund. Brudd i datastrømmen der kjøretøyet stod stille ignoreres. | Gjennomsnittlig intervall mellom meldinger fra akselerometer skal være innenfor et toleransevindu på 8-12 sekunder i løpet av en måleperiode. Intervall på mellom 12 - 60 sekunder regnes som 1 brudd i datastrømmen. Det tillates 3 brudd i løpet av en avgang. Eks: Et intervall på 3 minutter og 11 sekunder regnes som 3 brudd i datastrømmen. Eks: Et intervall på 3 minutter og 12 sekunder regnes som 4 brudd og er ikke godkjent. Brudd i datastrømmen der odometer viser at kjøretøyet flyttet seg mindre enn 10 meter ignoreres. | Godkjent dersom alle krav er godkjent. |
3 | Energiforbruk (kWh) Energiforbruk kan brukes til å samle innsikt om materiellet til ruteplanlegging og for etterlevelse av miljø- og bærekraftsmål. | Energiforbruket skal sendes regelmessig og hvert 60. sekund. Brudd i datastrømmen der kjøretøyet stod stille ignoreres. | Gjennomsnittlig intervall mellom meldinger på energiforbruket skal være innenfor et toleransevindu på 55-65 sekunder i løpet av en måleperiode. Intervall på mellom 65 - 120 sekunder regnes som 1 brudd i datastrømmen. Det tillates 3 brudd i løpet av en avgang. Eks: Et intervall på 7 minutter og 4 sekunder (120+120+120+64 sekunder) regnes som 3 brudd i datastrømmen. Eks: Et intervall på 7 minutter og 5 sekunder (120+120+120+65 sekunder) regnes som 4 brudd og er ikke godkjent. | Godkjent dersom alle krav er godkjent. |
Brudd i datastrømmen der odometer viser at kjøretøyet flyttet seg mindre enn 10 meter ignoreres. | ||||
3 | Batterinivå (SOC, kun elbuss) Batterinivå brukes for å samle innsikt om bruk av el-busser i rutetilbudet. | Batterinivå skal sendes regelmessig og hvert 60. sekund. Brudd i datastrømmen der kjøretøyet stod stille ignoreres. | Gjennomsnittlig intervall mellom meldinger på batterinivå skal være innenfor et toleransevindu på 55-65 sekunder i løpet av en måleperiode. Intervall på mellom 65 - 120 sekunder regnes som 1 brudd i datastrømmen. Det tillates 3 brudd i løpet av en avgang. Eks: Et intervall på 7 minutter og 4 sekunder (120+120+120+64 sekunder) regnes som 3 brudd i datastrømmen. Eks: Et intervall på 7 minutter og 5 sekunder (120+120+120+65 sekunder) regnes som 4 brudd og er ikke godkjent. Brudd i datastrømmen der odometer viser at kjøretøyet flyttet seg mindre enn 10 meter ignoreres. | Godkjent dersom alle krav er godkjent. |
3 | Ladestatus (kun elbuss) Ladestatus brukes for å gi bedre sanntidsinformasjon samt å samle innsikt om bruk av el-busser i rutetilbudet. | Sendes ved hver tilstandsendring av ladning. Brudd i datastrømmen der kjøretøyet stod stille ignoreres. | Sendes ved hver tilstandsendring av ladning Brudd i datastrømmen der odometer viser at kjøretøyet flyttet seg mindre enn 10 meter ignoreres. | Godkjent dersom alle krav er godkjent. |
- | 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. |
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.
Tjenesteyter er forpliktet til å sørge for at nødvendige data om kjøretøy til enhver tid er registrert og korrekt i Oppdragsgivers kjøretøydatabase; FRIDA. Registering i XXXXX er en forutsetning for at kjøretøyene er synlige i onlineskjema for VV.
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
Betingelsene i ADT gjelder fra kontraktinngåelse. Ved oppstart av ny leveranseavtale hvor det er spesifisert at denne avtalen kommer til anvendelse skal Tjenesteyter levere på nyeste versjon.
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 (Blokk) | 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. |