Joukkoliikenteen kansallinen ennusterajapinta

Transkriptio

1 ÄLLI-julkaisuja 9/2009 Joukkoliikenteen kansallinen ennusterajapinta Vaatimusmäärittely v. 1.0

2 ÄLLI-julkaisuja Helsinki 2009

3 SISÄLTÖ KÄSITTEITÄ YLEISKUVAUS TEHDYT SELVITYKSET Toimijoiden tahtotila Mahdollisia käyttötapauksia Pysäkeillä ja asemilla olevat näyttötaulut Matkustajien näyttötaulut liikennevälineissä Kuljettajamonitorit Kuulutusten ohjaus asemilla Kuulutusten ohjaus liikennevälineissä Taattujen vaihtojen hallinta Ennustetietojen visualisointi kartalla ohjauskeskuksissa Teknisiä toteutustapavaihtoehtoja Standardin hyödyntäminen Toteutus web-palveluna XML + HTTP -tapa XML + TCP -tapa Ulkomaisia rajapintastandardeja SIRI VDV453/ RTIG-XML ASETETTAVAT VAATIMUKSET JA RAJAUKSET Yleiset vaatimukset Käyttötapauksiin liittyvät vaatimukset Toiminnalliset vaatimukset Tekniset vaatimukset Asetettavia rajauksia SUOSITUKSIA Koordinointiryhmä Tukisivusto Referenssitoteutus Käytettävä viitekehys Paikannusarkkitehtuurin kehitystarpeet...16 LIITE 1: HAASTATTELUISSA ESILLE TULLEET ASIAT...18 LÄHDELUETTELO

4 KÄSITTEITÄ IFOPT ITS XML Identification of fixed objects in public transport. Joukkoliikenteen käsitteitä ja niiden suhteita määrittelevä standardi (CEN-standardi). Intelligent Transport Systems and Services. Extensible Markup Language. Rakenteinen tiedonsiirto formaatti. SIRI Service Interface for Real Time Information. Reealiaikarajapintoja standardoiva eurooppalainen organisaatio. ESB SOA WSDL SOAP Dispatchaus Enterprise Service Bus. Palveluväylään perustuva ITarkkitehtuuri, kts. myös SOA. Service Oriented Architecture. Yrityksen IT-arkkitehtuuri, jossa tietojärjestelmät nähdään tietoja tarjoavina palveluina. Web Service Description Language. Kuvauskieli, jota käytetään web-palvelujen rajapintojen kuvaamiseen. Web-palveluiden oletusprotokolla, joka toimii HTTPprotokollan päällä. Liikennetuotannon ajosarjojen reaaliaikainen seuranta, ohjaus ja muutoksiin reagointi. Kyselytyyppi Tarkoittaa samaa asiaa kuin rajapintafunktio tai rajapintametodi. CEN European Committee for Standardization. Eurooppalainen standardointiorganisaatio. RTIG Real Time Interest Group. Reaaliaikastandardeihin keskittynyt organisaatio. TRANSMODEL VDV Julkisen liikenteen abstrakti tietomalli (CEN-standardi). Verband Deutscher Verkehrsunternehmen. Saksalainen julkisen liikenteen ja rahtiliikenteen toimijoiden liitto. 4

5 1 YLEISKUVAUS Tässä dokumentissa on tehty alustava vaatimusmäärittely kansallisen ennustepalvelimen käyttäjärajapinnasta. Tämän dokumentin pohjalta on laadittu myöhemmin rajapinnan tekninen määrittely, joka löytyy dokumentista ennusterajapinta_tekninenmäärittely.pdf. Ennustepalvelimella tarkoitetaan järjestelmää, jonka tarkoitus on tuottaa reaaliaikatietojen pohjalta ennusteita joukkoliikennevälineiden liikkeistä muille liikenteen järjestelmille. Järjestelmän tärkein tunnistettu käyttötapaus on tuottaa saapumisaikaennusteita pysäkeillä ja asemilla olevia näyttötauluja varten. Tämä työ on tehty Tiehallinnon koordinoiman Älli-ohjelman puitteissa ja liikenne- ja viestintäministeriön toimeksiannosta. Hanketta oli ohjaamassa ministeriön lisäksi HSL (YTV liikenne ja HKL suunnittelu) ja Tampereen kaupunki. Työ täydentää osaltaan valmistunutta Kansallinen joukkoliikenteen paikannusarkkitehtuuri -hanketta, jossa määriteltiin paikannuspalvelimen rajapinnat. Ennustepalvelimen toteutuksista vastaavat joukkoliikennetoimijat ja näin ollen toteutuksia tulee siis olemaan useita. Toimijat toteuttavat ennustepalvelinjärjestelmät itsenäisesti siten, että järjestelmien rajapinnat ovat yhteneviä määritellyn rajapinnan teknisen määrittelyn kanssa. Joukkoliikennetoimijoista ennusterajapinnan tulevat toteuttamaan todennäköisesti ainakin tuleva HSL, RHK ja Tampereen Kaupunki. Tämä vaatimusmäärittely on tehty joukkoliikennetoimijoiden toiveiden pohjalta, joita on selvitetty haastatteluin ja workshopin avulla. Vaatimusmäärittelyä varten on lisäksi selvitetty kansainvälisiä standardeja, joita voitaisiin hyödyntää rajapinnan suunnittelussa. Tämän dokumentin perusteella tehdyssä teknisessä määrittelyssä on kuvattu tarkemmin rajapinnan toimintaperiaate, käytettävät sanomatyypit ja muut toteutuksen kannalta olennaiset asiat.

