MOBIILI JAVA HAJAUTETUISSA MITTAUS- JA OHJAUSJÄRJESTELMISSÄ

Transkriptio

1 JOONAS TUNTURI MOBIILI JAVA HAJAUTETUISSA MITTAUS- JA OHJAUSJÄRJESTELMISSÄ DIPLOMITYÖ Aihe hyväksytty osastoneuvoston kokouksessa Tarkastajat: prof. Hannu Koivisto, prof. Tommi Mikkonen

2 Sisällysluettelo TIIVISTELMÄ...4 ABSTRACT...5 KÄYTETYT LYHENTEET JOHDANTO TUTKIMUKSEN RAJAUS TUTKIMUKSEN RAKENNE HAJAUTUKSEN OMINAISUUDET JA VAATIMUKSET TAPAHTUMAPOHJAINEN MITTAUS- JA OHJAUSJÄRJESTELMÄ Hajautettujen järjestelmien erityispiirteitä Kommunikointi järjestelmän komponenttien välillä Automaation erityisvaatimukset MAANTIETEELLISESTI HAJAUTETTU AUTOMAATIOJÄRJESTELMÄ Järjestelmän rakenne Esimerkkejä maantieteellisesti hajautetuista järjestelmistä Maantieteellisen hajautuksen erityisvaatimukset MOBIILI JAVA J2ME Siirrettävyys Konfiguraatiot Profiilit CLDC Yleistä Virtuaalikone CLDC IMP IMP-profiilin ominaisuudet IMletin ajoympäristö ja hallinta IMP-NG MOBIILI JAVA HAJAUTETUISSA JÄRJESTELMISSÄ LIITTYMINEN LAAJEMPAAN JÄRJESTELMÄÄN Järjestelmäarkkitehtuurit Väliohjelmistot CORBA-ORB

3 JMS MOBIILILAITE JÄRJESTELMÄN OSANA Laitearkkitehtuuri Mobiililaitteen kolme roolia SÄÄHAVAINTOVERKKO, CASE VAISALA TAVOITTEET JA YMPÄRISTÖ Tutkimuksen tavoitteet ROSA-tiesääasema Nokia 12 -mobiililaite Kehitysympäristö MOBIILILAITE SÄÄASEMAN AINOANA ALUSTANA Tavoitteet ja toiminta Soveltuvuus sääaseman ainoaksi alustaksi MOBIILILAITE INTEGROITUNA TIESÄÄASEMAAN Tavoitteet ja toiminta Soveltuvuus tiedonvälitykseen säähavaintoverkossa JAVAN ASEMA JA MAHDOLLISUUDET HAJAUTETUSSA AUTOMAATIOSSA JAVAN TODELLINEN SIIRRETTÄVYYS ELINKAAREN HALLINTA ETÄÄLTÄ JMS VIESTINVÄLITYKSESSÄ OHJELMISTOKEHITYKSEN TEHOKKUUS ONGELMAT YHTEENVETO...61 LÄHDELUETTELO

4 TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto Ohjelmistotekniikka TUNTURI, JOONAS: Mobiili Java hajautetuissa mittaus- ja ohjausjärjestelmissä Diplomityö, 68 s. Kesäkuu 2004 Tarkastajat: prof. Hannu Koivisto ja prof. Tommi Mikkonen Rahoittajat: Vaisala Oyj, Metso Automation Oy, TeliaSonera Oyj, Plustech Oy, Nokia Mobile Phones M2M, TEKES, TTY Automaatio- ja säätötekniikan laitos Avainsanat: Mobiili Java, J2ME, CLDC, IMP, JMS, Hajautetut järjestelmät, mittaus- ja ohjausjärjestelmät Tiivistelmä Kustannustehokkuus yhtenä palvelujen ja niitä tukevien toimintojen tärkeimmistä ominaisuuksista on johtanut automatisoitumisen lisääntymiseen yhteiskunnassa. Erityisesti laitteiden verkottaminen hajautetuiksi automaatiojärjestelmiksi on lisääntynyt voimakkaasti. Tämä on lisännyt tarvetta kehittää laitteiden välistä viestintää. Laitteiden välinen viestintä tarvitsee nykyään entistä yleiskäyttöisempiä ja kustannustehokkaampia ohjelmistotekniikoita. Tutkimuksen on tarkoitus selvittää Mobiili Javan soveltuvuutta automaation tarpeisiin. Tutkimuksen teoriaosuus keskittyy hajautuksen ominaisuuksiin automaatiossa sekä Mobiili Java tekniikkaan ja sen soveltuvuuteen mittaus- ja ohjausjärjestelmien ohjelmistotekniikaksi. Tutkimuksen soveltavassa osuudessa on käsitelty hajautettujen sääasemasovellusten toteuttamista Mobiili Javan ja sitä tukevien laitteiden avulla. Tutkimuksessa määritellään myös käsite maantieteellisesti hajautettu automaatiojärjestelmä sekä mobiililaitteen kolme mahdollista roolia mittaus- ja ohjausjärjestelmän osana. Tutkimuksen johtopäätöksissä pohditaan Mobiili Java tekniikan tuomia etuja automatisoituvaan yhteiskuntaan. Lisäksi analysoidaan tekniikan puutteita, tämän hetkistä tilaa ja tulevaisuutta. 4

5 TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology Institute of Software Systems TUNTURI, JOONAS: Mobile Java in Distributed Measurement and Control Systems Master of Science Thesis, 68 pages. June 2004 Examiners: prof. Hannu Koivisto and prof. Tommi Mikkonen Funding: Vaisala Oyj, Metso Automation Oy, TeliaSonera Oyj, Plustech Oy, Nokia Mobile Phones M2M, TEKES, TUT Institute of Automaion and Control Keywords: Mobile Java, J2ME, CLDC, IMP, JMS, Distributed Systems, Measurement and Control Systems Abstract Cost-effectiveness is nowadays one of the main characteristics of services and operations supporting them. This has caused the importance of service automatisation to grow. Networking of devices to build distributed automation systems has especially grown rapidly. This has increased the need to develop machine to machine communication technologies between these devices. There is a call for new generic and cost efficiency software technologies to manage communication between the devices. This thesis clarifies how suitable Mobile Java is considering the needs of automation. Theory part of the thesis concentrates on characteristics of distribution in automation, characteristics of Mobile Java, and it s suitability to fulfil requirements of measurement and control systems. Applied part of the thesis describes the implementation of distributed weather station applications using Mobile Java and devices that support it. The meaning of geographically distributed automation system and the roles of mobile devices as a part of the system have also been defined in the research. Conclusions of this thesis describe the benefits of Mobile Java for a society relying more and more on automation. The worst shortcomings of Mobile Java are concluded in this thesis, as well as the current state and the future of the technology. 5

6 Käytetyt lyhenteet AMS ASCII CDC CLDC CORBA FP GPRS GSM HTTP IM IMP IMP IMP-NG IP J2EE J2ME J2SE JAR JCP JMS Application Management Software American Standard Code for Information Interchange Connected Device Configuration Connected Limited Device Configuration Common Object Request Broker Architecture Foundation Profile General Packet Radio Service Global System for Mobile Communication Hypertext Transfer Protocol Information Module Information Module Profile Information Module Profile Information Module Profile - Next Generation Internet Protocol Java 2 Platform, Enterprise Edition Java 2 Platform, Micro Edition Java 2 Platform, Standard Edition Java Archive Java Community Process Java Message Service 6

7 JSR JVM KVM LAN MIDP MMS MOM MVC NTCIP OEM ORB OTA PP RMS ROSA SIM SMS TCP WAP WSP WTP XML Java Specification Requests Java Virtual Machine K (Kilobyte) virtual machine Local Area Network Mobile Information Device Profile Multimedia Messaging Service Message Oriented Middleware Model View Controller National Transportation Communications for Intelligent Transportation System (ITS) Protocol Original Equipment Manufacturer Object Request Broker Over The Air Personal Profile Record Management System Road Surface Analyzer Subscriber Identity Module Short Message Service Transmission Control Protocol Wireless Application Protocol Wireless Session Protocol Wireless Transaction Protocol Extensible Markup Language 7

