Dynamisk Passasjerinformasjon [3.1]

• Ingen endring fra 3.0

Spesielle krav til Dynamisk Passasjerinformasjon (DPI)

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

Krav til skjermer - bør flyttes til materialbeskrivelsen!

• Se: materiellbeskrivelsen

•  

• 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 ved plassering i landskapsmodus, og minimum 1920 piksler i høyden ved plassering i portrettmodus.

• Nytt krav:

  • Minimum tilgjengelig RAM skal være 4gb per skjerm

Krav til browser

• Se: https://adt.transhub.io/3.x/browser-requirements/

Krav til webserver / installasjon:

• se: https://adt.transhub.io/3.x/packages/

Krav til skjerm-konfigurasjon:

• Se: https://adt.transhub.io/3.x/screen-configs/

• 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

Oppdatering av statisk innhold - OBS! SKAL FLYTTES TIL https://adt.transhub.io/3.x/packages/

• DPI-applikasjonen skal holdes oppdatert når Tjenestemottaker 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.

• Tjenesteyter skal regelmessig sjekke om nye versjoner av DPIs nedlastbare pakker er tilgjengelige i Tjenestemottaker produksjons-kanal

• Når nye pakker er tilgjengelige skal Tjenesteyter 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

• Tjenesteyter 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 Tjenestemottakers innhold om bord på kjøretøyet

• Tjenesteyter 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 - OBS! Skal flyttes til AsyncAPI-doc under lydmelding

• Når kjøretøyet mottar en MQTT-melding med lydinnhold skal Tjenesteyter 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