6 2 TEHDYT SELVITYKSET Tässä luvussa on koottu yhteen vaatimusmäärittelyä varten tehtyjen selvitysten tuloksia. 2.1 Toimijoiden tahtotila Joukkoliikennetoimijoiden ja muiden osapuolien tahtotilaa selvitettiin tässä määrittelyssä haastatteluiden ja projektin aikana järjestetyn ennusterajapintatyöpajan avulla. Työssä haastateltiin seuraavia organisaatioita: HKL, YTV, VR, RHK, Koiviston Auto, Matkahuolto, Turun kaupunki, Tampereen kaupunki ja Oulun kaupunki. Lisäksi haastateltiin Liikenne- ja viestintäministeriötä sekä Seasam House Ky, AB Thureb ja Trim-softa Oy yrityksiä. Projektin aikana järjestettiin myös kaikille sidosryhmille avoin ennusterajapintatyöpaja, johon osallistui 15 henkilöä eri organisaatioista ja yrityksistä. Liitteessä 1 olevaan taulukkoon on kirjattu haastatteluissa ja workshopissa (ks. Lähdeluettelo: Haastattelut ja kuulemistilaisuudet) esille tulleita asioita, ideoita ja mielipiteitä. Asiat on numeroitu, jotta niihin voi myöhemmin yksiselitteisesti viitata. Taulukkoon on myös kommentoitu jokaista kohtaa lyhyesti. Ennusterajapintaan viitataan taulukossa lyhenteellä RP. Taulukkoon kirjattuja toiveita ja tarpeita on pyritty huomioimaan tehdyssä teknisessä määrittelyssä siinä määrin missä mahdollista. Hankkeen tilaajaorganisaatioiden toiveita on määrittelyssä huomioitu suuremmalla painoarvolla kuin muiden osapuolien toiveita. 2.2 Mahdollisia käyttötapauksia Tässä kappaleeseen on koottu esiin tulleita käyttötapauksia ja tilanteita, joissa ennusterajapintaa voitaisiin hyödyntää. Kussakin käyttötapauksissa on pohdittu myös, minkälaista tiedonvälitystä siihen liittyy Pysäkeillä ja asemilla olevat näyttötaulut Tässä käyttötapauksessa ennusterajapintaa hyödyntävät pysäkeillä ja asemilla olevat näyttötaulut, jotka näyttävät matkustajille arvioituja saapumisaikoja liikennevälineistä. Tämä tapaus on tunnistetuista käyttötapauksista selvästi kaikista tärkein. Tässä tapauksessa ennustepalvelimen rooli olisi toimia taustajärjestelmänä, joka välittäisi ennustetiedot näyttötauluja ohjaaville ohjausjärjestelmille, ja jotka edelleen välittäisivät tiedot itse näyttötauluille. Näyttötauluille voitaisiin välittää ennusterajapinnasta ohitusaikojen lisäksi myös häiriötiedotteita. Kuvassa 1 on esitetty tapauksessa välitettäviä tärkeimpiä tietoja. 6

7 Ao. pysäkin kautta kulkevat linjat Linjojen arvioidut lähtöajat Linjojen arvioidut saapumisajat Linjojen käyttämät raiteet/laiturit Linjojen määränpääpysäkit ja välipisteet Kuva 1: Pysäkeillä ja asemilla sijaitseville näyttötauluille välitettävät tiedot Matkustajien näyttötaulut liikennevälineissä Tässä käyttötapauksessa ennusterajapintaa käyttäisivät liikennevälineissä olevat näyttötaulut, jotka näyttävät matkustajalle käynnissä olevan matkan edistymiseen liittyviä tietoja. Lisäksi näytöillä voitaisiin näyttää esim. tiedot siitä ajaako liikenneväline myöhässä aikataulusta ja mitkä ovat seuraavan pysäkin vaihtomahdollisuudet (+ vaihtojen arvioidut toteutumisajat). Ennustepalvelin välittäisi tässäkin tapauksessa tiedot vain näyttöjen ohjausjärjestelmälle, eikä itse näytöille. Kuvassa 2 on esitetty, mitä tietoja olisi näytöille syytä pystyä välittämään. Ao. linjan tunnus Ao. ajoneuvon tunnus Seuraava pysäkki ja sen pysäkkikoodi Sitä seuraavat pysäkit ja niiden pysäkkikoodit Ajaako myöhässä (viivetieto) nopeus Häiriötiedotteet ja niiden aiheuttamat viiveet minuutteina Vaihtomahdollisuudet seuraavalla pysäkillä ja niiden arvioidut toteutumisajat 7