8 1. Johdanto Hajautetun automaation kasvu on nähtävissä erilaisten laitteiden muodostamien verkkojen muodossa. Virvoitusjuoma-automaatit keskustelevat varastonohjaus- ja huoltojärjestelmien kanssa, autot lähettävät sijaintinsa hätäkeskukselle onnettomuuden sattuessa tai säähavaintoasema raportoi säätietoja asiakkailleen. Verkottuminen on tunkeutumassa yhä laajemmalle alueelle, kuten viihdepalveluihin ja koteihin. Tämä hajautettujen automaatiojärjestelmien määrän ja niiltä vaadittujen ominaisuuksien nopea lisääntyminen on lisännyt tarvetta kehittää yleiskäyttöisiä ja kustannustehokkaita toteutustekniikoita. Mobiili Java pohjainen ratkaisu on eräs joustava ja helposti erilaisiin järjestelmiin integroituva tapa toteuttaa järjestelmän mittaus- ja ohjaustarpeet. Tutkimuksessa on keskitytty käsittelemään Mobiili Javan soveltuvuutta maantieteellisesti hajautetun mittaus- ja ohjausjärjestelmän ja sen etälaitteiden tarpeisiin. Tutkimuksen kohteena on myös etälaitteiden rooli osana laajempaa järjestelmää sekä viestinvälitys järjestelmän komponenttien välillä. Mittaustiedon välittäminen ja laitteiden etäohjaus voidaan toteuttaa monella eri tavalla. Tutkimuksessa on selvitetty Mobiili Java tekniikan ja viestipohjaisen väliohjelmiston (Java Message Service, JMS) soveltuvuutta tähän tarkoitukseen. Sovelluksena on käytetty maantieteellisesti hajautettua säähavaintoasemaa. 8

9 1.1. Tutkimuksen rajaus Työssä tutkitaan laitteiden väliseen kommunikointiin suunnitellun Mobiili Javan ja sitä tukevien mobiililaitteiden soveltuvuutta maantieteellisesti hajautetun automaation mittausja ohjaustehtäviin. Vaikka työn nimestä on jätetty maantieteellinen hajautus pois, on se mobiilimaailmasta puhuttaessa otettava huomioon. Aiheen laajuuden vuoksi tutkimuksen ulkopuolelle on rajattu tietoturvan käsittely. Tutkittaessa Mobiili Javan liittymistä laajempaan järjestelmään on jouduttu osa merkittävistä järjestelmäarkkitehtuureista, kuten Microsoftin.NET, rajaamaan pois Tutkimuksen rakenne Mobiili Javan soveltuvuutta hajautettuihin mittaus- ja ohjausjärjestelmiin voidaan tarkastella tarkemmin vasta taustalla olevaan teoriaan tutustumisen jälkeen. Viitekehyksen esittelystä ja määrittelystä vastaa luku kaksi, jossa puhutaan hajautuksesta yleisesti, automaation erityisvaatimuksista sekä määritellään maantieteellisesti hajautettu automaatiojärjestelmä. Luvussa kolme on purettu auki Mobiili Javan määrittelyistä työn kannalta olennaisimmat osat sekä esitelty olennaisimmat uudistukset tulevista määrittelyistä. Neljännessä luvussa yhdistetään osittain kahden edellisen luvun anti ja esitellään mahdollisuuksia liittää mobiililaite laajempaan järjestelmään. Samassa luvussa tutkitaan myös mobiililaitteiden mahdollisia rooleja järjestelmän osana. Luku viisi on puhtaasti soveltava. Siihen on dokumentoitu tavoitteita ja tuloksia työn soveltavasta osuudesta: Mobiili Java kahdessa roolissa osana säähavaintoverkkoa. Kahdessa viimeisessä luvussa pohditaan tutkimuksessa saavutettuja tuloksia, arvioidaan tutkimuksen merkitystä ja katsotaan tulevaisuuteen. 9

10 2. Hajautuksen ominaisuudet ja vaatimukset Hajautus tuo järjestelmään kompleksisuutta. Hajautetun järjestelmän hallinta on usein vaikeampaa kuin keskitetyn järjestelmän hallinta. Tosin joissakin tapauksissa hajautus myös yksinkertaistaa järjestelmää jakamalla ongelman pienempiin osiin. Hajautus tuo järjestelmälle ominaisuuksia, joita keskitetty arkkitehtuuri ei tarjoa. Joskus hajautus on pakollista järjestelmän fyysisten ominaisuuksien vuoksi Tapahtumapohjainen mittaus- ja ohjausjärjestelmä Järjestelmällä on yleensä vaatimus maksimiajasta, jossa tehtävä on suoritettava, vaikka sillä ei olisikaan varsinaisia reaaliaikavaatimuksia [Liu01]. Vaatimukset ajoitukselle voivat olla joko kovia tai pehmeitä. Ellei vaatimuksiin pystytä vastaamaan seurauksena voi olla virhe toiminnassa tai tietyn tiedon menetys mittauksessa (kovat ajoitusvaatimukset), tai ainakin järjestelmän toiminnan viivästyminen (pehmeät ajoitusvaatimukset) [Liu01]. Vaatimus määrittelee kuitenkin ennemminkin järjestelmän ulkoisen suorituskyvyn, kuin sen toteuttaman yksittäisen toiminnon ajoituksen. Tehtävien suoritukselle/ajoitukselle on siis asetettu tietyt reunaehdot, joiden puitteissa järjestelmän on toimittava. Monet ohjaus- ja monitorointijärjestelmät ovat tällaisia. Esimerkiksi 10

11 erillisen laadunvalvontajärjestelmän havaittua virheen tuotteessa sen ei tarvitse pysäyttää linjaa reaaliajassa. Tuotannon kannalta riittää, kun tieto virheestä saadaan ennen määritellyn maksimiajan umpeutumista, oli se sitten 100 millisekuntia tai 5 minuuttia. Reaaliaikaisuuden puute ei siis estä laadunvalvontajärjestelmää toimimasta. Tapahtumapohjaisilla järjestelmillä ei yleensä ole kovia reaaliaikavaatimuksia. Mittaus- ja ohjausjärjestelmissä hajautetulla etälaitteella voi kuitenkin olla toimintoja, jotka vaativat reaaliaikaista ajoitusta, vaikka koko järjestelmän tasolla vaatimukset olisivatkin kevyemmät. Esimerkiksi mittaus on joissakin tapauksissa tehtävä millisekunnilleen oikeaan aikaan, vaikkei tiedon eteenpäinviennillä olekaan yhtä kovia vaatimuksia. Kevyemmät vaatimukset tiedonvälityksen ajoituskriittisyyden suhteen mahdollistavat virtuaalikonepohjaisten alustariippumattomien arkkitehtuurien soveltamisen hajautetuissa mittaus- ja ohjausjärjestelmissä Hajautettujen järjestelmien erityispiirteitä Järjestelmiä voidaan hajauttaa monella eri tavalla. Yksinkertaisimmillaan hajautus voidaan tehdä PC-tietokoneen sisällä. Järjestelmän toiminnot hajautetaan eri prosesseille, jotka tekevät toimintojaan erillään, mutta toisistaan riippuen. Esimerkki tällaisesta arkkitehtuurista on MVC-malli (Model-View-Controller) [MVC]. Mallin mukaan toteutetussa ohjelmistossa voidaan tietokanta, käyttöliittymä ja varsinaiset toiminnot hajauttaa omiin ohjelmakomponentteihinsa, jotka vastaavat vain itselleen kuuluvista toiminnoista. Mallin etuna on mahdollisuus toteuttaa komponentit sekä eri ohjelmointikielillä että erilaisille alustoille. Näin saadaan toteutettua komponentit tehokkaimmilla mahdollisilla ohjelmointikielillä sopivimmille alustoille. Eri komponentit voidaan myös toteuttaa kullekin parhaiten sopivassa kehitysympäristössä. Hajautettu järjestelmä mahdollistaa resurssien jakamisen usealle käyttäjälle [CoDoKi01]. Esimerkiksi MVC-mallin mukaisen ohjelmiston käyttö voidaan jakaa usealle käyttäjälle. Käyttöliittymän toteuttaminen verkkosivuna mahdollistaa monen käyttäjän samanaikaisen käytön. Toimintoihin pääsy voidaan näin mahdollistaa kaikille Internetin käyttäjille. Internetiä kutsutaankin maailman suurimmaksi hajautetuksi järjestelmäksi. 11

