Avtale om digitale tjenester 2.3
Avtale om digitale tjenester 2.3
Dette vedlegget et er kopi av avtalen som ligger på Ruters operatørportal. For best leseropplevelse anbefales det å benytte det publiserte dokumentet på operatørportalen.
Innledning
Overordnet
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 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.
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 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.
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/XxxxxxxxxxXXXXxxxxxxx e
NeTEx i henhold til
nordisk NeTEx profil: xxxxx://xxxxxxx.xxxxxxxxx.xxx/xxxx/xxxxxx/XXXXXX/xxxxx/000000000/Xxxxxxx NeTEx+Profile
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
Konsentra Førerapplikasjon
Tjenestemottaker publiseres oppdrag og kjørelister gjennom en forhåndsavtalt applikasjon. Fører registreres 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 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å xxxxx://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 grensenitt 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
Ved turens start initierer Tjensteyter 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. Dette inkluderer
• Kunde identifikator
• Bil/Løyvenummer
• Start adresse
• Start posisjon (lng/lat)
• Stopp adresse
• Stopp posisjon (lng/lat)
• Turtype
• Starttidspunkt
• Sluttidspunkt
• Ventetid
• Turdistanse
• Pris
• Kunde kost
• Sum
Merk: Spesifikasjoner for grensesnitt for kundeoppslag og turrapportering vil bli utarbeidet i løpet av høsten 2021. Grensesnittene vil være av typen REST
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- labeling/.
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.
Spesielle krav til Salg/billettering
Spesielle krav til Salg/billettering vedlikeholdes i et vedlegg til denne avtalen
Vedlegg – Xxxx Xxxx/Billettering
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
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 passasjeromådene.
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
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 Bestillingstransport: heltidsinnleid | Enkeltoppdrag innenfor kjøreoppdrag |
Avgang: | Bestillingstransport: timesinnleid | Se Kjøreoppdrag |
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 | Xxxxxxxxx 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 kjøreoppdrag (block), inngår tomkjøringen i kravet til ytelsesnivå for avgangen. Altså stilles samme ytelseskrav til tomkjøringer som til ruteavganger.
Kategori | Ytelsesnivå | Dataemne | Krav | Terskel for at avgangen skal merkes med SLA-brudd |
DI [MQTT) | 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 | 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 [MQTT) | 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-reckoning) for å gi posisjon. | Hvis et eller flere kriterier ikke er oppfylt. |
Sensors [MQTT) | Kritisk | Odometer Odometer brukes av Tjenestemottaker som en redundant løsning for posisjon der mottaksforholdene for posisjon er vanskelige eller satellittdekning ikke er tilgjengelig. /sensors/odometer Oppdateringsfrekvens og trigger oppgis i dataemne /mi/provider_clients/<client_id>/provided_topics | 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. 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). | Hvis et eller flere kriterier ikke er oppfylt. |
Sensors [MQTT) | Kritisk | Passasjertelling (APC) | 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. | Hvis et eller flere kriterier ikke er oppfylt. |
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> | Det tillates et avvik mellom av og påstigende i løpet av en avgang på 5% etter formelen Kvalitetsavviket 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. | |||
Sensors [MQTT) | 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 [MQTT) | 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 [MQTT) | 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 [MQTT) | 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 [MQTT) | - | 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 [MQTT) | - | 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 [MQTT) | 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 [MQTT) | 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 [MQTT) | Normal | Batterinivå (SOC, kun elbuss) Batterinivå brukes for å samle operativ innsikt om bruk av el-busser i rutetilbudet. /sensors/telemetry/01000005 | Maksimal frekvens for energiforbruk-meldinger er 1/minutt Gjennomsnittlig intervall mellom batterinivå-meldinger skal ikke overskride 2 minutter i løpet av en avgang. Gjennomsnittlig forsinkelse ved mottak av batterinivå -meldinger skal ikke overskride 5 sekunder i løpet av en avgang. Intervall mellom batterinivå -meldinger som overstiger 10 minutter regnes som et brudd i batterinivå-strømmen. Det tillates 2 brudd i løpet av en avgang. | Hvis et eller flere kriterier ikke er oppfylt. |
Sensors [MQTT) | - | Ladestatus 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 [MQTT) | Kritisk | Dynamisk passasjerinformasjon (DPI) Fremvisning av korrekt informasjon til passasjerene om bord er viktig for Tjenestemottaker Rådata /pe/dpi/# Diagnosedata /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 [MQTT) | Absolutt | Salg av billetter Salg av billetter er viktig for å gi inntektssikring for Tjenestemottaker /pe/sales_diag /pe/sales/# | 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/operatør 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 våre reisende 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. | |
PE | Absolutt | Oppdragsbekreftelse Konsentra førerapp | Tjenesteyter må bekrefte mottatt oppdrag gjennom avtalt applikasjon Fører registrerer faktisk hente- og leveringstid gjennom avtalt applikasjon | Hvis et eller flere kriterier ikke er oppfylt. |
PE | Absolutt | Oppdragsbekreftelse 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. |
PE | Absolutt | Oppdragsbekreftelse Y2M | Tjenesteyter utveksler data i henhold til grensesnitt beskrevet for funksjonsnivå Y2M | Hvis et eller flere kriterier ikke er oppfylt. |
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 nettverkskonnektivet mellom Tjenesteyter og Tjenestemottaker
• Velformethet for meldinger og rapporter både B2B, Turrapport 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 minimumsversjonen 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.