8 Kuva 2: Liikennevälineissä oleville näyttötauluille välitettävät tiedot Kuljettajamonitorit Monissa busseissa on kuljettajamonitoreita, joiden kautta kuljettajille voidaan välittää tietoja ja ohjeita. Ennustepalvelimelta näihin monitoreihin voitaisiin välittää esim. tieto siitä ajaako kuljettaja myöhässä/edellä aikataulua tai siitä kuinka monen minuutin päässä ajaa seuraava/edellinen saman linjan liikenneväline. Kuvassa 3 havainnollistaa tätä tilannetta. Ajaako myöhässä/ edellä aikataulua Monenko minuutin päässä seuraava/ edellinen vuoro Häiriötiedotteet ja niiden aiheuttamat viiveet minuutteina Kuva 3: Kuljettajamonitorille välitettävät tiedot Kuulutusten ohjaus asemilla Tämä käyttötapaus liittyy pääosin junaliikenteeseen. Käyttötapauksessa ennusterajapintaa voitaisiin hyödyntää antamaan automaattinen kuulutus asemaa lähestyvästä junasta tai myöhästyvästä junista. Ennustepalvelin voisi väittää kuulutuksia ohjaavalle järjestelmälle automaattisen myöhästymisilmoituksen esim. kun se arvioi junan saapuvan 5 minuuttia myöhässä aikataulusta. Tätä käyttötapausta voitaisiin soveltaa myös mahdollisesti bussiterminaaleissa ja lentoasemilla. Kuulutuksien välityksessä tarvittavia tietoja: junan tunnus lähtöpaikka raide/laituri jolle saapuu arvioitu saapumisaika arvioitu myöhästymisaika 8

9 2.2.5 Kuulutusten ohjaus liikennevälineissä Tämä käyttötapaus on periaatteessa sama kuin edellinen, mutta automaattiset kuulutukset annettaisiin junassa. Tapauksessa junamatkustajille halutaan välittää tieto siitä milloin junan arvioidaan saapuvan asemalle tai jos se saapuu myöhässä. Ennusterajapinnan tietoja voitaisiin myös käyttää seuraavien asemien kuuluttamiseen. Junakuulutuksien välityksessä tarvittavia tietoja: seuraava pysäkki arvioitu saapumisaika myöhästymisaika Taattujen vaihtojen hallinta Taattujen vaihtojen hallinnalla tarkoitetaan sitä, kun halutaan varmistaa että vaihto liikennevälineestä toiseen onnistuu varmasti. Tässä tapauksessa ennustetietoja voitaisiin hyödyntää esim. siinä että lähetetään liityntäbussin kuljettajille viesti että tämän pitää odottaa myöhästyvää junaa. Taattujen vaihtojen hallinnassa välitettäviä tietoja: linjan A arvioitu saapumisaika pysäkille/asemalle linjan B lähtöaika pysäkiltä/asemalta Ennustetietojen visualisointi kartalla ohjauskeskuksissa Tässä käyttötapauksessa halutaan näyttää kartalla ennustettu liikennetilanne tietyn ajan päästä. Karttanäkymän avulla joukkoliikennetoimija voi paremmin varautua yllättäviin muutoksiin liikenteessä. Esim. häiriön sattuessa voidaan nopeasti arvioida liikenteen ruuhkautuminen puolen tunnin päästä ja varautua siihen. Tarvittavia tietoja: linjojen ennustetut sijainnit jollain ajanhetkellä linjojen ajosuunnat linjojen ennustetut viivetiedot 2.3 Teknisiä toteutustapavaihtoehtoja Tässä kappaleessa on selvitetty rajapinnan eri toteutustapavaihtoehdot tekniseltä kannalta. Tässä kappaleessa on lähdetty olettamuksesta, että ennustepalvelin on internetissä sijaitseva palvelin ja että palvelimen viestinvälityksen halutaan perustuvan standardinmukaisiin XMLtekniikoilla. 9