12 Hajautettujen järjestelmien haasteet voidaan jakaa esimerkiksi seuraavasti [CoDoKi01]: Heterogeenisyys. Heterogeenisyys tarkoittaa samassa hajautetussa järjestelmässä esiintyvien erilaisten verkkojen, käyttöjärjestelmien, tietokoneiden ja ohjelmointikielten yhteensovittamista. Avoimuus. Avoimuus vaatii järjestelmän komponenttien rajapintojen julkaisemista ja niiden yhdistämisen mahdollistamista. Turvallisuus. Hajautettu järjestelmä vaatii tietoturvan toteutumista sen kaikilla tasoilla. Skaalautuvuus. Järjestelmän kokoa tulee voida kasvattaa ja pienentää ilman, että ohjelmistoja joudutaan muuttamaan. Virheiden hallinta. Jokaisen komponentin on hoidettava virheistä toipuminen niin, että ollessaan riippuvainen jostakin toisesta komponentista, se hallitsee myös kyseisen komponentin virhetilanteista johtuvat omat virheet. Samanaikaisuus. Usean käyttäjän järjestelmissä ei saa tulla ongelmia samanaikaisuudesta. Läpinäkyvyys. Jotta ohjelmistokehittäjät pystyvät keskittymään sovelluskehitykseen, on hajautus tehtävä sovelluksen kannalta läpinäkyväksi. Edelliset haasteet kuvaavat hyvin sekä hajautuksen monimutkaisuutta että sen tuomia mahdollisuuksia. Esimerkiksi heterogeenisyys vaatii järjestelmältä joustavia rajapintoja, mutta tarjoaa mahdollisuuden suorituskykyiseen toteutukseen, kuten MVC-mallissa. Järjestelmän skaalautuvuus taas vaatii sen komponenteilta kykyä mukautua muuttuviin tarpeisiin. Toisaalta se antaa mahdollisuuden optimoida toteutuksen tarpeen mukaan sopivan kokoiseksi Kommunikointi järjestelmän komponenttien välillä Hajautetun järjestelmän ominaisuuksiin kuuluu erityisesti älyn ja toimintojen hajauttaminen. Tämän vuoksi järjestelmää, jonka hajautetuilla komponenteilla ei ole itsenäistä toimintakykyä, ei voida perustellusti kutsua hajautetuksi järjestelmäksi. Pelkkä 12

13 anturoinnin hajautus fyysisesti erilleen mittaustietoa analysoivasta keskusjärjestelmästä ei tee järjestelmästä hajautettua. Älyn ja toimintojen hajauttaminen vaatii komponenteilta kahdensuuntaista kommunikointia. Esimerkiksi mittalaitteen on kyettävä lähettämään järjestelmälle mittaustietoa, ja toisaalta järjestelmän tulee pystyä ohjaamaan mittalaitetta. Mittaus- ja ohjaustoiminnot vaativat erilaisia älykkäitä ominaisuuksia kommunikoinnilta. Mittaustiedon määrä voi vaihdella suuresti sovelluksesta riippuen jopa yhden järjestelmän sisällä. Toiselta mittalaitteelta tietoa välitetään vain poikkeustilanteessa virheen sattuessa, kun taas toiselta laitteelta voidaan siirtää kuvia sekunnin välein. Siirtomedian joustavuus erilaisiin tarpeisiin onkin tärkeä ominaisuus hajautetuissa mittaus- ja ohjausjärjestelmissä. Tällaisissa järjestelmissä mittalaite voi lähettää tietoa aktiivisesti tai passiivisesti. Aktiivinen tiedon lähetys voi tapahtua esimerkiksi tietyin aikavälein tai mittauksen ylittäessä jonkin raja-arvon. Mittalaite lähettää mitatun tiedon oman päättelynsä tuloksena. Passiivisella tiedonvälityksellä puolestaan tarkoitetaan laitteen kykyä vastata keskusjärjestelmän pyyntöihin, eli lähettää mittaustietoa pyydettäessä. Hajautettujen laitteiden etäohjauksen toteuttaminen vaatii komponenttien väliseltä kommunikoinnilta edellisten lisäksi parempaa tietoturvaa ja palautetta ohjauksen onnistumisesta. Tietoturvan merkitys saattaa sovelluksesta riippuen olla suuri myös mittaustiedon välityksessä, mutta laitteiden etäohjauksessa sen merkitys on aina ilmeinen. Ohjauskomennon perillemenon varmistamiseksi on siitä yleensä saatava palaute järjestelmälle. Vaatimukset kommunikoinnin toteutuksesta hajautettujen komponenttien välillä riippuu sovelluksen tarpeista ja käytettävissä olevasta siirtomediasta. Esimerkiksi mittaustiedon määrä aikayksikköä kohti vaikuttaa suoraan verkolle asetettaviin vaatimuksiin. Joskus sovellus joudutaan suunnittelemaan siirtomedian asettamien reunaehtojen mukaan. Usein siirtomedia voidaan kuitenkin valita sovelluksen tarpeet täyttäväksi. Voimakkaasti yhteydestä keskusjärjestelmään riippuvissa järjestelmissä voidaan käyttää kommunikoinnin varmentamiseksi kahta siirtomediaa, esimerkiksi kiinteän langallisen yhteyden lisäksi langatonta GPRS-yhteyttä (General Packet Radio Service). 13

14 Automaation erityisvaatimukset Hajautettujen automaatiojärjestelmien keskinäinen erilaisuus johtaa siihen, että niiden järjestelmälle aiheuttamia erityisvaatimuksia on vaikea määritellä. Yleisesti voidaan todeta vaatimusten usein kohdistuvan tiedonsiirron ominaisuuksiin, kuten etälaitteen saavutettavuuteen, kommunikaatiossa käytettävään kaistan leveyteen tai tietoturvaan. Toisaalta automaatiojärjestelmien erilaisuuden vuoksi on kuitenkin vaikeaa määritellä näiden ominaisuuksien tärkeyttä yleisesti automaatiojärjestelmissä. Vaatimukset onkin kohdistettava automaatiojärjestelmien toimintoihin eikä koko järjestelmään. Toimintoja ovat esimerkiksi mittaustiedon siirto, toimilaitteiden ohjaus, reaaliaikainen säätö ja hälytysviestien lähetys. Näille toiminnoille voidaan helpommin asettaa vaatimuksia, vaikka nekin riippuvat koko järjestelmän vaatimuksista. Taulukko 2. 1 on esimerkki toimintojen verkon ominaisuuksille asettamista erityisvaatimuksista. Taulukko 2. 1 Automaatiojärjestelmien toimintojen tiedonsiirrolle asettamia vaatimuksia. Saavutettavuus Kaistan leveys Tietoturva Mittaus Tärkeä Ohjaus Tärkeä Tärkeä Säätö Tärkeä Tärkeä Hälytykset Tärkeä Päivitykset Tärkeä Automaatiojärjestelmät eivät kuitenkaan ainoastaan vaadi ominaisuuksia hajautukselta, ne voivat myös tyytyä joihinkin ominaisuuksiin, joihin tiedon hajauttamiseen perustuvat järjestelmät eivät tyydy. Esimerkiksi käytettävyysvaatimukset ovat laitteiden välisessä kommunikoinnissa erilaiset kuin ihmisen ja koneen välisessä kommunikoinnissa. Ihmiselle on erityisen tärkeää saada välitön palaute tekemästään toiminnosta, mutta laitteelle ei. Tämän vuoksi hajautetussa automaatiojärjestelmässä voidaan esimerkiksi kaistan leveyttä kaventaa käytettävyyden kärsimättä. 14

15 2.2. Maantieteellisesti hajautettu automaatiojärjestelmä Maantieteellisesti hajautettu automaatiojärjestelmä on terminä verrattain uusi, eikä sitä ole vielä tarkasti määritelty missään. Kyseessä on erikoistapaus hajautetuista automaatiojärjestelmistä (Kuva 2. 1). Tässä työssä termillä tarkoitetaan maantieteellisesti toisistaan erillään olevia laitteita, joilla on itsenäistä toimintakykyä ja keskinäisiä riippuvuussuhteita. Maantieteellisesti hajautetussa järjestelmässä laitteet ovat tyypillisesti etäällä toisistaan. Sanalla maantieteellinen halutaan tehdä ero laitteiden perinteiseen sijoitteluun, joka on yleensä rajattu ja hallittu, kuten tehdasympäristö. Itsenäisellä toimintakyvyllä tarkoitetaan laitteiden kykyä tehdä asioita ilman jatkuvaa ulkopuolista valvontaa tai ohjausta. Laitteilla on kyky tehdä itsenäisiä päätöksiä ja toimia niiden perusteella automaattisesti. Keskinäiset riippuvuussuhteet edellyttävät laitteilta kommunikointia järjestelmässä. Kommunikointi on maantieteellisen hajautuksen vuoksi usein mobiilia, vaikka maantieteellinen hajautus ei poissuljekaan langallista kommunikointia. Edellinen määritelmä ja koko kohta 2.2 on tehty yhteistyönä Tom Artellin kanssa, joka on käsitellyt tutkimuksessaan palvelun laatua automaation tiedonsiirrossa [Ar04]. Automaatiojärjestelmät Hajautetut automaatiojärjestelmät Maantieteellisesti hajautetut automaatiojärjestelmät Hajautetut järjestelmät Kuva 2. 1 Maantieteellisesti hajautettu automaatiojärjestelmä. 15

16 Järjestelmän rakenne Rakenteeltaan maantieteellisesti hajautettu järjestelmä ei periaatteessa eroa paikallisesti hajautetusta järjestelmästä; se koostuu kahdesta pääkomponentista: laitteista ja niitä yhdistävästä verkosta. Hajautetussa järjestelmässä älykkyyttä on viety laitteisiin, eli niillä on vähintään alkeellinen kyky toimia erilaisissa tilanteissa itsenäisesti. Tällaiseksi ei esimerkiksi voida laskea sähköistä lämpömittaria, jonka ainoana tehtävänä on kertoa lämpötila kysyttäessä. Hajautettua älyä sen sijaan olisi mittarilla, joka osaa ilmoittaa tavoitearvosta poikkeavasta lämpötilasta itsenäisesti. Toinen järjestelmän pääkomponentti, verkko, yhdistää laitteet toisiinsa. Laitteet yhdistävää verkkomediaa ei ole määrätty, joten kommunikoinnissa voidaan käyttää erilaisia tekniikoita jopa järjestelmien sisällä. Tärkeintä on valita kuhunkin tilanteeseen parhaiten soveltuva mediatyyppi. Maantieteellisesti hajautettuihin järjestelmiin kuuluu tyypillisesti myös muita komponentteja. Niitä ovat kiinteästi sovelluksen toimintaan tai järjestelmän hallintaan liittyvät järjestelmät. Sovelluksen toimintaan liittyvät järjestelmät voivat olla esimerkiksi tiedonkeruu- ja käsittelyjärjestelmiä. Hallintajärjestelmät liittyvät lähinnä järjestelmän toteutukseen ja toimintaan. Niillä ylläpidetään, valvotaan, konfiguroidaan ja päivitetään verkkoa ja sen muita komponentteja. Molemmat lisäkomponentit ovat tyypillisiä, mutta eivät pakollisia. Hallintajärjestelmien puuttuessa verkon solmut eivät ole keskitetysti hallittuja, vaan toimivat ad-hoc-periaatteella, kuten esimerkiksi tiedostojen jakamiseen tarkoitetut Freenet [FREE] ja Gnutella [GNUT]. Mediariippumattomuuden ansiosta järjestelmässä voidaan käyttää rinnakkaisia tiedonsiirtotapoja josta seuraa, että verkko on epähomogeeninen. Esimerkiksi kiinteän yhteyden katketessa voidaan turvautua varmentavaan langattomaan yhteyteen, josta seuraa, että siirtonopeus pienenee ja viive ja saatavuus saattavat vaihdella rajusti. Tämä asettaa järjestelmälle ja sen hallinnalle erityisiä vaatimuksia. 16

17 Esimerkkejä maantieteellisesti hajautetuista järjestelmistä Sähköverkon hallintajärjestelmä on tyypillinen esimerkki maantieteellisesti hajautetusta automaatiojärjestelmästä. Sähköverkon luotettava toiminta on kansallisesti ehdottoman tärkeää, joten sen toimintavarmuuteen on panostettava paljon. Verkossa on useita itsenäisesti toimivia komponentteja, joiden toiminta vaatii järjestelmältä paljon koordinointia. Koska laitteet ovat etäällä toisistaan, on olennaista, että ne toimivat varmasti kaikissa tilanteissa. Lisäksi on tärkeää, että laitteet ovat etähallittavia, sillä ongelmien sattuessa sähkökatkon pituus on huomattavasti lyhyempi, jos laitteita voidaan konfiguroida ja ohjata etäältä. Kolmas tärkeä vaatimus järjestelmälle on kattava tietoturva, sillä on erityisen tärkeää, ettei mikään ulkopuolinen taho pääse käsiksi sähkönjakeluun. Kommunikoinnissa käytetään hyvin erilaisia mediatyyppejä alkaen puheradioyhteydestä päätyen nopeaan LAN-yhteyteen. [Ko98] Toinen esimerkki maantieteellisesti hajautetusta järjestelmästä on tiesäähavaintoverkko. Järjestelmä koostuu teiden varsille sijoitetuista sääasemista, jotka mittaavat sääolosuhteita, kuten tien lämpötilaa ja liukkautta. Järjestelmään kuuluu sääasemien lisäksi ylemmän tason keskusjärjestelmä, joka hallitsee asemia ja kerää säätietoa niiltä. Järjestelmä voidaan perustella hajautetuksi, koska asemat ovat itsenäisiä yksiköitä. Ne analysoivat mittaustietoa ja lähettävät ylemmän tason järjestelmälle ainoastaan olennaisen osan siitä. Ylemmän tason järjestelmä käsittelee tietoa edelleen ja lähettää sen asiakkaalle, kuten Tiehallinnolle. Tärkeimpänä vaatimuksena järjestelmässä on laitteiden kattava etähallinta ylläpitokustannusten minimoimiseksi ja toiminnan takaamiseksi. Sääasemien manuaalinen läpikäynti laajassa havaintoverkossa, esimerkiksi vikaantumisen takia, olisi työlästä ja kallista. Tiedonvälitys asemien ja ylemmän tason järjestelmän välillä tapahtuu tieosuudesta riippuen kiinteää tai langatonta yhteyttä käyttäen. [VaIce] Kolmas esimerkki maantieteellisestä hajautuksesta on autoihin liitettävä tekstiviestijärjestelmä, joka turvatyynyn lauettua lähettää lähimpään hätäkeskukseen tekstiviestin. Viestistä voisi ilmetä esimerkiksi auton tyyppi, matkustajien määrä, auton sijainti, törmäyksen voimakkuus ja turvatyynyn laukeamisen ajankohta. Autossa oleva mobiililaite kokoaa tekstiviestin sisällön itsenäisesti auton tietojärjestelmästä saamiensa 17