10 2.3.1 Standardin hyödyntäminen Standardiin pohjautuvassa toteutustavassa rajapinta toteutetaan perustuen johonkin ulkomaiseen standardiin. Edellytyksenä on että löydetään sopiva standardi ja että se vastaa rajapinnalle esitettyihin vaatimuksiin. Standardin perustuisi johonkin tässä kappaleessa esiteltyyn tekniseen toteutustapaan. Standardinmukaisen toteutustavan etuna on että rajapinnasta on käyttökokemuksia muualta ja sen voidaan olettaa olevan toimiva ratkaisu. Toisena merkittävänä etuna voidaan pitää että saadaan säästöjä, kun toteutuksessa voidaan hyödyntää valmiita ohjelmistokomponentteja ja olemassa olevia tietotaitoja Toteutus web-palveluna Web-palvelut (Web Services) ovat joukko viime vuosina yleistyneitä tekniikoita, joilla voidaan toteuttaa standardinmukaisia konekielisiä rajapintoja tietojärjestelmiin. Web-palvelut edustavat tämän päivän de facto tapaa integroida tietojärjestelmiä yhteisen rajapinnan kautta. Webpalvelut soveltuvat erityisesti www-pohjaisten tietojärjestelmien integrointiin. Web-palvelun kehittäminen edellyttää että palvelun rajapinnasta tehdään WSDLkuvausdokumentti ja että välitettävät sanomat kuvataan XML Schemalla. Web-palveluissa sanomat lähetetään useimmiten SOAP-protokollan yli, joka on ohut protokolla HTTPprotokollan päällä. SOAPin käyttö ei kuitenkaan ole pakollista, jos halutaan tehdä ns. RESTtyyppinen web-palvelu. Web-palveluiden kehittäminen on nykyään kohtuullisen helppoa, koska tähän tarkoitukseen on paljon valmiita kehitystyökaluja ja ohjelmakoodikirjastoja. Myös ennusterajapinta voidaan toteuttaa web-palveluna. Tämän tavan suurin etu olisi se että rajapinnasta tulisi yleisten standardien mukainen. Haitaksi voidaan sanoa SOAP-protokollan aiheuttamat ylimääräiset siirtokustannukset XML + HTTP -tapa Tässä toteutustavassa XML-sanomat lähetetään suoraan HTTP-protokollan yli ilman SOAPprotokollaa. Tällöin tarvitsee kuvata pelkästään välitettävät viestit, johon käytetään XML Schemaa. Rajapinnan toimintalogiikkaa ei kuvata tässä tapauksessa erillisellä kuvauskielellä, vaan se voidaan kertoa sanallisesti määrittelydokumentissa. Etuna tässä tavassa on että se on jonkin verran yksinkertaisempi kuin web-palvelun toteutus. Haittana tässä tavassa on että rajapinnasta ei tule koneluettavaa, jolloin sitä ei voi käyttää ja testata valmiilla työkaluilla. Ongelmaksi voi muodostua myös että määrittelydokumentissa rajapinnan toimintalogiikkaa ei pystytä kuvaamaan sanallisesti kyllin tarkasti, jolloin toimijoiden toteutuksista voi tulla erilaisia. 10

11 2.3.4 XML + TCP -tapa Tämä toteutustapa on periaatteessa vastaava kuin edellinen, mutta tässä tapauksessa XMLviestit lähetetään suoraan TCP:n yli ilman HTTP-protokollaa. Käyttäjän pitää siis avata porttiyhteys palvelimeen ennen kuin voi alkaa lähettää tälle XML-kyselyjä. Tämän toteutuksen etuna on että se on kevyt ja yksinkertainen. Ongelmaksi saattaa muodostua mm. se että palomuureihin täytyy tehdä vaikeita porttiavauksia, joilla sallitaan TCPyhteydet erikoisiin porttinumeroihin. Lisäksi tässä tavassa syntyy ylimääräisiä kustannuksia siitä kun porttiyhteyttä joudutaan pitämään jatkuvasti auki tai se joudutaan avaamaan uudestaan jokaista kyselyä varten (vrt. HTTP keep-alive). Tässä tavassa menetetään myös virhekoodien tuoma etu ongelmatilanteiden selvittämisessä. 2.4 Ulkomaisia rajapintastandardeja Tässä kappaleessa on selvitetty ulkomaisia rajapintastandardeja, joita voitaisiin mahdollisesti hyödyntää ennusterajapinnan teknisessä määrittelyssä SIRI SIRI (Service Interface for Real Time Information) on yhteiseurooppalainen rajapintastandardi julkisen liikenteen ja ajoneuvojen reaaliaikatietojen välittämiseen joukkoliikennetoimijoiden välillä. SIRI-standardi on käytössä mm. Isossa-Britanniassa, Ruotsissa, Tanskassa, Norjassa, Saksassa, Ranskassa ja Tshekissä. SIRI-standardi vastaisi varsin hyvin tämän projektin tarpeita. [1] SIRI on kehitetty kansallisten standardien pohjalta ja siitä on pyritty kehittämään mahdollisimman joustava, jotta sitä voidaan käyttää mahdollisimman monissa maissa. Standardi on alun perin kehitetty Ranskassa, Saksassa ja Iso-Britanniassa. SIRI on hyväksytty CEN-standardiksi vuonna 2006 (CEN ). SIRIä voidaan käyttää mm. aikataulujen välittämiseen muille toimijoille, tietojen välitykseen pysäkkinäytöille, liikennevälineiden seurantaan, taattujen vaihtojen hallintaan ja liikennevälinenäyttöjen ohjaukseen. SIRI määrittelee XML/Web Service -pohjaisen rajapinnan VDV453/454 VDV453/454 on SIRI-standardin Saksa versio. VDV (Verband Deutscher Verkehrsunternehmen) on saksalainen julkisen liikenteen ja rahtiliikenteen toimijoiden liitto. Siihen kuuluu Saksan suurimmat joukkoliikenteen toimijat mukaanlukien paikallisliikenne ja kaukoliikenne. Liiton päätehtäviin kuuluu laatia suosituksia jäsenyrityksilleen parhaista käytännöistä liittyen julkisen liikenteen operointiin. [2] 11