18 tietojen perusteella ja voidaan siten ajatella hajautetuksi. Tällaisia järjestelmiä on autoihin tulossa jo lähitulevaisuudessa [Ti04]. Järjestelmän ehdottomana vaatimuksena on toimintavarmuus, sillä toimintakatkos kolarin hetkellä tekee järjestelmästä täysin hyödyttömän Maantieteellisen hajautuksen erityisvaatimukset Edellisten esimerkkien perusteella maantieteellisesti hajautetuille automaatiojärjestelmille löytyy muutama erityisvaatimus verrattuna paikallisesti hajautettuihin. Tärkeimpiä erityisvaatimuksia ovat kattava etähallinta ja tiukempi tietoturva. Kattavan etähallinnan avulla tehty ylläpito pienentää kustannuksia ja lisää järjestelmän toimintavarmuutta. Ylläpidolla tarkoitetaan laitteissa olevien ohjelmistojen elinkaarenhallintaa ja esimerkiksi ongelmatilanteista toipumista. Kun laitteistojen ohjelmistoalustat tukevat ohjelmistojen elinkaarenhallintaa, voidaan alustoille asentaa etäältä uusia ohjelmia, jotka lisäävät esimerkiksi toiminnallisuutta. Tämä tekee järjestelmästä joustavan mahdollistaen sen muunneltavuuden sopeutumaan muuttuviin tarpeisiin. Tietoturvaan on maantieteellisesti hajautetussa järjestelmässä kiinnitettävä erityistä huomiota, sillä niissä liikennöidään yleensä muiden hallinnoimissa verkoissa. Järjestelmään murtautuminen on helpompaa kuin paikallisesti hajautettuun, jossa liikennöidään useimmin suljetussa verkkoympäristössä palomuurien takana, jolloin järjestelmään käsiksi pääseminen on vaikeampaa. [CoDoKi01] 18

19 3. Mobiili Java Hajautetuissa mittaus- ja ohjausjärjestelmissä etälaitteen älykkyys on pystyttävä ohjelmoimaan niin, että se palvelee sekä mittaus- ja ohjaustarpeita että liittymistä laajemman järjestelmän osaksi. Perinteisten sulautettujen järjestelmien ohjelmointiin käytettyjen kielten, kuten C:n ja assemblyn lisäksi on nykyään olemassa etälaitteita, jotka tukevat Javaa. Mobiili Java on vakiintunut nimitys Java Community Processin (JCP) [JCP] kehittämälle määrittelylle toteuttaa mobiileihin ja muihin sulautettuihin laitteisiin soveltuvia langattomasti siirrettäviä ohjelmistoja. Se tuo sulautettuihin laitteisiin muutaman keskeisen edun käytössä oleviin perinteisiin tekniikoihin nähden, kuten siirrettävyyden, langattoman elinkaarenhallinnan ja tehokkaan ohjelmointikielen. Java 2 Platform, Micro Edition (J2ME) alusta yleisesti, sekä erityisesti Connected Limited Device Configuration (CLDC) konfiguraatio ja Information Module Profile (IMP) profiili ovat mobiililaitteisiin suunnitellun ohjelmistoalustan teknisiä määrittelyjä J2ME Sun Microsystems on jakanut Java 2 alustat (Java 2 Platform) kolmeen erikokoisille järjestelmille tarkoitettuun osaan, Enterprise Editioniin (J2EE), Standard Editioniin (J2SE) ja Micro Editioniin (J2ME). J2SE on PC-ympäristöön tarkoitettujen ohjelmistojen 19

20 toteutukseen suunniteltu alusta, joka sisältää virtuaalikoneen (JVM - Java Virtual Machine), kehitysympäristön ja suuren määrän valmiita ohjelmointirajapintoja. J2EE pohjautuu J2SE:n ja määrittelee tavan toteuttaa laajoja komponenttipohjaisia ja monitasoisia ohjelmistoja. J2ME sisältää tekniikoita ja standardeja, jotka on suunnattu pieniin laitteisiin, kuten kännyköihin ja PDA:hin sekä sulautettuihin järjestelmiin, kuten pesukoneisiin tai limsa-automaatteihin. Koska J2ME:n kohderyhmään kuuluvien laitteiden fyysiset ja toiminnalliset erot saattavat olla hyvin suuria, ohjelmien siirrettävyys ei ole mahdollista kaikkien J2ME laitteiden välillä. Jotta Javan kulmakivestä, siirrettävyydestä, ei ole jouduttu luopumaan on J2ME jaettu tarkennuksiin, joita kutsutaan konfiguraatioiksi ja profiileiksi. Mobiili Java nimitystä käytetään J2ME:n toisesta tähän mennessä määritellystä konfiguraatiosta CLDC:stä (Kuva 3. 1). [Sun2] Mobile Java IMP CDC CLDC J2EE J2SE J2ME Java Card APIs JVM KVM Card VM Kuva 3. 1 Java-alustat erikokoisille järjestelmille. 20

21 Siirrettävyys Ohjelmistojen siirrettävyys on ollut Java teknologioiden käytön suurimpia etuja työasemaja palvelinympäristössä [Sun3]. Koska Javalla toteutetut ohjelmat käännetään tavukoodiksi (engl. bytecode), jota virtuaalikone tulkkaa ohjelmaa ajettaessa, sen alla olevalla käyttöjärjestelmällä ei ole merkitystä. Tarkemmin asiaa käsitellään lähteessä [GoMcGi96]. Siirrettävyyden merkitys kasvaa, mitä enemmän erilaisia laitealustoja on. Laitteilla, jotka ovat J2ME-alustan kohderyhmässä, on hyvinkin erilaisia ominaisuuksia. Laitteessa voi olla näppäimistö, näyttö, verkkoyhteys ja kohtalaisen paljon muistia. Toisaalta saman kohderyhmän laitteella ei välttämättä ole mitään edellisistä. Esimerkkejä laitteista ovat digi-tv, uuni, pesukone, auton navigointilaitteisto ja matkapuhelin. Vaikkei siirrettävyys eri laitekategorioiden välillä olisikaan mahdollista tai edes järkevää, löytyy kategorioiden sisältä laitteita, joihin voidaan ja kannattaa tuottaa ohjelmistoja välittämättä niiden omien käyttöjärjestelmien eroavaisuuksista. Tarve sovellusten siirrettävyyteen tulee sulautetuissa järjestelmissä todennäköisesti olemaan vielä suurempi, kuin työasema- ja palvelinympäristöissä. [Ste] Koska laitteet ovat käyttötarkoitukseltaan, ominaisuuksiltaan ja kooltaan hyvin erilaisia, on J2ME-ohjelmien siirrettävyyden takaamiseksi määritelty konfiguraatiot ja profiilit, joiden mukaan toteutetut ohjelmat toimivat kaikissa niitä tukevissa laitteissa (Kuva 3. 2). Profile(s) Configuration Libraries JVM Host Operating System Kuva 3. 2 J2ME:n arkkitehtuuri. 21

22 Konfiguraatiot Konfiguraatio on teknologian määrittely, jota käytetään yhden tai useamman profiilin (3.1.3) perustana [CLDC10a]. Resursseiltaan erilaisille laitteille on omat konfiguraationsa, jotka JCP määrittelee. Konfiguraatio määrittelee laitekategorialle sopivan virtuaalikoneen, sovellusten hallinnan toiminnan, tietoturvan tason, erot Java-kieleen ja tarpeelliset luokkakirjastot [CLDC10a]. Konfiguraation tulee tarjota ohjelmistoille mahdollisimman toimiva alusta ja riittävät palvelut, jotta ohjelmistokehitys saadaan tehokkaaksi ja ohjelmistot luotettaviksi. Se ei kuitenkaan saa olla liian raskas kyseiselle laitekategorialle, jottei se vie kaikkia resursseja laitteelta. Esimerkiksi muistikapasiteetti on sulautetuissa järjestelmissä lähes poikkeuksetta rajallinen. Tällä hetkellä J2ME:n konfiguraatioita on määritelty kaksi: Connected Device Configuration (CDC) ja Connected Limited Device Configuration (CLDC). CDC on suunniteltu resursseiltaan pienille laitteille, joilla on verkkoyhteys. Tyypillisiä tähän konfiguraatioon kuuluvia laitteita ovat digi-tv, autojen navigointijärjestelmät ja kehittyneemmät kommunikointivälineet [Sun4]. CLDC on määritelty resursseiltaan hyvin pienille laitteille, kuten mobiililaitteille ja pesukoneille sopivaksi Profiilit Vaikka J2ME on jaettu konfiguraatioihin, voi saman konfiguraation sisällä olla toiminnallisuudeltaan hyvinkin erilaisia laitteita. Esimerkiksi CLDC määrittelee virtuaalikoneen ja luokkakirjastojen joukon niinkin erilaisille laitteille kuin matkapuhelin ja pesukone. Nämä laitteet voivat sisältää samanlaisen laitteiston (hardware) ja käyttöjärjestelmän konfiguraatiota varten, mutta niiden toiminnallisuus eroaa toisistaan selvästi. Tämän vuoksi konfiguraatiot on jaettu profiileihin. Profiili määrittelee rajapinnat ja luokkakirjastot kyseiselle laitteelle, jotta sen tarjoamat tarpeet ja mahdollisuudet saadaan mahdollisimman hyvin hyödynnettyä. Konfiguraatioiden tapaan profiilit määrittelee JCP. 22

23 CLDC-konfiguraation profiileista tunnetuin on Mobile Information Device Profile (MIDP), joka on matkapuhelimille suunniteltu profiili. Mobiili Java -ohjelmia ovat juuri matkapuhelimissa ajettavat Java-pelit ja muut Java-sovellukset. Laitteiden väliseen kommunikointiin suunniteltu IMP-profiili on MIDP:n osajoukko. Siitä puuttuvat vain näytön ja näppäimistön ohjaukseen tarkoitetut rajapinnat. CDC:n profiileita ovat puolestaan esimerkiksi Foundation Profile (FP) ja Personal Profile (PP). Molemmille konfiguraatioille on määritelty ja määritellään parhaillaan uusia profiileja, joten ajankohtainen tieto löytyy lähteestä [JCP] CLDC CLDC (JSR-30) on J2ME:n konfiguraation määrittely, joka on suunniteltu pienille langattomille laitteille, joilla on yksinkertainen käyttöliittymä, hyvin pienet muistiresurssit ja kapeakaistainen verkkoyhteys. Tyypillisiä tämän kaltaisia laitteita ovat matkapuhelimet ja PDA:t (Personal Digital Assistant). [Sun1] Yleistä CLDC määrittelee virtuaalikoneen, sovellusten hallinnan toiminnan, tietoturvan tason, erot Java-kieleen ja vaaditut luokkakirjastot. CLDC:tä tukevat laitteet voivat olla melko erilaisia, vaikka konfiguraatio onkin suunnattu tietyn kokoisille laitteille. Tämän vuoksi määrittely ei aseta laitteille muita kuin muistin riittävyyteen liittyviä laitteistovaatimuksia [CLDC10a]. Virtuaalikonetta ja CLDC:n kirjastoja varten on oltava 128 kilotavua haihtumatonta (non-volatile) muistia, eli pysyväismuistia. Javan ajoympäristölle ja olioille on puolestaan oltava vähintään 32 kilotavua haihtuvaa (volatile) muistia eli käyttömuistia. 1 Tässä työssä käsitellään CLDC:n versiota 1.0, vaikka versio 1.1. on jo julkaistu. Versio 1.1 tuo vain joitakin muutoksia, joten CLDC:n perusta on järkevämpi käsitellä alkuperäisen version avulla. Myös työn kannalta tärkein profiili IMP 1.0 on määritelty käyttämään CLDC:n versiota 1.0. Erot näiden versioiden välillä käsittelen kohdassa

24 Määrittelyn tekijöiden (JSR-30 Expert group) mukaan yksi tärkeimmistä Java tekniikoiden tuomista eduista pienten laitteiden maailmaan on dynaaminen ja turvallinen sovellusten lataaminen erilaisten verkkojen yli laitteille. Aiemmin kyseisiin laitteisiin, kuten matkapuhelimiin, oli kovakoodattu (hardcoded) tietyt ominaisuudet, mutta nyt laitevalmistajat etsivät ratkaisuja, joilla laitteista saataisiin laajennettavampia, jolloin ne voisivat toimia alustoina kolmansien osapuolien tuottamille ohjelmille. Määrittely ei kuitenkaan ota kantaa tapaan, jolla sovellukset siirretään laitteelle, se vain vaatii laitteelta tiettyjä ominaisuuksia, jotka mahdollistavat siirron. [CLDC10a] Konfiguraatio määrittelee joitakin eroja ohjelmointikielelle, pyrkien kuitenkin noudattamaan Java-kielen määrittelyä [GoJoSte96] mahdollisimman tarkasti. Erot Javakieleen ovat liukulukujen puute, olioiden hävittämistä ennen kutsuttavan finalize-metodin puute ja suppeampi valikoima rajapintoja poikkeusten hallinnalle. [CLDC10a] Konfiguraatio määrittelee myös sovellusten hallinnan (CLDC10a kohta 3.3) sekä sovellusten tietoturvan Virtuaalikone CLDC:n määrittelemä virtuaalikone on suunniteltu vastaamaan mahdollisimman suurelta osin PC-maailman Javan virtuaalikoneen (JVM) määrittelyä, josta enemmän lähteessä [LiYe99]. CLDC:n virtuaalikoneelle on kuitenkin jouduttu suunnittelemaan omia rajoituksia ja toiminnallisuuksia johtuen erityisesti sulautettujen laitteiden rajallisesta muistikapasiteetista [CLDC10a]. Merkittävimmät eroavaisuudet JVM:en verrattuna ovat liukulukutuen ja muutamien muiden ominaisuuksien puuttuminen sekä luokkatiedostojen varmennus (engl. verification), muoto ja niiden lataaminen. Liukulukutuki on jätetty konfiguraatiosta pois, koska tuki puuttuu suurimmasta osasta kohderyhmän laitteista ja sen lisääminen konfiguraatioon olisi kasvattanut virtuaalikoneen kokoa liikaa. Muista pois jätetyistä ominaisuuksista merkittävin on Java Native Interfacen (JNI) puute. CLDC ei tue JNI:a, koska se ei sovi konfiguraation tietoturvaan. CLDC:n tietoturva määrittelee niin kutsutun hiekkalaatikkomallin (engl. sandbox model), jonka mukaan sovellusta tulee ajaa suljetussa 24

25 ympäristössä. Rajapinnat, joita sovellus saa käyttää, tulee olla määritelty konfiguraatiossa, profiilissa tai laitteen tukemassa OEM-luokassa (OEM - Original Equipment Manufacturer) (Kuva 3. 3). Hiekkalaatikkomalli esitellään tarkemmin lähteen [CLDC10a] kohdassa IMP Applications CLDC IMP OEM-Specific IMP Applications OEM- Specific Classes Native Applications Native System Software Device Hardware Kuva 3. 3 Mobiililaitteen ohjelmistoarkkitehtuuri. Luokkatiedostojen varmennus on konfiguraatiossa suunniteltu niin, että tiedoston esivarmennus (engl. preverification) tehdään jo kehitysympäristössä ennen tiedoston siirtämistä laitteelle (Kuva 3. 4). Ajonaikainen varmennus tapahtuu esivarmennuksessa luotujen attribuuttien avulla. Viimeinen merkittävä ero JVM:en liittyy sovelluksen sisältävän luokan muotoon ja sen lataamiseen laitteelle. Jotta yksi Mobiili Javan tärkeimmistä ominaisuuksista, sovellusten dynaaminen lataaminen laitteelle, voitaisiin toteuttaa, on konfiguraatio määritellyt luokille tietyt ominaisuudet liittyen niiden muotoon ja lataamiseen. [CLDC10a] Ensimmäinen CLDC:lle toteutettu virtuaalikone K virtual machine (KVM) on äärimmäisen niukka (engl. lean) virtuaalikone. Virtuaalikone tarvitsee ainoastaan muutaman sata kilotavua muistia toimiakseen. [Sun1] 25