12 VDV453 edustaa SIRIn osajoukkoa ja se on suositus julkisen liikenteen toimijoille AVMSjärjestelmän julkisesta rajapinnasta. AVMS-järjestelmiä (Automatic Vehicle Management Systems) käyttävät operaattorit ja muut toimijat liikennevälineiden seuraamiseen ja hallintaan. Rajapinnan kautta toimija voi tarjota reaaliaikapohjaisia tietoja liikennevälineistään muille toimijoille. VDV453 edustaa SIRI-standardiin CEN osajoukkoa. VDV454 sisältää joitain lisäyksiä edellä mainittuun suositukseen. VDV453 ja VDV454 suositukset löytyvät VDV:n www-sivuilta kohdasta VDV-projects. Suositukset ovat kirjoitettu englanniksi. VDV on tuottanut myös lukuisia muita suosituksia ja standardeja liittyen tiedon vaihtoon sen jäsenyritysten kesken RTIG-XML RTIG-XML on SIRI-standardin Iso-Britannia versio ja edustaa tämän osajoukkoa. RTIG (Real Time Interest Group) on reaaliaikastandardeihin keskittynyt organisaatio Isossa-Britanniassa. RTIG on osallistunut myös SIRI-standardin kehittämiseen. RTIG-XML:n ensimmäinen versio julkaistiin vuonna [3] 12

13 3 ASETETTAVAT VAATIMUKSET JA RAJAUKSET Tässä luvussa on esitetty rajapinnalle asetettavat vaatimukset. Vaatimukset ja rajaukset on kerätty edellisten lukujen selvitysten perusteella sekä suoraan alkuperäisestä tarjouspyynnöstä. Tämän luvun tarkoitus on luoda perusta myöhemmin tehtävälle tekniselle määrittelylle. 3.1 Yleiset vaatimukset Rajapinnan ensimmäisestä versiosta on suunniteltava mahdollisimman yksinkertainen, jotta se soveltuu käyttöönotettavaksi mahdollisimman monelle toimijalle. Yksinkertaisuudella varmistetaan myös että ennustepalvelimesta ei tule toimijalle liian kallista toteuttaa. Rajapinta suositellaan toteuttavan SIRI-standardin määrittelemällä tavalla, koska SIRI vastaa tämän projektin vaatimuksia varsin hyvin. SIRIn määrittelemä XML-rajapinta on syytä toteuttaa web-palveluna, koska se tarjoaa eniten mahdollisuuksia ja on toimijoiden kannalta helpoin. Rajapinta tulisi tehdä sellainen, että siinä on huomioitu mahdollisimman hyvin eri liikennemuodot. Eri liikennemuodoista tärkeimmät ovat paikallisliikenne, junaliikenne ja bussien kaukoliikenne. Vähemmän tärkeitä liikennemuotoja ovat laiva- ja lentoliikenne. 3.2 Käyttötapauksiin liittyvät vaatimukset Aiemmin esitellyistä käyttötapauksista tärkeimpänä voidaan pitää liikennevälineiden saapumisaikaennusteiden esittämistä pysäkkien ja asemien näyttötauluilla. Täten ao. käyttötapaus on syytä määrittää rajapinnan pääkäyttötapaukseksi hankkeen ensimmäisessä vaiheessa. Pääkäyttötapauksessa tärkein välitettävä tieto on milloin tietty linja saapuu tietylle pysäkille tai asemalle. Muut käyttötapaukst (liikennevälineiden näyttötaulut, kalustonhallinta, LIVA-etuudet ym.) voidaan toteuttaa myöhemmin, mutta toistaiseksi ne rajataan tämän määrittelyn ulkopuolelle. Rajapinta on suunniteltava siten, että se tarjoaa tulevaisuudessa riittävät laajennusmahdollisuudet näille käyttötapauksille. Jotta myös netti- ja mobiilipalvelut voivat hyödyntää ennusterajapintaa, on teknisessä määrittelyssä huomioitava mm. reittioppaiden, aikataulusivujen ja omat lähdöt tyyppisten palveluiden erityistarpeet. 3.3 Toiminnalliset vaatimukset Rajapinnasta on voitava tilata ennusteet myös jatkuva-aikaisena syötteenä. Tämä tarkoittaa että rajapinnassa on oltava omat erityiset kyselytyypit, jotka mahdollistavat syötteenä tilaamisen. Toisin sanoen, ennusterajapinnan tuettava sekä pyyntö/vastaus että julkaise/tilaa - tyyppisiä kommunikaatiomalleja ja kyselykäytäntöjä. 13

14 Rajapinnan on syytä tarjota vain yleiskäyttöisiä kyselytyyppejä, jotka soveltuvat käytettäväksi kaikkien toimijoiden toimesta. Tietyn toimijan tietylle järjestelmälle räätälöityjä kyselytyyppejä ei ole rajapintaan järkevää toteuttaa. Laajasta ja suppeasta rajapinnasta: Laajaa ja suppeaa versiota rajapinnasta ei tulla määrittelemään erikseen. Sen sijaan rajapintaan toteutetaan tietty pakollinen (suppea) joukko kyselytyyppejä ja tämän lisäksi laajempi joukko valinnaisia kyselytyyppejä, joista kukin toimija toteuttaa haluamansa. Suppeassa toteutuksessa kyselytyyppien lisäksi voidaan toteutusta rajata tarkemmin myös tietuekohtaisesti kyselytyyppien sisällä. Rajapinta on suunniteltava siten että itse palvelu kykenee lähettämään/vastaanottamaan yli 1000 viestiä sekunnissa ilman merkittäviä viiveitä. Liikennevälineiden saapumisaikaennusteet pysäkeille/asemille on saatava vähintään sekunnin tarkkuudella. 3.4 Tekniset vaatimukset Mikäli rajapinta toteutetaan SIRI-standardin mukaisena web-palveluna, rajapinnan tulee toteuttaa SIRI-standardin mukainen WSDL-rajapintakuvaus. Lisäksi rajapinnassa käytettävien sanomien on oltava SIRIn XML Schemojen mukaisia. Viestinvälityksen on tapahduttava rajapinnasta viiveettömästi ja ilman porrastusta, kun viestejä lähetetään asiakkaalle syötteenä. Rajapinnan eri versioiden on oltava taaksepäin yhteensopivia. 3.5 Asetettavia rajauksia Teknisessä määrittelyssä määritellään ennustepalvelimen rajapinta määrittely ei ota kantaa siihen, miten itse ennustepalvelin tulisi toteuttaa ja mitä teknologioita toteutuksessa tulisi hyödyntää. Näistä asioista päättää kukin toimija itsenäisesti. Rajataan käyttötapaukset liikennevaloetuudet ja Matkapalvelukeskusten (MPK) operatiivinen hallinta kokonaan ennusterajapinnan määrittelyn ulkopuolelle. 14

15 4 SUOSITUKSIA 4.1 Koordinointiryhmä Työryhmä suosittelee, että ennustepalvelimen toteutusprojekteja varten perustetaan oma koordinaatioryhmänsä tai nimetään yksi vastuuhenkilö tilaajaorganisaatioiden toimesta. Ryhmän tai vastuuhenkilön vastuulla olisi opastaa toteutusprojektien tekijöitä ongelmatilanteissa, ylläpitää rajapinnassa käytettävää viitekehystä, testata toteutetut rajapinnat sekä tehdä korjauksia ja parannuksia rajapintamäärittelyyn. Testauksella tarkoitetaan sitä, että koordinaatioryhmä varmistaa, että tehdyt toteutukset ovat määrittelyn mukaisia. Viitekehyksen ylläpidolla tarkoitetaan sitä, että koordinointiryhmä määrittelee minkä muotoisia tunnisteita (viitteitä) toimijoiden on syytä käyttää rajapinnan viesteissä sellaisista asioista kuin pysäkeistä, linjakoodeista, reiteistä, ajosuunnista ym Tukisivusto Työryhmä suosittelee, että ennusterajapintaan liittyvät dokumentit ja muut ohjeet liitetään osaksi Kalkati.net www-sivustoa. Kalkati.net sivustolle voitaisiin perustaa esim. oma alasivunsa ennusterajapinnan asioita varten. Alasivulle voitaisiin laittaa mm. lyhyt johdatus aiheeseen, ajankohtaista-osio, UKK-osio, linkit käytettäviin määrittelydokumentteihin ja skeemoihin, koordinaatioryhmän yhteystiedot, lista jo toteutetuista rajapinnoista sekä linkit mm. SIRIn määrittelydokumentteihin. Sivun ylläpito olisi koordinointiryhmän vastuulla. 4.3 Referenssitoteutus Työryhmä suosittelee, että tehdään ennustepalvelimesta ja sen rajapinnasta ns. referenssitoteutus, jonka tarkoitus on tuottaa käytännön kokemuksia rajapinnan toteuttamisesta ja siinä mahdollisesti ilmenevistä haasteista. Näiden kokemuksien avulla voidaan tehdä tarkennuksia määrittelydokumentteihin ennen kuin rajapintaa aletaan laajemmin toteuttamaan. Referenssitoteutuksen tulee tekemään näillä näkymin HKL, joka toteuttaa ennusterajapinnan Helmi-reaaliaikajärjestelmän yhteyteen. Rajapintaa tulisi käyttämään ainakin ENOjulkaisujärjestelmä. Työryhmä suosittelee, että hankkeen aikana työryhmä voisi toimia avustavassa roolissa. 4.4 Käytettävä viitekehys Työryhmä suosittelee, että ennusterajapintahankkeiden aikana panostetaan riittävästi ennusterajapinnan viitekehyksen suunnitteluun ja sen toteutumiseen. Viitekehyksellä tarkoitetaan rajapinnassa käytettäviä tunnistekäytäntöjä, ts. minkälaisia yksilöiviä tunnisteita ja koodeja (viitteitä) käytetään joistain tärkeistä asioista kuten linjoista, 15