26 Development Workstation Target Device (KVM Runtime) MyApp.java Javac Download Verifier MyApp.class Preverifier Interpreter MyApp.class Kuva 3. 4 Sovelluksen verifiointi Mobiili Javassa CLDC 1.1 Toteutettaessa tehokkaita tiedonkeruujärjestelmiä, joissa mobiililaite toimii osana järjestelmää, tulisi Mobiili Java sovelluksilla olla tuki liukuluvuille. Tämä onkin suurin lisäys mitä CLDC:n versioon 1.1 on tullut. Suunnittelijoiden (JSR-139 Expert group) mielestä CLDC:n määrittelyyn ei tarvinnut tehdä merkittäviä muutoksia. Ryhmä oli yleisesti tyytyväinen edelliseen versioon. Tästä johtuen versio 1.1 on vain määrittelyn seuraava askel, joka on täysin taaksepäin yhteensopiva version 1.0 kanssa. [CLDC11a, kohta 1.2] Joitakin asioita uuteen määrittelyyn on kuitenkin lisätty. Tärkeimpänä pidetty uusi ominaisuus on tuki liukuluvuille. Luokat java.lang.float ja java.lang.double tuovat mahdollisuuden käsitellä liukulukuja valmiiden metodien avulla [CLDCAPI]. Myös muita 26

27 kirjastoluokkia on jouduttu muokkaamaan liukulukutuen vuoksi. Toinen tärkeä muutos on heikon viittauksen (engl. weak reference) lisääminen. Heikon viittauksen avulla ohjelma voi säilyttää viitteen olioon, jottei automaattinen roskienkeruu tuhoa sitä [Sun6]. Uuteen konfiguraatioon on tehty myös monia pienempiä muutoksia kirjastoihin sekä muutama uusi luokka, kuten java.util.calendar, java.util.date, java.util.timezone ja java.lang.noclassdeffounderror [CLDCAPI]. Myös edellisessä versiossa ilmenneitä virheitä on korjattu. Näiden muutosten, erityisesti liukulukutuen lisäyksen johdosta, vaatimus muistintarpeelle on noussut 160 kilotavusta 192 kilotavuun. [CLDC11a, kohta 1.2] 3.3. IMP Hajautettujen mittaus- ja ohjausjärjestelmien laitteiden toiminnallisuuden toteuttaminen ja laitteiden yhdistäminen laajempaan järjestelmään, voidaan toteuttaa noudattamalla CLDCkonfiguraatioon kuuluvaa IMP-profiilia. Profiili on suunniteltu yhä kasvaville tarpeille toteuttaa dynaamisia ja etähallittavia sovelluksia erilaisille sulautetuille ja hajautetuille järjestelmille. Tällaisissa järjestelmissä etälaitteeseen ollaan yhteydessä verkon yli, yleensä langattomasti. Laitteessa itsessään ei tarvitse olla rajapintaa käyttäjälle. Profiili ei siis tue rajapintoja näytölle, eikä näppäimistölle. Se onkin ainoa asia, joka erottaa profiilin MIDP-profiilista. IMP:n luokkakirjastojen joukko on siis osajoukko MIDP:n luokkakirjastojen joukosta. Profiilien muu toiminnallisuus on identtinen, koska IMP on määritelty käyttäen MIDP-profiilia perustana IMP-profiilin ominaisuudet Profiili määrittelee sovellusten toiminnallisuuden sulautetuille etähallittaville laitteille sisältäen rajapinnat muun muassa verkkoyhteyden hallinnalle, paikalliselle tietovarastolle ja sovelluksen elinkaaren hallinnalle [IMPIndex]. Profiilia noudattavassa laitteessa tulee olla 160 kilotavua vapaata muistia virtuaalikoneelle ja luokkakirjastoille. Sen tulee myös tukea langatonta tietoliikennettä. Laitteen käyttöjärjestelmältä profiili vaatii vain vähäisiä 27

28 ominaisuuksia. Sen tulee kuitenkin muun muassa kyetä huolehtimaan keskeytyksistä, poikkeuksista ja aikatauluttamisesta. Käyttöjärjestelmän tulee mahdollistaa normaalit muistiin ja ulkoiseen rajapintaan kohdistuvat luku- ja kirjoitusoperaatiot. Profiili vaatii myös sovelluksen elinkaaren hallinnalle tietyt tukitoiminnot, josta enemmän profiilin määrittelyn liitteessä [IMP1.0 liite A]. [IMP1.0, kohdat 2.11 ja 2.1.2] Arkkitehtuuri. Profiilin mukaisten laitteiden ohjelmistoarkkitehtuuri voi sovellusten kannalta jakaantua kolmeen osaan Kuva 3. 3 mukaisesti. Laitteessa voidaan ajaa IMlettien (IMP-sovellus) lisäksi valmistajakohtaisia rajapintoja käyttäviä OEM-IMlettejä sekä laitteen oman käyttöjärjestelmän päälle tehtyjä sovelluksia. Valmistaja voi siis suunnitella omia OEM-luokkakirjastoja esimerkiksi laitteen oman I/O rajapinnan käyttämiseksi. Siirrettävyys eri valmistajien laitteiden välillä on kuitenkin mahdollista vain, jos IMleteissä käytetään ainoastaan IMP-profiilissa määriteltyjä rajapintoja. [IMP1.0, luku 3] Liittyminen laajempaan järjestelmään. Laitteen liittäminen laajempaan järjestelmään voidaan IMP-profiilia tukevissa laitteissa toteuttaa TCP/IP-protokollan päälle HTTPyhteyden avulla. Yhteys voidaan muodostaa myös WAP:ia (Wireless Application Protocol) käyttäen. WAP sisältää HTTP/TCP/IP-pinon tyyppisen protokollan, jossa vastaa WSP (Wireless Session Protocol) ja TCP/IP:tä vastaa WTP (Wireless Transaction Protocol). Myös WAP:n kaltaista i-modea voidaan käyttää laajempaan järjestelmään liittymisen osana. [IMP1.0, luku 6] Sovellusten dynaaminen lataaminen. Yksi Mobiili Java järjestelmien tärkeimmistä ominaisuuksista on mahdollisuus siirtää IMlettejä verkon yli laitteelle (OTA over-theair Provisioning). J2ME:n konfiguraatiot ja profiilit eivät kuitenkaan ota kantaa tapaan, jolla sovellus siirretään verkon yli ylemmän tason järjestelmältä laitteelle. Mobiili Java toteutusten siis oletetaan tukevan sovellusten dynaamista siirtoa laitteelle, mutta määrittelyt eivät ota kantaa tekniikkaan, jolla siirto tehdään. Tämä johtuu siitä, että mahdollisia teknisiä ratkaisuja on useita. Toisaalta myös siirtotapaan vaikuttavia tarpeita on erilaisia. Näistä syistä johtuen olisi ollut mahdotonta määritellä standardoitua tapaa siirtää sovelluksia laitteelle. [MIDP1.0, kohta 2.2] 28