16 pysäkeistä, reiteistä, ajosuunnista ym. Näitä tunnisteita käytetään välitettävissä viesteissä tietueiden arvoina. Yhtenäisten tunnistekäytäntöjen sopiminen on tärkeää, koska vain tällöin on mahdollista käyttää eri toimijoiden rajapintoja täsmälleen samalla tavalla. Jos yhtenäisiä tunnistekäytäntöjä ei sovita, niin asiakassovelluksiin joudutaan ohjelmoimaan jokaista rajapintaa kohden oma tunnisteiden muodostuslogiikka. Tunnistekäytännöistä sopimisella varmistetaan myös, että tarpeelliset yksilöivät tunnisteet säilyvät yksilöllisinä. Teknisessä määrittelyssä olevia alustavia tunnistekäytäntöjä on syytä täydentää referenssitoteutuksen yhteydessä, kun tiedetään tarkasti minkälaisia tunnisteita tarvitaan. Määrittelyä olisi syytä ylläpitää myös tämän jälkeen. Tunnistekäytäntöjä voitaisiin ylläpitää mahdollisesti myös hankkeen www-sivuilla. 4.5 Paikannusarkkitehtuurin kehitystarpeet Alkuperäisessä tehtävänmäärityksessä oli ehto, että ennusterajapinnan määrittelyn aikana listataan myös kehitystarpeet valmistuneelle Kansallisen joukkoliikenteen paikannusarkkitehtuurille [4]. Kuvassa 3 on esitetty työryhmän suositus paikannusarkkitehtuurista. Siinä on paikannus- ja ennusterajapinnat yhdistetty yhdeksi rajapinnaksi, joka tarjoaa asiakassovelluksille kaikki tarvittavat tiedot yhdestä paikasta. Yhdistetty paikannus/ennusterajapinta toteutettaisiin kokonaan SIRI-standardin avulla. Ajoneuvorajapinta voitaisiin toteuttaa Kansallisen joukkoliikenteen paikannusarkkitehtuuri - dokumentin mukaisesti tai sitten käyttää tähän tarkoitukseen soveltuvaa kansainvälistä rajapintastandardia, jos sellainen löydetään. Tätä mahdollisuutta olisi hyvä selvittää. Toimijan taustajärjestelmät suositellaan yhdistettäväksi palveluväylällä. 16

17 Ennustepalvelu Aikatauluttietokanta Muut taustajärjestelmät Database Palveluväylä Paikannuspalvelin SIRI-palvelin Ajoneuvorajapinta Paikannus- ja ennusterajapinta (SIRI) Ajoneuvot Sovellukset Kuva 3: Työryhmän suosittelema paikannusarkkitehtuuri. 17

18 LIITE 1: HAASTATTELUISSA ESILLE TULLEET ASIAT No. Asia 1. Ennustetietoja tulee ensisijaisesti tarjota push-tyyppisesti, koska se on pull-tapaa tehokkaampaa suurten datamäärien jatkuvassa siirtämisessä. 2. Vaikka rajapinta tulee sisältämään monipuolista toiminnallisuutta ja suuren joukon parametreja, pitää silti kiinnittää erityistä huomiota helppokäyttöisyyteen ja pitää kokonaisuus niin yksinkertaisena kuin mahdollista. 3. Koko ennustepalvelun tarjoamaa ei voida jakaa julkisesti internetissä, vaan esimerkiksi kuljettajanumerot on pidettävä erillään julkisesti saatavilla olevasta informaatiosta. 4. Pelisäännöt käyttöoikeuksien hallinnan osalta tulee määritellä selvästi, eli mitä tietoa ylipäänsä jaetaan, missä muodossa ja kenelle? 5. Itse ennustepalvelimen on hyvä tukea tietojen vastaanottamista useista lähteistä, esimerkiksi tulevaisuudessa hyödyntää Tiehallinnon sää- ja kelipalveluiden tarjoamia tietoja ennusteiden laadinnassa. 6. Rajapinnan odotetaan palauttavan rajallisen määrän jalostettua tietoa. 7. Rajapintaa tulee voida käyttää myös stream-muotoisen datan välitykseen, mikä tarkoittaa informaation tarjoamista helposti jatkojalostettavana raakadatana. 8. Rajapinnan on tuettava ESB/SOA -pohjaista IT-arkkitehtuuria, jonka osaksi ennustepalvelin kytketään. 9. Määrittelyssä tulee ottaa huomioon noin 2000 ajoneuvon ja 7000 pysäkin asettamat tekniset haasteet. 10. Ennustepalvelimen tulee tukea syötteitä ainakin seuraavista lähteistä: Tiehallinto, sää ja kelipalvelut, Muuli, RHK, VR, Metro. Kommentit Molemmat tavat mahdollisia Huomioitu Huomioitu Rajapinnasta jaetaan vain liikennetietoa Ei liity rajapintaan Huomioitu Streamaus = syötteenä tilaaminen on huomioitu Rajapinta toteutetaan Web-palveluna, joka helppo liittää SOA:aan Huomioitu Ei varsinaisesti liity rajapintaan 11. Dataa on pystyttävä esittämään monenlaisilla näytöillä. Tietojen esittämistapa näytöillä ei liity rajapintaan 18