29 Erilaiset siirtotavat on jätetty laitevalmistajien ja mahdollisten muiden määrittelyjen vastuulle. Esimerkki julkisesta määrittelystä sovellusten siirron toteuttamiseksi on Sunin julkaisu Over The Air User Initiated Provisioning Recommended Practice for the Mobile Information Device Profile [Sun5]. Laitevalmistajat voivat siis kuitenkin toteuttaa sovellusten siirron haluamallaan tavalla. Esimerkiksi Nokian mobiililaitteiden käyttämä M2M (Machine To Machine) Gateway perustuu CORBA:an (Common Object Request Broker Architecture). Sen oliopyyntöjen välityksen (ORB - Object Request Broker) avulla voidaan IMlettejä siirtää langattomasti ylemmän tason järjestelmältä laitteelle [Nokia12c]. Muistiin tallentaminen. Profiili tarjoaa mahdollisuuden tallentaa tietoa laitteen muistiin ja käyttää sitä myöhemmin. Tallennus mekanismin nimi on Record Management System (RMS). Tallennuksilla on sama elinkaari kuin IMlet Suitella (IMlet Suite on usean IMletin nippu), eli ne ovat pysyviä kunnes IMlet Suite tuhotaan. IMletit voivat käyttää muistiin tallennettuja tietoja ristiin yhden IMlet Suiten sisällä. Toinen IMlet voi tallentaa esimerkiksi mittaustietoa, jota toinen IMlet käsittelee. Tallennusoperaatiot ovat atomistisia, synkronoituja ja sarjallistettuja, joten tieto pysyy turmeltumattomana (engl. corrupt) myös päällekkäisten tallennusyritysten jälkeen. Tieto tallennetaan muistiin tavutaulukkoina (engl. byte array). RMS tarjoaa valmiit rajapinnat tallennettavan tiedon muuntamiseen tavutaulukoiksi, joten tallennettava tieto voi olla minkä muotoista tahansa. [IMP1.0, luku 7] IMletin ajoympäristö ja hallinta IMP-profiili määrittelee sitä noudattaville sovelluksille (IMlet) ja mobiililaitteille tietyt ominaisuudet, jotka niiden tulee toteuttaa. Tällaisia ovat esimerkiksi se, miten IMlet on pakattu, kun se siirretään laitteelle, millainen ajoympäristö laitteella on sovellusta varten ja kuinka laite voi hallita sovellusta sen elinkaaren ajan [IMP1.0, sivu 23]. Tätä sovelluksen hallintaa ja sen elinkaarta käsittelevää mallia kutsutaan sovellusmalliksi (engl. application model). Sovelluksen hallintaohjelma (engl. application management software AMS) tarjoaa ympäristön, jonne IMlet voidaan asentaa, jossa se voidaan käynnistää ja pysäyttää, ja josta 29

30 se voidaan poistaa (Kuva 3. 5). AMS huolehtii myös virheistä, joita edellisten toimintojen suorituksen aikana mahdollisesti tapahtuu. [IMP1.0, kohta 8.2] resumerequest() Paused pauseapp() startapp() Activated notifypaused() destroyapp() notifyrequest() Stopped destroyapp() Kuva 3. 5 IMletin tilat ja tilasiirtymiset. [Top02] IMletit pakataan JAR-tiedostoiksi (Java Archive [JAR]). Yhdessä tiedostossa voi olla useampia IMlettejä ja niiden käyttämiä luokkakirjastoja. JAR-paketissa tulee olla myös JAR manifesti, joka määrittää IMlet Suiten tunnistamisessa ja asentamisessa tarvittavat tiedot AMS:lle. Sovelluksen kuvaaja (engl. application descriptor) puolestaan kertoo AMS:lle paketin sisältämien IMlettin sopivuuden kyseiselle laitteelle. [IMP1.0, kohta 8.4 ja 8.5] IMP-NG Ensimmäiset versiot MIDP- ja IMP-profiileista ovat osoittaneet niissä joitakin selviä puutteita. Käytännön tutkimustuloksia on saatu erityisesti MIDP-profiilin ominaisuuksien riittävyydestä, ensimmäisen määrittelyn valmistuttua jo yli kolme vuotta sitten (JSR-37, Final Release, ). MIDP:stä onkin jo julkaistu versio 2.0. IMP-profiilin toista 30

31 versiota lähdettiin määrittelemään melkein heti ensimmäisen version valmistuttua kesällä Kuten ensimmäinen IMP-profiili perustui ensimmäiseen MIDP-profiiliin, tulee toinen IMP perustumaan toiseen MIDP:iin. IMP-NG tulee siis olemaan MIDP 2.0 profiilin osajoukko. IMP-NG profiili tulee olemaan taaksepäin yhteensopiva IMP 1.0 version kanssa. IMP-NG profiiliin tulee muutamia tärkeitä ominaisuuksia, kuten sovellusten varmentaminen, joka mahdollistaa allekirjoituksella varmennetun IMletin pääsyn laitteen omiin rajapintoihin. Tämä ominaisuus on puuttunut IMP:n ensimmäisestä versiosta, jossa kaikkia IMlettejä ajetaan hiekkalaatikko-mallin mukaisessa rajapinnoiltaan rajoitetussa ympäristössä. Muita tärkeitä ominaisuuksia uudessa profiilissa tulee olemaan HTTPS-tuki, pieni ja tehokas XML-muunnin (Extensible Markup Language), verkkoyhteyksien muodostaminen Javan Socket-rajapintaa käyttäen sekä sovellusten dynaaminen lataaminen laitteelle. Englanninkielinen termi OTA provisioning kuvaa tätä toimintoa, joka on määritelty omassa julkaisussaan [Sun5]. JCP tulee sisällyttämään julkaisun IMP-NG profiilin määrittelyyn. [JCP, kohta JSR-228] 31

32 4. Mobiili Java hajautetuissa järjestelmissä Hajautetuissa mittaus- ja ohjausjärjestelmissä laitteiden liittäminen järjestelmän osaksi on luonnollinen edellytys sen toiminnalle. Esimerkiksi mittausdatan siirtäminen etälaitteilta asiakkaille vaatii kommunikointia laitteiden ja muun järjestelmän välillä. Laitteiden etähallintaa puolestaan vaaditaan nykyaikaiselta mittaus- ja ohjausjärjestelmältä elinkaarenhallinnan ja kustannustehokkuuden vuoksi. Mobiili Javan TCP/IP-tuki mahdollistaa PC-maailmassa kehitettyjen joustavien kommunikointitapojen käytön myös sulautetuissa järjestelmissä Liittyminen laajempaan järjestelmään Järjestelmäarkkitehtuuri vaikuttaa hajautetun järjestelmän ominaisuuksiin erityisen paljon. Erilaiset tavat jakaa vastuu järjestelmän eri osille vaikuttaa voimakkaasti sen suorituskykyyn, luotettavuuteen ja turvallisuuteen. Vastuuta voidaan keskittää johonkin verkon osaan erityisesti tai jakaa laajemmin hajautetuille komponenteille. [CoDoKi01] 32

33 Järjestelmäarkkitehtuurit Asiakas-palvelin -malli on tällä hetkellä käytetyin ja historiallisesti merkittävin hajautusmalli. Suurin osa Internetin hajautuksesta perustuu tähän malliin. Sen perusideana on keskittää toimintoja ja palveluja verkon yksittäisille solmuille (Kuva 4. 1). Näiden solmujen palveluja voivat järjestelmän muut komponentit käyttää verkon yli. Tällaisissa verkoissa palvelimien määrä on pienempi kuin asiakkaiden, eli toiminnot ja älykkyys on keskitettyä. [CoDoKi01] Client Result Invocation Server Result Client Result Invocation Client Kuva 4. 1 Perinteinen asiakas-palvelin malli. Mittaus- ja ohjausjärjestelmissä toiminnot ja palvelut hajautetaan eripuolille verkkoa, jolloin palvelimien määrä kasvaakin asiakaskomponentteja suuremmaksi (Kuva 4. 2). Ohjelmistoteknisesti hajautetut mittalaitteet toimivat kuitenkin yleensä asiakassovelluksina, johtuen niiden kevyemmistä vaatimuksista toiminnallisuuden ja resurssien kulutuksen osalta. 33