19 12. Tekstimuotoiset tiedotteet voivat olla osa rajapintaa, mutta ne voivat tulla myös erillisestä rajapinnasta. 13. Yleensä minuutin tarkkuus ennusteissa on riittävä, mutta teknisesti rajapinnan tarkkuus on esitettävä sekunneissa. 14. Paikkatietoa voidaan välittää rajapinnan kautta, mutta se voi tulla myös erillisen rajapinnan kautta. 15. Yksinkertaisemmissa nettipalveluissa voi riittää pull-tyyppinen rajapinta. Poikkeustiedotteita voidaan välittää määritellyn rajapinnan kautta Sekunnin tarkkuus käytössä Paikkatietojen välitys mahdollista Molemmat tavat määritelty 16. Ennustetietoja voidaan hyödyntää liikenteen ohjauksessa. Osittain mahdollista 17. Liikennevaloetuudet ja Matkapalvelukeskusten (MPK) operatiivinen hallinta 18. Alkuperäinen jako laajaan ja suppeaan rajapintaan hylätään, ja sen sijaan määritellään RP:ssa pakolliset ja optionaaliset tiedot ja parametrit. 19. Rajapinnan tulee soveltua pysäkkien, liikennevälineiden, kuljettajan ja terminaalien infonäyttöjen tarpeisiin 20. Rajapinnan tulee soveltua www- ja mobiilisovelluksille, kuten Reittiopas, aikataulusivut, Kamo ym. Ei mahdollista Vain yksi rajapinta määritelty Sopii toistaiseksi pysäkki- ja terminaalinäyttöjen tarpeisiin Mahdollista 21. Rajapinnan tulee soveltua joukkoliikenteen jakelupalveluun Osittain kyllä 22. Bussin siirtyminen linjalta toiselle: jos bussi ei ehdi siirtyä tietyssä ajassa, tulee liikennöitsijälle sakkoa Ei huomioitu 23. Lähtöketjunhallinta Ei huomioitu 24. Rajapinta tukee liikenneinfoportaaleita Osittain mahdollista 25. Rajapinta tukee Nokia mapsia ja Googlea Ao. karttapalvelujen mahdollista käyttää määriteltyä rajapintaa 26. Ruuhkaindikaattori: Jos monet bussit ovat myöhässä aikataulusta jollain reitillä, voidaan päätellä, että siellä on todennäköisesti ruuhkaa. Mahdollinen jatkomäärittelyn aihe 27. Speed profiling Mahdollinen 19

20 jatkomäärittelyn aihe 28. Jos ennustetietoa ei saatavilla, pitäisikö antaa paikannustietoa? Annetaan aikataulun mukaisia aikoja 29. Ennustetietojen viiveetön jakaminen omiin ja kolmansien osapuolien liikennetietotojärjestelmiin 30. Tärkein käyttötapaus on pysäkkien infotaulut, joihin tulee saada push-tyyppisesti saapumisaikaennusteet. 31. Rajapinnan peruskäyttö on tärkein: koska liikenneväline saapuu pysäkille? Huomioitu Tämä on ollut määrittelyn lähtökohta Ollut myös lähtökohtana 32. Rajapintaa käyttää mm. infonäyttöjen ohjausjärjestelmä. Kyllä 33. Viestit näytöille lähetetään laitetoimittajan oman rajapinnan kautta. 34. Liikennöitsijät käyttävät rajapintaa esim. kalustonhallintaan ja dispatchaukseen Riippuu toteuttaako ennusterajapinnan toimija vai laitetoimittaja Mahdollinen jatkomäärittelyn aihe 35. Varautuminen tulevaisuudessa hankittaviin järjestelmiin Huomioitu 36. Tulevaisuudessa liikenteen infokeskus on rajapinnan merkittävä hyödyntäjä. 37. Kuljettajamonitorit liikennevälineissä tulevat käyttämään rajapintaa. 38. Rajapintaa hyödyntävät pysäkkien infonäytöt, jotka näyttävät matkustajille bussien arvioidut saapumisajat pysäkille. 39. Rajapintaa hyödyntävät liikennevälineissä olevat infonäytöt, jotka näyttävät matkustajille reitin, reittimuutokset ja arvioituja ajoaikoja. Kehittyneissä infonäytöissä voitaisiin näyttää myös vaihtomahdollisuudet seuraavalla pysäkillä ja arvioidut saapumisajat vaihdettaviin liikennevälineisiin. 40. Rajapinnan mahdollinen käyttötapaus kalustonhallinnassa: Jos bussi ei ehdi sille määriteltyyn lähtöön, lähtö uudelleenjärjestellään ja kuljettajaa voidaan ohjata kääntämään ympäri ennen päätepysäkkiä. Huomioitu Vaatii jatkomäärittelyn Kyllä Liikennevälinenäytöt tulevat seuraavassa vaiheessa, toistaiseksi vain pysäkkinäytöt Mahdollista myöhemmin 41. Liikennöinnin seuranta ja hallinta Mahdollista myöhemmin 42. Liikennevaloetuudet ja MPK:n operatiivinen hallinta Osittain mahdollista myöhemmin 20