VAASAN YLIOPISTO TEKNIIKAN JA INNOVAATIOJOHTAMISEN YKSIKKÖ OHJELMISTOTEKNIIKKA Vesa Rantala TIETOLIIKENTEEN DYNAAMINEN REITITYS KAIVOSTEOLLISUUDEN TIETOVERKKOINFRASTRUKTUURISSA Diplomityö, joka on jätetty tarkastettavaksi diplomi-insinöörin tutkintoa varten Vaasassa 23.4.2018. Työn valvoja Professori Jouni Lampinen Työn ohjaaja DI Pirkka Tukeva 1 ALKUSANAT Tämä diplomityö on tehty Seinäjoella toimivalle Exertus Oy:lle. Osoitan suuret kiitok- set Juha Viitaselle ohjauksesta ja mielenkiintoisista keskusteluista, jotka tarjosivat ar- vokkaita näkökulmia diplomityötä varten. Suuret kiitokset myös Kimmo Hautalalle, jo- ka tarjosi asiantuntevia neuvoja tietoliikennetekniikkaan liittyvissä asioissa. Lisäksi kii- tän erityisesti Pirkka Tukevaa, joka auttoi hallinnollisissa asioissa ja asiakasyhteyksissä. Kiitos professori Jouni Lampiselle diplomityön eteenpäin viemisestä ja rakentavasta palautteesta. Kiitos perheelleni ja ystävilleni tuesta. Seinäjoella 22.4.2018 Vesa Rantala 2 SISÄLLYSLUETTELO ALKUSANAT 1 LYHENNELUETTELO 5 TIIVISTELMÄ 8 ABSTRACT 9 1 JOHDANTO 10 1.1 Tausta 10 1.2 Tavoitteet 11 1.3 Rakenne 11 1.4 Exertus oy 11 2 OHJAUSJÄRJESTELMÄ 13 2.1 Arkkitehtuuri 13 2.1.1 Exertuksen ohjausyksiköt 13 2.2 Tietoliikenne 14 2.2.1 REST-palvelin 15 2.2.2 Työkone 17 3 TIETOLIIKENNETEKNIIKAT 19 3.1 OSI-malli 19 3.2 TCP/IP-protokollaperhe 22 3.2.1 TCP/IP-protokollapino 22 3.2.2 TCP 23 3 3.2.3 IP 24 3.3 DHCP 27 3.4 DNS 28 3.5 NAT 29 4 SUUNNITTELU 31 4.1 Nykyinen tiedonsiirtojärjestelmä 31 4.2 Uusi tiedonsiirtojärjestelmä 32 4.2.1 Arkkitehtuuri yleisellä tasolla 35 4.3 Verkkoarkkitehtuuri 36 4.3.1 Työkone 36 4.3.2 ReDi 38 4.3.3 Välityspalvelin 40 4.3.4 Kokonaisuus 42 4.4 Laitteistoarkkitehtuuri 48 4.4.1 Reititin 48 4.4.2 Verkkokytkin 50 4.4.3 Ohjausyksikkö 50 4.5 Ohjelmistoarkkitehtuuri 51 5 ASENNUS 52 5.1 Työkone 53 5.1.1 Ohjausyksikkö 53 5.1.2 Reititin 53 5.2 Välityspalvelin 57 5.2.1 Tukiasemareititin 57 5.2.2 Ohjausyksikkö 60 4 5.2.3 Asiakasreititin 61 6 TESTAUS 65 6.1 Työkoneelta lähtevä tietoliikenne 65 6.2 Välityspalvelimelta lähtevä tietoliikenne 68 7 TULOKSET 70 7.1 Kehitysideat 72 8 JOHTOPÄÄTÖKSET 77 LÄHDELUETTELO 78 5 LYHENNELUETTELO ARP Address Resolution Protocol, fyysisen osoitteen loogisesta osoitteesta selvittävä tietoliikenneprotokolla ASCII American Standard Code for Information Interchange, mer- kistö CAN Controller Area Network, ajoneuvoissa käytettävä automaa- tioväylä CIDR Classless Inter-Domain Routing, luokaton reititys dBd Desibeliä verrattuna puoliaaltodipoliantenniin dBi Desibeliä verrattuna isotrooppiseen antenniin dBm Desibeliä verrattuna milliwattiin DHCP Dynamic Host Configuration Protocol, IP-parametrejä jakava tietoliikenneprotokolla DNAT Destination Network Address Translation, kohdeosoitteen- muunnos DNS Domain Name System, verkkotunnuksen IP-osoitteeksi muun- tava nimipalvelujärjestelmä EIRP Effective Isotropic Radiated Power, efektiivinen säteilyteho isotrooppisesta antennista ERP Enterprise Resource Planning, toiminnanohjausjärjestelmä (ERP-järjestelmä) FTP File Transfer Protocol, tiedostonsiirtoon tarkoitettu tietolii- kenneprotokolla HTTP Hypertext Transfer Protocol, WWW-tekniikassa käytettävä tietoliikenneprotokolla I/O Input/Output, sisäänmenoja ja ulostuloja sisältävä liitäntä IEEE 802.11 Langattomien lähiverkkojen standardi, jonka on standardisoi- nut Institute of Electrical and Electronics Engineers 6 IoT Internet of Things, esineiden internet IP Internet Protocol, IP-pakettien siirrosta vastaava tietoliikenne- protokolla ISO International Organization for Standardization, kansainvälinen standardisoimisjärjestö JSON JavaScript Object Notation, tiedonvälityksessä käytettävä tie- dostomuoto LAN Local Area Network, lähiverkko LED Light-Emitting Diode, hohtodiodi MAC Media Access Control, siirtoyhteyden varaava osakerros siir- toyhteyskerroksessa MQTT Message Queuing Telemetry Transport, kevyt tuottaja–tilaaja- protokolla NAT Network Address Translation, osoitteenmuunnos OSI Open Systems Interconnection, tietoliikennejärjestelmien toi- minnan kuvaamiseen käytetty kerrosmalli (OSI-malli) PoE Power over Ethernet, virransyöttö kierretyllä parikaapelilla Ethernet-lähiverkossa PWM Pulse-Width Modulation, pulssinleveysmodulaatio RARP Reverse Address Resolution Protocol, loogisen osoitteen fyy- sisestä osoitteesta selvittävä tietoliikenneprotokolla ReDi Remote Diagnostics, Exertus Oy:n kehittämä ja ylläpitämä telematiikkapalvelu REST Representational State Transfer, arkkitehtuurimalli ohjelmoin- tirajapinnoille RS232 Recommended Standard 232, sarjamuotoisen ja asynkronisen tiedonsiirron standardi SMTP Simple Mail Transfer Protocol, sähköpostiviestien välitykseen tarkoitettu tietoliikenneprotokolla SNAT Source Network Address Translation, lähdeosoitteenmuunnos 7 SSID Service Set Identifier, langattomassa lähiverkkotekniikassa käytettävä verkon nimimääritys TCP Transmission Control Protocol, yhteydellisen tiedonsiirtotien tarjoava tietoliikenneprotokolla TFT Thin-Film Transistor, ohutkalvotransistori UDP User Datagram Protocol, yhteydettömän tiedonsiirtotien tar- joava tietoliikenneprotokolla URL Uniform Resource Identifier, internetissä käytettävä osoitus- mekanismi USB Universal Serial Bus, sarjamuotoinen liitäntä WLAN Wireless Local Area Network, langaton lähiverkko WPA Wi-Fi Protected Access, langattomissa lähiverkoissa käytettä- vä salausmenetelmä WWW World Wide Web, tiedon jakoon tarkoitettu palvelu internetis- sä 8 VAASAN YLIOPISTO Tekniikan ja innovaatiojohtamisen yksikkö Tekijä: Vesa Rantala Diplomityön nimi: Tietoliikenteen dynaaminen reititys kaivosteollisuu- den tietoverkkoinfrastruktuurissa Valvoja: Professori Jouni Lampinen Ohjaaja: DI Pirkka Tukeva Tutkinto: Diplomi-insinööri Koulutusohjelma: Tietotekniikan koulutusohjelma Suunta: Ohjelmistotekniikka Opintojen aloitusvuosi: 2013 Diplomityön valmistumisvuosi: 2018 Sivumäärä: 82 TIIVISTELMÄ Esineiden internet mahdollistaa muun muassa erilaisten työkoneiden liittämisen interne- tiin. Tämän johdosta työkoneiden käytöstä voidaan kerätä dataa, jota voidaan hyödyntää monilla eri osa-alueilla. Esineiden internet edellyttää kuitenkin pääsyn internetiin ja vaativissa olosuhteissa internet-yhteyttä ei aina ole saatavilla tai se voi olla laadultaan huono. Yhteyden puuttumisesta huolimatta dataa pitäisi silti saada siirrettyä. Diplomityössä suunnitellaan ja toteutetaan eräänlainen liikkuva välityspalvelin kaivos- teollisuudessa käytettäville työkoneille. Työkoneilla on valmius lähettää dataa palveli- melle, mutta syvällä maan alla yhteyttä internetiin ei aina ole saatavilla. Tästä syystä työkoneilla pitäisi nousta maan pinnalle datan lähetystä varten, mikä ei ole kaivostoi- minnan kannalta käytännöllistä. Sen sijaan työkoneet voisivat lähettää datansa välitys- palvelimelle, joka sitten kuljettaisi datan ylös kaivoksesta ja lähettäisi ne oikealle palve- limelle internetiin. Välityspalvelimen suunnitteluun ja toteutukseen liittyvät keskeisenä osana TCP/IP-protokollaperhe ja osoitteenmuunnos. Osoitteenmuunnoksen avulla väli- tyspalvelin saadaan näyttäytymään oikeana palvelimena työkoneille. Diplomityössä keskitytään välityspalvelinjärjestelmän laitteisto- ja verkkoarkkitehtuuriin ohjelmisto- arkkitehtuurin jäädessä pienempään osaan. Välityspalvelin toteutettiin siten, että se sisältää elementtejä työkoneesta ja oikeasta pal- velimesta. Välityspalvelimen verkko rakennettiin yleiskäyttöiseksi siten, että sitä voi- daan käyttää tulevaisuudessa myös muissa järjestelmissä sellaisenaan. Lisäksi työko- neissa käytettävään ohjausjärjestelmän ohjelmistoarkkitehtuuriin ei tarvinnut tehdä muutoksia, sillä järjestelmä toteutettiin laitteisto- ja verkkoarkkitehtuuri edellä. Tulok- sena syntyi toimiva välityspalvelin, joka voi siirtää dataa langattomasti työkoneilta oi- kealle palvelimelle internetiin. Lisäksi uuden järjestelmän arkkitehtuuri mahdollistaa sen, että sitä voidaan käyttää myös ilman välityspalvelinta. Näin uuden järjestelmän vä- lityspalvelin ei ole välttämätön kaivostyömaalla, jossa internet-yhteys on muuten hel- posti saatavilla. AVAINSANAT: esineiden internet, dynaaminen reititys, välityspalvelin, kaivosteolli- suus 9 UNIVERSITY OF VAASA School of Technology and Innovations Author: Vesa Rantala Topic of the Thesis: Dynamic Routing in Data Network Infrastructure of Mining Industry Supervisor: Professor Jouni Lampinen Instructor: M.Sc. (Tech.) Pirkka Tukeva Degree: Master of Science in Technology Degree Programme: Degree Programme in Information Technology Major: Software Engineering Year of Entering the University: 2013 Year of Completing the Thesis: 2018 Pages: 82 ABSTRACT Internet of Things makes it possible to connect different sorts of work machines to the Internet so that data can be gathered from them. Gathered data can then be used in a wide range of applications. However, Internet of Things requires Internet access and it is not always available in certain environments. Despite the lack of Internet access there is still need to transfer data to the Internet. The aim of this thesis was to develop a type of mobile proxy server for work machines used in mining industry. Work machines are able to transmit data to a server but in a deep mine Internet connection cannot always be established. Therefore, work machines must be brought out from the mine so that they can establish an Internet connection and transmit their data. In the case of mining this is very impractical procedure. Instead, work machines could transmit their data to a proxy server that would be able to carry the data out of mine and transmit it to the actual server when Internet connection is available. TCP/IP protocol suite and network address translation are key techniques to be used in the proxy server. With the help of network address translation, it is possible to make proxy server act as a real server to the work machines. The thesis focuses on hardware and network architecture while software architecture is discussed only in brief. The proxy server was implemented so that it contains elements from a work machine and from the real server. Network architecture of the proxy server was developed so that it is general-purpose and can be used with other systems as well in the future. In addi- tion, there is no need to modify the control system used in work machines because of the hardware architecture of the new system. The result of this thesis is functional proxy server which can transfer data wirelessly from the work machines to the real server. The architecture of the new system makes it also possible to use it without the proxy server. If there is no need for proxy server and the Internet connection is available the proxy server can be omitted from the system. KEYWORDS: internet of things, dynamic routing, proxy server, mining industry 10 1 JOHDANTO Internetiin yhdistetään nykyään tavanomaisimmatkin laitteet. Tämä esineiden internet mahdollistaa monia asioita, mutta sen myötä syntyy myös uusia ongelmia ratkaistavak- si. Esineiden internetin esineet voivat olla mitä vain laitteita, jotka voidaan yhdistää in- ternetiin. Yleisesti kuitenkin tarkoitetaan sellaisia laitteita, joita ei ole aiemmin ollut tar- koitus yhdistää internetiin. Tämä rajaa esimerkiksi puhelimet pois esineiden internetistä. Esineiden internetiin voidaan siten katsoa kuuluvan esimerkiksi erilaiset työkoneet. Työkoneiden tapauksessa halutaan yleensä reaaliaikaista dataa sen hetkisestä tilanteesta työmaalla tai käyttötietoja itse työkoneesta. Datan kerääminen työkoneilta toteutuu ny- kypäivänä melko vaivattomasti hyvien internet-yhteyksien vuoksi. Dataa ei kuitenkaan voida kerätä alueilla, joilla internet-yhteyttä ei ole lainkaan saatavilla tai se on laadul- taan huono. Tällaisia alueita voivat olla esimerkiksi erämaat ja kaivokset. Kaukana erä- maassa voi kuitenkin olla yhteys satelliitin kautta. Sen sijaan kaivoksissa, jotka ulottu- vat syvälle maan alle, ei internet-yhteyttä voida muodostaa, ellei kaivokseen ole sitä varten rakennettu verkkoinfrastruktuuria. Edellä mainittu tilanne on hyvä esimerkki esi- neiden internetin mahdollistamasta toiminnasta, joka tuo mukanaan uuden ongelman. 1.1 Tausta Seinäjoella toimiva Exertus oy sai asiakkaaltaan Normet oy:ltä tilauksen kehittää erään- lainen tiedonsiirtojärjestelmä, joka pystyisi keräämään kaivostyökoneiden tuottaman datan ja lähettämään sen eteenpäin internetissä sijaitsevalle palvelimelle. Uusi järjestel- mä olisi tarkoitus liittää tällä hetkellä käytössä olevaan ohjausjärjestelmäperheeseen ni- meltä Norsmart. Normetin työkoneiden Norsmart-ohjausjärjestelmä voidaan tällä het- kellä kytkeä internetiin ja ohjausjärjestelmä voi lähettää reaaliaikaista dataa työkoneesta internetissä sijaitsevalle palvelimelle. Normetin työkoneita käytetään usein kaivoksissa syvällä maan alla, jossa ei aina ole internet-yhteyttä saatavilla riippuen siitä, onko kai- vokseen rakennettu tarkoitukseen sopiva verkkoinfrastruktuuri. Verkkoinfrastruktuurin puuttuessa data ei liiku kaivoksen työkoneilta palvelimelle reaaliaikaisesti, eikä välttä- mättä ollenkaan, jos työkoneet eivät pääse välillä maan pinnalle lähettämään dataa. 11 Työkoneiden ohjausjärjestelmissä on rajallinen muisti dataa varten ja jossain vaiheessa vanhempaa dataa alkaa tuhoutua uuden tilalta, jos dataa ei saada välillä lähetettyä palve- limelle. Uuden järjestelmän olisi tarkoitus korjata tämä ongelma siten, että kaivoksessa eräänlainen ajoneuvo keräisi työkoneilta niiden tallentaman datan. Tällä ajoneuvolla voitaisiin sitten nousta välillä maan pinnalle, jolloin se voisi lähettää kaikilta työkoneilta keräämänsä datan palvelimelle. Järjestelmän ei kuitenkaan tarvitsisi olla reaaliaikainen. Pääasia olisi se, että data saataisiin talteen, eikä työkoneilla tarvitsisi nousta maan pin- nalle pelkästään datan lähetystä varten. 1.2 Tavoitteet Diplomityössä käsitellään pääasiassa uuden järjestelmän laitteisto- ja verkkoarkkiteh- tuuria. Päätavoite on rakentaa tietoliikenteen näkökulmasta toimiva tiedonsiirtojärjes- telmä kaivostyökoneiden käyttöön siten, että dataa saadaan siirrettyä työkoneilta palve- limelle. Ohjelmistoarkkitehtuuria käsitellään tämän tukena ylemmällä tasolla, mutta yk- sityiskohtainen tutkimus tähän liittyen rajataan diplomityön ulkopuolelle. 1.3 Rakenne Ensimmäisenä esitellään järjestelmä, johon tavoitteen mukainen lopputulos on tarkoitus yhdistää. Tämän jälkeen käsitellään asiaan liittyvää teoriaa ja käsitteistöä. Tavoitteen mukaisen järjestelmän arkkitehtuuri ja suunnitelma esitellään ennen itse järjestelmän rakentamista ja testausta. Lopuksi esitellään tulokset ja kehitysideat. 1.4 Exertus oy Exertus oy on perustettu vuonna 2003 ja on riippumaton palveluyritys, jonka päätavoit- teena on auttaa asiakkaita tekemään tuotteistaan älykkäämpiä. Exertuksen ydinosaami- nen liittyy CAN-väylällä hajautettujen ohjausjärjestelmien hallintaan. Asiakkaille voi- 12 daan tarjota pienempiä osa-alueita tai kokonaisvaltainen ohjausjärjestelmä. Palvelukon- septi kattaa myös esisuunnittelun, konsultoinnin, määrittelyn, toteutuksen, koulutuksen ja ylläpidon. (Exertus oy 2018.) 13 2 OHJAUSJÄRJESTELMÄ 2.1 Arkkitehtuuri Normetin työkoneissa on käytössä älykäs ohjausjärjestelmä nimeltä Norsmart. Se koos- tuu Exertuksen kehittämistä ohjausyksiköistä, näytöistä ja työkoneen laitteistosta. Ohja- usjärjestelmää varten on ohjausyksiköille räätälöity ohjelmisto, joka sisältää ohjauslo- giikan ja käyttöliittymän. 2.1.1 Exertuksen ohjausyksiköt Norsmart-ohjausjärjestelmän ytimenä on Exertuksen kehittämä ohjausyksikkö MIC1100S. Käyttöjärjestelmänä siinä on sulautettu Linux, joka perustuu Debian- jakeluun. Ohjausyksikön I/O-liitännästä löytyy monenlaisia sisäänmenoja ja ulostuloja. Näihin kuuluvat digitaaliset sisäänmenot ja -ulostulot, analogiset sisäänmenot, puls- sisisäänmenot ja PWM. Laitteessa on myös Ethernet, USB, RS232, CAN sekä näyttö- ja komposiittivideoliitännät. (Exertus oy 2017a: 2–6.) Tässä ohjausyksikössä ei ole omaa näyttöä, mutta sen kanssa voidaan käyttää erillistä näyttöä, kuten liitännöistä huomataan. Tähän tarkoitukseen sopivat Exertuksen näytöt RD121S2 sekä kooltaan pienempi RD084S2. Molemmat ovat TFT-näyttöjä ja niiden resoluutio on 800x600 (Exertus oy 2017b: 2, 2017c: 2). MIC1100S voidaan tarvittaessa korvata Exertuksen uudemmilla ohjausyksiköillä, joita ovat MIC2000S ja MID070S. Ohjausyksikölle voidaan asentaa Exertuksen Guitu-ohjelmalla rakennettu sovellus, jos- sa on graafinen käyttöliittymä ja ohjauslogiikka. Ohjauslogiikka voidaan ohjelmoida myös suoraan C-ohjelmointikielellä ja sitä käytetäänkin Norsmart-ohjausjärjestelmässä hyvin paljon. Yleensä tarvitaan myös I/O-moduuleja, sillä yksittäisen ohjausyksikön I/O-liitäntä har- voin riittää kokonaiselle työkoneelle. Moduulit ja ohjausyksiköt ovat yhteydessä toisiin- 14 sa CAN-väylän kautta. I/O-moduulit ottavat vastaan syötteitä ja ohjaavat työkoneen lait- teita sekä lähettävät tietoa ohjausyksikölle ohjausjärjestelmän käyttöön. Esimerkiksi ku- vassa 1 ohjaimelta menee tieto sisäänmenoon I/O-moduulille HCM3100, josta tieto me- nee CAN-väylää pitkin ohjausyksikölle. Sieltä menee tieto I/O-moduulille HCM2000, jonka ulostulo sitten ohjaa hydrauliikkaa. HCM2000 voi vielä lähettää ohjausyksikölle tiedon esimerkiksi männän asennosta sylinterissä. I/O-moduulit eivät ole ohjelmoitavia, vaan niissä on tarvittava ohjelma valmiina. Exertuksella on useita I/O-moduuleita, jotka soveltuvat eri käyttötarkoituksiin. Kuva 1. Norsmart-ohjausjärjestelmän arkkitehtuuri (Exertus oy 2009: 1). 2.2 Tietoliikenne Diplomityön käytännön osuuden kannalta on oleellista tietää, miten Norsmart- ohjausjärjestelmän tietoliikenne toimii. Tietoliikenteen puolella ohjausjärjestelmässä käytetään Exertuksen kehittämää ja ylläpitämää ReDi-palvelua. Se tarjoaa telematiikka- ratkaisuja työkoneisiin, joissa on Exertuksen ohjausjärjestelmä. Se mahdollistaa kak- sisuuntaisen tiedonsiirron työkoneen ohjausjärjestelmän ja asiakkaan järjestelmien välil- lä. Sen avulla voidaan esimerkiksi muodostaa salattu etäyhteys työkoneeseen internetin välityksellä, jolloin työkoneen mahdollisista vikatilanteista saadaan tietoa jo ennen kuin paikan päälle mennään, mikä tietenkin nopeuttaa huoltotoimenpiteitä. Työkoneen kul- jettajaa voidaan myös opastaa etäyhteyden avulla, sillä molemmissa päissä nähdään sa- 15 ma käyttöliittymä. ReDi-palvelu mahdollistaa datan keräämisen työkoneilta ja datan analysoinnin. Tämä big data sisältää tietoja työkoneen käyttöasteesta, eli esimerkiksi siitä kauanko työkone on ollut käynnissä ja kauanko sillä on tehty työtä sen ollessa käynnissä. Näihin liittyvät myös polttoaineen kulutus ja ajettu matka. Lisäksi voidaan tarkkailla työkoneen apulaitteiden kuntoa. (Exertus oy 2016: 2–3.) ReDi-palvelun arkki- tehtuuri yleisellä tasolla nähdään kuvasta 2. Kuva 2. Exertuksen ReDi-palvelun arkkitehtuuri (Exertus oy 2016: 3). 2.2.1 REST-palvelin Kuvassa 3 on nähtävillä tarkempi kuvaus ReDi-palvelusta. Kuvasta nähdään, että tieto kulkee työkoneen ja ReDi-palvelun palvelimen välillä. Palvelimelta on yhteys asiak- kaan ERP-järjestelmään ja toimistotietokoneille. Palvelinta ylläpitää Exertus ja sen tar- koituksena on käsitellä työkoneelta tulevaa raakaa dataa siten, että se saapuu asiakkaan järjestelmään oikeassa muodossa ohjelmointirajapinnan kautta (Exertus oy 2016: 2). ReDi-palvelun avulla saadaan tietoa myös järjestelmän toimivuudesta, sillä ReDi- palvelun ja sen palvelimen toiminta pysyy lähestulkoon aina samanlaisena. Jos tiedon kulku vikaantuu, voidaan palvelimen avulla rajata vika työkoneen ohjausjärjestelmään tai asiakkaan ERP-järjestelmään. ReDi-palvelun palvelin on rakennettu REST- 16 arkkitehtuurin mukaisesti ja se on tarkoitettu datan keräämiseen kaikenlaisilta työko- neilta. Koska kyseessä on REST-arkkitehtuurin mukainen palvelin, niin sitä voidaan käyttää sellaisenaan ilman muutoksia kaikilla Exertuksen ohjausjärjestelmillä. Kuva 3. Yhteydet Exertuksen ReDi-palvelussa (Exertus oy 2016: 2). REST-ohjelmointirajapinnan periaatteita ovat hyvä suorituskyky, skaalautuvuus, yksin- kertaisuus, siirrettävyys ja muokattavuus (Yellavula 2017: 9). REST-rajapintaan liitty- viä rajoitteita ovat asiakas–palvelin-malliin perustuva arkkitehtuuri, yhtenäinen rajapin- ta, kerroksittainen järjestelmä, välimuisti, tilattomuus ja ladattava koodi. Näiden rajoit- teiden katsotaan täyttävän WWW:n kehitykselle asetetut vaatimukset. Edellä mainitut rajoitteet täytyy siis löytyä järjestelmästä, jotta sitä voidaan kutsua REST-arkkitehtuurin mukaiseksi. (Massé 2011: 2–5.) REST-rajapinnassa tietojen lähetys ja vastaanotto ovat hyvin yksinkertaisia toimenpiteitä, sillä jokainen REST-rajapinnan kutsu liittyy URL- osoitteeseen ja HTTP-metodeihin, joista yleisimmin käytössä ovat GET, POST, PUT, PATCH, DELETE ja OPTIONS (Yellavula 2017: 11–12). 17 Myöhemmässä vaiheessa käytämme Exertuksen REST-palvelinta yhteyden testaami- seen. Yhteyttä testataan lähettämällä palvelimelle dataa POST-metodilla. Palvelin vas- taa POST-pyyntöön sen perusteella hyväksyykö se vastaanottamansa datan. Jos palvelin hyväksyy datan, palvelin tallentaa sen tietokantaan ja lähettää vastauksen pyynnön lä- hettäjälle, jossa se kertoo toiminnon onnistuneen. Jos taas data on vääränlaista, palvelin ei tallenna sitä ja ilmoittaa pyynnön lähettäjälle, että data ei ole oikeassa muodossa. Muita REST-rajapinnan mukaisia HTTP-metodeja ei tällä kertaa tarvita. 2.2.2 Työkone ReDi-palvelussa tieto liikkuu siis työkoneen ohjausjärjestelmästä Exertuksen REST- palvelimelle ja sieltä edelleen asiakkaan järjestelmiin. Tarkastellaan tiedon kulkua Normetin työkoneen Norsmart-ohjausjärjestelmästä ReDi-palvelun REST-palvelimelle. Pääpiirteet järjestelmän tästä osasta nähdään kuvasta 4. Kuva 4. Tietoliikenne Norsmart-ohjausjärjestelmässä (Exertus oy 2013: 6). Ohjausjärjestelmä kerää dataa työkoneesta sitä varten rakennettuun rengaspuskuriin. Dataa voidaan varastoida hetkellisesti pitkäänkin, jos internet-yhteyttä ei ole saatavilla 18 ja dataa ei pystytä lähettämään. Rengaspuskurin koko on siitä huolimatta rajallinen ja jossain vaiheessa vanhempaa dataa alkaa kadota, jos työkone on ollut pitkään ilman in- ternet-yhteyttä. Työkoneen ohjausjärjestelmään on yhdistetty Ethernetillä standardin IEEE 802.11 mukainen langaton reititin tai silta tilanteesta riippuen. Näin työkoneen ohjausjärjestelmä voi yhdistyä kaivoksen tai tehtaan langattomaan verkkoon. Tämä lan- gaton verkko taas on yhdistetty internetiin ja sitä kautta data kulkee ReDi-palvelun REST-palvelimelle. Työkoneen ohjausjärjestelmä kokoaa lähetettävän datan JSON- formaatin mukaiseen tekstitiedostoon. (Exertus oy 2013: 6–8.) JSON-formaatti helpot- taa datan käsittelyä myöhemmin, sillä siitä on muodostunut eräänlainen de facto - standardi IoT-alalla (Korotkevitch 2016: 241). Yhteenvetona ReDi-palvelun palvelin on siis REST-arkkitehtuurin mukainen palvelin, jonne työkoneen ohjausjärjestelmä lähet- tää datan JSON-muodossa käyttäen POST-metodia (Exertus oy 2013: 6–8). 19 3 TIETOLIIKENNETEKNIIKAT Diplomityössä keskitytään laitteistoon ja verkon suunnitteluun, joten on tarpeellista käydä läpi suunnittelussa ja toteutuksessa tarvittavien tekniikoiden teoriaa. Tähän liitty- vät erityisesti erilaiset tietoliikenneprotokollat. Seuraavaksi käsiteltäviä tekniikoita tul- laan soveltamaan uuden järjestelmän rakentamisessa. 3.1 OSI-malli OSI-malli on ISO:n määrittelemä standardi ja se tulee sanoista Open Systems Intercon- nection. Sen tarkoituksena on ollut tarjota laitevalmistajille ja käyttäjille sellainen ym- päristö, jossa järjestelmät olisivat yhteensopivia ja kykenisivät kommunikoimaan kes- kenään. Tähän tavoitteeseen ei ole päästy, eikä sen mukaisia järjestelmiä ole juurikaan käytössä. OSI-mallia käytetään kuitenkin tietoliikennejärjestelmien toiminnan kuvaami- seen, johon se sopii erityisen hyvin ja se onkin laajasti käytössä tässä tarkoituksessa. (Kaario 2002: 18; Hakala & Vainio 2005: 138.) OSI-mallissa tietojärjestelmälle on määritelty seitsemän eri perustehtävää ja ne kuva- taan kerroksina. Kerrokset yhdestä kolmeen liittyvät laitteistoon ja niiden käyttämiin protokolliin. Näitä kerroksia kutsutaan alakerroksiksi. Ylemmät kerrokset seitsemänteen kerrokseen asti sen sijaan määrittelevät asiakas–palvelin-sovelluksen toiminnan ohjel- mallisesti. (Hakala & Vainio 2005: 138.) Käydään kerrokset läpi yksitellen alimmasta kerroksesta ylimpään kerrokseen. Alin kerros on nimeltään fyysinen kerros. Se hoitaa bittien fyysisen käsittelyn, eli sen avulla määritellään sähköiset arvot signaalinsiirtoon. Fyysisellä kerroksella verkon ak- tiivilaitteita ovat esimerkiksi keskitin ja toistin. (Hakala & Vainio 2005: 139.) Siirtoyhteyskerros määrittelee, miten datasta rakennetaan siirrettäviä yksiköitä, kuten kehyksiä ja soluja. Siirtokerros määrittelee myös lähettävän ja vastaanottavan osapuolen 20 fyysiset laiteosoitteet eli MAC-osoitteet. Siirtokerroksen laitteita ovat esimerkiksi verk- kokortti, silta ja kytkin. (Hakala & Vainio 2005: 139.) Kolmas kerros eli verkkokerros määrittelee tietoliikenteen reitittämisen. Tämä kerros ei välitä verkon fyysisestä rakenteesta ja tekniikasta, kunhan tieto vain kulkee alempien kerrosten kautta. Protokolla, jota tällä tasolla yleisesti käytetään, on IP. Tämän kerrok- sen tärkein laite on reititin, joka reitittää IP-paketit kohdeverkkoon. (Hakala & Vainio 2005: 139.) Neljäs kerros ja samalla ylemmän kerroksen ensimmäinen kerros tunnetaan nimellä kul- jetuskerros. Tähän kerrokseen liittyvät keskeisesti kuljetusprotokollat, joista yleisimpiä ovat TCP ja UDP. TCP on yhteydellinen protokolla, ja UDP on yhteydetön protokolla. Tällä tasolla protokollien tehtävänä on tehdä sovellusten tietovirroista pienempiä yksi- köitä eli paketteja. Tiedon pilkkominen, pakettikoon määritys ja kuittaus muodostavat yhdessä kokonaisuuden nimeltä vuonohjaus, jonka yhteydelliset protokollat ottavat huomioon. Lisäksi yhteydellistä protokollaa käytettäessä tämä kerros huolehtii yhteyden muodostamisesta ja purkamisesta. Yhteydetön protokolla huolehtii tietovirran pilkkomi- sesta, mutta ei muusta vuonohjauksesta. (Hakala & Vainio 2005: 139–140.) Istuntokerros huolehtii käyttöoikeuksien tarkistuksesta ja muista järjestelmän suojauk- sista. Sen tehtäviin kuuluu tarjota kirjautumisrutiinit ja salausmenetelmät sekä huolehtia lukituksista. Nykyään monista istuntokerroksen tehtävistä huolehtii käyttöjärjestelmä. (Hakala & Vainio 2005: 140.) Esitystapakerros määrittelee muodon asiakkaan ja palvelimen väliselle sanomaliiken- teelle. Näitä ovat erilaiset koodausjärjestelmät, kuten esimerkiksi merkistö ASCII. Myös tämän kerroksen tehtävistä suurin osa hoidetaan nykyään käyttöjärjestelmässä. (Hakala & Vainio 2005: 140.) Mallin ylin kerros on sovelluskerros, joka määrittelee sovellusten ja käyttöjärjestelmien toimintojen ne osat, joita alemmissa kerroksissa ei ole määritelty. Se on siten rajapinta sovelluksia varten. Tavanomaisia palveluja ovat esimerkiksi Telnet, FTP ja SMTP. Ku- 21 ten edellä mainittiin, on istunto-, esitystapa- ja sovelluskerros nykyään ohjelmallinen kokonaisuus käyttöjärjestelmissä, eikä niiden erottaminen ole aina mahdollista. (Hakala & Vainio 2005: 140–141.) Kerrosten nimet ja niiden välinen liikenne nähdään kuvasta 5. Kuvassa on havainnollis- tettu tietovuo lähettäjältä vastaanottajalle. Loogisella tasolla tieto siirtyy samantasoisten kerrosten välillä, kun taas fyysisellä tasolla tieto kulkee ainoastaan fyysisten kerrosten välillä. Ylemmästä kerroksesta alempaan tieto siirretään sen sijaan palvelupyynnöillä. Sanomaa vastaanotettaessa esitetään lukupyyntö alemmalle kerrokselle, jolloin saadaan kuittauksena vastaanotettu sanoma. (Granlund 2007: 10.) Kuva 5. Tiedon siirto OSI-kerrosmallissa (Granlund 2007: 11). 22 3.2 TCP/IP-protokollaperhe TCP/IP-protokollaperheestä puhuttaessa on hyvä eritellä yksittäiset protokollat TCP ja IP, sillä usein tätä protokollien yhdistelmää kutsutaan virheellisesti yhdeksi protokollak- si. Yhdessä TCP ja IP muodostavat siis TCP/IP-protokollaperheen. Lisäksi tähän proto- kollaperheeseen kuuluu myös muita jäsenprotokollia sovellus-, kuljetus-, verkko- ja siir- toyhteysprotokollista. TCP/IP-verkossa toiminnan lähtökohtana on verkkojen välinen tietoliikenne, eikä esimerkiksi yksilölliset laitteiden osoitteet. Hierarkkiset nimi- ja osoi- tejärjestelmät määrittelevät sekä verkon että laitteen sijainnin verkossa ja reitityksen avulla tieto liikkuu eri arkkitehtuurien mukaisten osaverkkojen välillä. Osoitteina käyte- tään loogisia osoitteita, jotka on määritelty laitteille ohjelmallisesti. Itse laitteet sijaitse- vat sitten jossain verkossa, jossa on käytössä fyysiset laiteosoitteet eli MAC-osoitteet. (Hakala & Vainio 2005: 178.) Loogisen osoitteen ja MAC-osoitteen välisestä muunnok- sesta huolehtivat protokollat ARP ja RARP (Kaario 2002: 63). 3.2.1 TCP/IP-protokollapino Koska TCP/IP-protokollaperhe liittyy jollain tapaa kaikkiin OSI-mallin kerroksiin, on sillä myös OSI-mallin kaltainen kerrosmalli eli TCP/IP-protokollapino. Siihen kuuluu viisi kerrosta, jotka ovat fyysinen-, siirto-, verkko-, kuljetus- ja sovelluskerros. Näistä kahta ensimmäistä kerrosta voidaan kuvata myös yhtenä kerroksena, sillä kuten OSI- mallin yhteydessä mainittiin, verkkokerroksen alla voi olla melkein mikä verkkotek- niikka tahansa. Täten TCP/IP-protokollaperhe toimii oikeastaan verkkokerrokselta ylöspäin, sillä fyysisen kerroksen ja siirtokerroksen asioita ei suoraan määritellä. TCP/IP-protokollapinon kerroksien suhde OSI-mallin kerroksiin nähdään kuvasta 6. Kuten kuvasta havaitaan, niin TCP/IP-protokollapinon kerrokset voivat vastata useam- paa kerrosta OSI-mallista. Esimerkiksi sovelluskerros käsittää jopa kolme kerrosta OSI- mallista. TCP/IP-protokollapino helpottaa siis TCP/IP-protokollaperheen käsittelyä, kun sitä voidaan verrata OSI-malliin. (Kaario 2002: 21–22.) 23 Kuva 6. TCP/IP-protokollapinon kerrosten suhde OSI-mallin kerroksiin (Kaario 2002: 22). 3.2.2 TCP Transmission Control Protocol eli TCP on yhteydellinen tietoliikenneprotokolla, joka tarjoaa sovelluksille luotettavan kuljetuspalvelun. Luotettavuus tarkoittaa tässä tapauk- sessa sitä, että TCP kykenee varmistamaan tiedon perillemenon ja korjaamaan mahdol- liset virheet tiedonsiirrossa. Yhteydellisyys tarkoittaa sitä, että TCP:n kuljetuspalvelu on aina kahden pisteen välistä palvelua. Tämä tarkoittaa myös sitä, että osapuolten välillä neuvotellaan yhteyden muodostamisesta ja purkamisesta. TCP käsittelee tavuvirtaa, eli TCP-kerroksen yläpuolella oleva sovellusprosessi kirjoittaa tavuja TCP:lle lähetystä varten. TCP voi varastoida tavuja puskureihin. Lähetyspuskurista TCP lähettää seg- menttejä, jotka eivät välttämättä ole samankokoisia sovelluksen kirjoittamien palasten kanssa. (Kaario 2002: 166.) Kuvasta 7 nähdään, kuinka TCP lukee tavuja ja lähettää segmenttejä. TCP:n yläpuolella olevat sovellusprosessit tunnistetaan porttinumeroilla. Niiden avulla yksi TCP-prosessi voi palvella useita sovelluksia samaan aikaan. TCP osaa myös valvoa verkon suorituskykyä ja voi säätää lähetysnopeuttaan sen mukaan. Käytännössä lähettä- 24 jä tarvitsee siis tiedon siitä, kuinka paljon vastaanottaja voi vastaanottaa tietoa. (Kaario 2002: 166.) Kuva 7. Tavujen kirjoittaminen ja lukeminen (Kaario 2002: 166). 3.2.3 IP Internet Protocol eli IP välittää paketteja verkkojen osasta toiseen. Luonteeltaan se on yhteydetön protokolla, eli verkkokerroksen tasolla ei pidetä kirjaa olemassa olevista yh- teyksistä, sillä se jätetään ylempien kerrosten protokollien hoidettavaksi. IP:n hyvä suo- rituskyky perustuu siihen, että se ei suorita vuonohjausta eikä virheenkorjausta. IP- liikenne on luonteeltaan pakettiliikennettä, missä kaikki paketit välitetään erikseen riip- pumatta siitä, mitä reittiä edellinen paketti on kulkenut. IP:n tehtäviä ovat muun muassa pakettien osioiminen, liikenteen reititys IP-osoitteen avulla ja peruspaketin koon määri- tys. (Anttila 2001: 114.) On hyvä erottaa käsite IP-osoite itse protokollasta, sillä kuten aiemmin mainittiin, niin IP reitittää liikennettä IP-osoitteen avulla. Tällä hetkellä on käytössä versiot IPv4 ja IPv6. Näistä IPv4 on vanhempi ja edelleen laajasti käytössä. Diplomityössä käsitellään ainoastaan IPv4-osoitteita, joten käydään läpi IPv4-osoitteen rakennetta. IPv4:n mukai- 25 nen IP-osoite lukuna muodostuu 32 bitistä ja tavallisesti se esitetään neljän desimaalilu- vun sarjana pisteillä erotettuna. Pisteillä erotetut luvut ovat arvoltaan välillä 0–255. (Anttila 2001: 87.) Internetin osoiteavaruus on jaettu viiteen eri luokkaan, joita ovat A, B, C, D ja E. Kullakin luokalla on tietty määrä osoitteita. (Anttila 2001: 88–90.) Nyky- ään puhutaan kuitenkin luokattomista IP-osoitteista. Luokattomuuden tarjoaa erityinen CIDR-tekniikka. (Anttila 2001: 109–110.) IP-osoitteiden käyttöön liittyy tärkeänä osana aliverkotus. Aliverkotus on tärkeää erityi- sesti julkisten IP-osoitteiden yhteydessä, sillä niitä on käytössä hyvin rajallinen määrä. Siksi tällaiset osoitteet olisi hyvä jakaa mahdollisimman tehokkaasti käytössä olevien laitteiden kesken. Jos esimerkiksi yritys tarvitsee julkiset IP-osoitteet kymmenelle lait- teelle, niin ei ole järkeä antaa yrityksen käyttöön kokonaista C-luokan osoiteavaruutta, joka käsittäisi 254 osoitetta. Aliverkotus hoidetaan yleisimmin erillisen aliverkon mas- kin avulla. Aliverkon maski peittää kohdeosoitteesta tietyn osan. Aliverkon maskin avulla IP-osoitteesta nähdään sen verkko-osa, sillä aliverkon maskin kohdalla peiton kohde on IP-osoite ja peitettävä kohde on osoitteen laiteosuus. Kun laite haluaa kom- munikoida toisen laitteen kanssa, niin laite tekee oman ja vastapuolen osoitteen välillä binäärisen XOR-operaation. Tästä saatavaan tulokseen tehdään binäärinen AND- operaatio aliverkon maskin kanssa. Mikäli AND-operaation tulos on nolla, niin vas- taanottajalaite sijaitsee samassa verkossa ja paketti voidaan lähettää käyttäen lähiverkon menetelmiä. Mikäli tulos ei ole nolla, niin vastaanottaja sijaitsee jossain toisessa verkos- sa ja paketti lähetetään reitittimelle, josta paketti reititetään eteenpäin kohti oikeaa verk- koa. (Anttila 2001: 96–99.) Aliverkon maski voi olla esimerkiksi 255.255.255.0. Tällöin esimerkiksi laite, jonka IP-osoite on 10.3.2.2, sijaitsee verkossa 10.3.2.0. Toisin sanoen aliverkon maskin nolla-bitit kertovat mikä osa osoitteesta voi muuttua. Esimerkissämme verkossa on siis käytössä IP-osoitteet 10.3.2.1–10.3.2.254 osoitteen 10.3.2.255 ollessa levitysviestiosoite. Verkko-osoite ja aliverkon maski yhdistetään nykyään CIDR- tekniikan merkintätavan mukaisesti. Edellä mainittu esimerkkiverkko 10.3.2.0 ja aliver- kon maski 255.255.255.0 kirjoitettaisiin CIDR-merkintätavan mukaisesti muotoon 10.3.2.0/24, missä kauttamerkin jälkeinen luku kertoo ykkösbittien määrän aliverkon maskissa (Anttila 2001: 110). 26 Diplomityön kannalta oleellista on tietää mitä IP-osoitteita voidaan käyttää yksityisessä verkossa eli lähiverkossa, sillä julkisiin internet-osoitteisiin ei oteta nyt kantaa. Jos tar- kastellaan IP-osoitteita internetin näkökulmasta, niin on olemassa tiettyjä osoitteita, joi- ta ei voida käyttää julkisina IP-osoitteina internetissä. Taulukossa 1 on listattu erikois- käyttöön varatut verkot ja siitä nähdään yksityisille verkoille varatut verkko-osoitteet, joita ovat 10.0.0.0/8, 172.16.0.0/12 ja 192.168.0.0/16. Tätä kannattaa soveltaa myös toi- seen suuntaan. Toisin sanoen lähiverkossa, josta on yhteys internetiin, ei kannata käyt- tää sellaisia IP-osoitteita, jotka ovat oikeita osoitteita internetissä. Lähiverkoissa kannat- taakin käyttää juuri lähiverkoille tarkoitettuja osoitteita taulukon 1 mukaisesti. Taulukko 1. Erikoiskäyttöön varatut osoitteet (Internet Assigned Numbers Authority 2017). Address Block Name 0.0.0.0/8 "This host on this network" 10.0.0.0/8 Private-Use 100.64.0.0/10 Shared Address Space 127.0.0.0/8 Loopback 169.254.0.0/16 Link Local 172.16.0.0/12 Private-Use 192.0.0.0/24 IETF Protocol Assignments 192.0.0.0/29 IPv4 Service Continuity Prefix 192.0.0.8/32 IPv4 dummy address 192.0.0.9/32 Port Control Protocol Anycast 192.0.0.10/32 Traversal Using Relays around NAT Anycast 192.0.0.170/32, 192.0.0.171/32 NAT64/DNS64 Discovery 192.0.2.0/24 Documentation (TEST-NET-1) 192.31.196.0/24 AS112-v4 192.52.193.0/24 AMT 192.88.99.0/24 Deprecated (6to4 Relay Anycast) 192.168.0.0/16 Private-Use 192.175.48.0/24 Direct Delegation AS112 Service 198.18.0.0/15 Benchmarking 198.51.100.0/24 Documentation (TEST-NET-2) 203.0.113.0/24 Documentation (TEST-NET-3) 240.0.0.0/4 Reserved 255.255.255.255/32 Limited Broadcast 27 On olemassa hyviä käytäntöjä siitä, miten eri osoitteet kannattaa jakaa laitteiden kesken. Kuten taulukosta 1 nähdään, niin laitteen osoite ei saa olla 0 tai 255, sillä 0 tarkoittaa verkkoa itseään, eikä näin ole yksittäinen laite ja 255 on levitysviestiosoite, jonka kautta lähetetään viesti yleislähetyksenä kaikille verkon laitteille. Käytäntö laitteiden osoitteil- le voi olla millainen tahansa, sillä sen tarkoitus on helpottaa ihmisten työtä uusia asen- nuksia tehtäessä ja virhetilanteita selvitettäessä. Esimerkiksi reitittimille, palvelimille ja asiakaslaitteille jaettavat osoitteet voidaan määritellä alkavan jostain tietystä luvusta. Kuvitellaan, että käytössä on aiemmin mainitun verkon 10.3.2.0/24 IP-osoitteet 10.3.2.1–10.3.2.254, jolloin osoitteen viimeinen desimaaliluku muuttuu. Tällöin esi- merkiksi reitittimille ja hallittaville kytkimille voidaan antaa osoitteet 1–10, palvelimille osoitteet 200–254, asiakaslaitteille osoitteet 100–199 ja varalle jää vielä osoitteet 11–99. (Anttila 2001: 94.) 3.3 DHCP Dynamic Host Configuration Protocol eli DHCP on tietoliikenneprotokolla, jonka tär- kein tehtävä on antaa IP-osoite verkkoon kytkeytyvälle työasemalle. Yleensä DHCP antaa myös muita IP-parametrejä. Näitä ovat esimerkiksi aliverkon maski, yhdyskäytä- vä, nimipalvelimien IP-osoitteet ja verkkotunnus. Työasema voi pyytää näitä parametre- jä DHCP-palvelimelta, jossa on DHCP-palvelu toiminnassa. DHCP-palvelu ei ole ver- kossa välttämätön, sillä tarvittavat parametrit voidaan asettaa työasemalle myös käsin, mutta työasemien määrän kasvaessa tämä muuttuu hyvin epäkäytännölliseksi. Siksi DHCP onkin erityisen kätevä suuressa verkossa, jossa työasemat ovat satunnaisesti käynnissä ja niiden sijainti vaihtelee. Tästä huolimatta DHCP on yleisesti käytössä jo ihan pienissäkin verkoissa, sillä sen käyttöönotto on helppoa ja hyöty on suuri. DHCP- palvelin voi sijaita reitittimellä, mutta suuremmissa verkoissa sitä varten kannattaa olla oma palvelimensa. (Anttila 2001: 201–202.) DHCP-palvelin voi määritellä IP-osoitteen työasemalle kolmella tavalla, joita ovat au- tomaattinen määrittely, dynaaminen määrittely ja määrittely käsin. Automaattinen mää- rittely tarkoittaa sitä, että osoitetta pyytävälle työasemalle annetaan osoite määrittele- 28 mättömäksi ajaksi. Dynaamisessa määrittelyssä osoite annetaan määritellyksi ajaksi. Käsin määriteltäessä verkon ylläpitäjä asettaa palvelimen antamaan kiinteitä IP- osoitteita tietyille työasemille niiden MAC-osoitteiden perusteella. Voidaan määritellä esimerkiksi työasema, jonka MAC-osoite on 00-00-0c-a0-a2-10 saamaan aina IP-osoite 10.3.2.10. Käsin määrittely on hyödyllistä silloin, kun tietylle työasemalle halutaan an- taa aina sama osoite, mutta halutaan sen saavan muita mahdollisesti muuttuvia paramet- rejä DHCP-palvelimelta. Tavallisesti käytetään dynaamista määrittelyä, sillä siinä osoit- teet voivat palautua tietyn ajan kuluttua takaisin jaettavien osoitteiden joukkoon. Jos esimerkiksi verkossa, jossa työasemia on enemmän kuin jaettavia IP-osoitteita käytet- täisiin automaattista määrittelyä, osoitteet loppuisivat jossain vaiheessa kesken ja vii- meisinä käynnistetyt työasemat eivät saisi enää osoitteita ollenkaan. Dynaamisella mää- rittelyllä tämä onnistuu, kunhan kaikki työasemat eivät ole yhtä aikaa päällä. (Anttila 2001: 203.) 3.4 DNS Domain Name System eli DNS on nimipalvelujärjestelmä, joka muuntaa verkkotunnuk- sen (domain) IP-osoitteeksi. Jos esimerkiksi halutaan vierailla osoitteessa univaasa.fi, niin DNS muuntaa verkkotunnuksen univaasa.fi IP-osoitteeksi 193.166.120.2. Pelkkä verkkotunnus ei siis toimi yksinään, vaan sen takaa löytyy aina IP-osoite, jonka avulla varsinainen yhteys muodostetaan. (Järvinen 2003: 166.) Verkkotunnukset taas helpotta- vat lähinnä osoitteiden muistamista, sillä nimet painuvat numerosarjoja helpommin mie- leen (Anttila 2001: 231). Nimipalvelun toiminta perustuu nimipalvelimiin (domain na- me server), jotka tietävät verkon sisällä olevien laitteiden verkkotunnukset ja niitä vas- taavat IP-osoitteet. Jos nimipalvelin ei pysty selvittämään sille saapunutta pyyntöä, se lähettää pyynnön toiselle nimipalvelimelle ja tätä jatkuu, kunnes oikea palvelin löytyy ja vastaava IP-osoite selviää. (Järvinen 2003: 166.) Internetin verkkotunnuksista kirjaa pitävät nimipalvelimet sijaitsevat tietenkin internetissä, mutta myös lähiverkossa voi- daan ylläpitää omaa nimipalvelinta ja omia lähiverkon sisäisiä verkkotunnuksia. Tällai- nen verkkotunnus voisi olla esimerkiksi mailsrv1.koti.local, jonka IP-osoite lähiverkos- 29 sa olisi esimerkiksi 10.3.2.200 ja tämän verkkotunnus löytyisi ainoastaan lähiverkosta. (Hakala & Vainio 2005: 226–228.) 3.5 NAT Muun muassa reitittimen ominaisuuksiin kuuluva osoitteenmuunnos eli NAT muuntaa lähiverkon yksityiset IP-osoitteet yksilöllisiksi ulkoisiksi IP-osoitteiksi. Näin esimerkik- si monen lähiverkon laitteen IP-osoitteet saadaan näkymään internetiin yhtenä IP- osoitteena. Tällöin lähiverkon sisäisessä liikenteessä voidaan käyttää lähiverkon osoi- teavaruuteen kuuluvia osoitteita ja ulkopuolelle, eli yleensä internetiin suuntautuvissa yhteyksissä käytetään sitten julkista osoitetta. Samasta syystä NAT parantaa myös tieto- turvaa toimiessaan eräänlaisena palomuurina, joka piilottaa lähiverkon osoitteet ulko- maailmalta. Lisäksi lähiverkon laitteella on ulkoinen osoite vain silloin, kun yhteys on muodostettu ulkomaailmaan osoitteenmuunnoksen kautta. (Ballew 1998: 237–239.) Osoitteenmuunnos toimii yleensä siten, että kun lähiverkon laite ottaa yhteyden esimer- kiksi internetiin, NAT antaa sen käyttöön IP-osoitteen. Kun laite lähettää paketin, NAT korvaa sen lähiverkon IP-osoitteen dynaamisesti allokoidulla ulkoisella IP-osoitteella. Kun tällä samalla osoitteella varustettu paketti palaa takaisin, NAT tekee käänteisen osoitteenmuunnoksen, eli korvaa ulkoisen osoitteen alkuperäisellä sisäisellä osoitteella. Kun laite lopettaa yhteyden, NAT vapauttaa ulkoisen osoitteen muiden laitteiden käyt- töön. (Ballew 1998: 237–238.) Osoitteenmuunnos voidaan tehdä neljällä tavalla, joita ovat menetelmät yhdestä yhteen, yhdestä moneen, monesta yhteen ja monesta moneen. Yhdestä yhteen tarkoittaa sitä, että yksi lähiverkon IP-osoite muunnetaan yhdeksi julkiseksi IP-osoitteeksi. Yhdestä moneen puolestaan tarkoittaa sitä, että jokaiselle, yhdestä lähiverkon osoitteesta lähte- välle yhteydelle annetaan oma julkinen osoite. Monesta yhteen on tapa, jossa lähiverkon osoitteet muunnetaan aina yhdeksi ja samaksi julkiseksi osoitteeksi. Monesta moneen tarkoittaa nimensä mukaisesti sitä, että lähiverkon osoitteita muunnetaan tietyn julkisen osoiteavaruuden sisältämiksi osoitteiksi. (Gheorghe 2006: 91.) 30 Edellä esitelty osoitteenmuunnos on niin sanottu täysimääräinen osoitteenmuunnos (Full NAT). Osoitteenmuunnoksen tavanomaisimmissa käyttökohteissa sitä käytetään juuri täysimääräisenä. Täysimääräinen osoitteenmuunnos koostuu kahdesta eri osoit- teenmuunnoksen alalajista. Näitä ovat lähdeosoitteenmuunnos (SNAT) ja kohdeosoit- teenmuunnos (DNAT). Lähdeosoitteenmuunnos muuntaa ainoastaan tietyn lähdeosoit- teen joksikin tietyksi osoitteeksi, joka määritetään käsin. Jos esimerkiksi reitittimessä on pelkkä lähdeosoitteenmuunnos käytössä, niin pakettia lähetettäessä lähiverkon osoite muunnetaan käsin määritellyksi julkiseksi osoitteeksi, mutta paketin palatessa reititti- melle julkista osoitetta ei muunneta takaisin lähiverkon osoitteeksi. Tällöin paketti ei pääse takaisin lähdeosoitteeseensa. Masquerade on lähdeosoitteenmuunnoksen erityis- tapaus, joka toimii muuten kuten lähdeosoitteenmuunnos, mutta se ei muunna lähiver- kon osoitetta käsin määritetylle julkiselle osoitteelle, vaan reitittimen ulkoisen verk- kosovittimen osoitteelle, joka voi vaihdella. Kohdeosoitteenmuunnos muuntaa tietyn kohdeosoitteen joksikin tietyksi osoitteeksi. Periaate on sama kuin lähdeosoitteenmuun- noksessa, mutta muunnos tehdään nyt vain toiseen suuntaan. Jos reitittimessä on pelkkä kohdeosoitteenmuunnos käytössä, niin julkisesta verkosta tulevat paketit pääsevät koh- deosoitteenmuunnoksessa määritettyyn osoitteeseen, mutta paketit eivät voi palata ta- kaisin, sillä osoitetta ei muunneta takaisin. Yhdessä lähdeosoitteenmuunnos ja kohde- osoitteenmuunnos muodostavat siis täysimääräisen osoitteenmuunnoksen, jolloin osoit- teenmuunnos toimii molempiin suuntiin ja yhteys voidaan muodostaa osoitteenmuun- nosta käyttäen. (Gheorghe 2006: 92–96.) 31 4 SUUNNITTELU 4.1 Nykyinen tiedonsiirtojärjestelmä Nykyinen järjestelmä tietoliikenteen näkökulmasta koostuu työkoneesta ja ReDi- palvelun REST-palvelimesta suhteella monesta yhteen, eli työkoneita on monta ja REST-palvelimia yksi. Järjestelmän tiedonsiirrossa käytetään standardin IEEE 802.11 mukaista langatonta lähiverkkoa (WLAN), mikä tunnetaan myös nimellä Wi-Fi. Työ- koneen ohjausyksikköön on kytketty standardin mukainen langaton silta, joka yhdistyy kaivoksen tai tehtaan langattomaan lähiverkkoon, jos sellainen on saatavilla. Tätä kautta työkoneen ohjausyksikkö on yhteydessä internetiin ja REST-palvelimelle. Ongelmaksi muodostuu kuitenkin se, että langatonta lähiverkkoa ei ole läheskään aina saatavilla tai sen kantama ei riitä sinne asti, missä työkoneita käytetään. Myös matkapuhelinverkkoa voidaan hyödyntää. Tällöin internet-yhteys ei ole pelkän langattoman lähiverkon varassa. Siitä huolimatta tällainen ratkaisu auttaa vain silloin, kun työkoneet ovat maan päällä. Koska Normetin työkoneita käytetään usein haastavis- sa olosuhteissa syvällä maan alla, niin edellä mainitut tekniikat eivät toimi sellaisenaan. Edes matkapuhelinverkoista ei ole hyötyä maan alla, sillä signaali ei pääse kiven ja maa-aineksen läpi. Tätä voidaan verrata tilanteeseen, jossa puhelimeen puhutaan mentä- essä ison tunnelin läpi junalla ja yhteys katkeaa. Normetin työkoneet ovat lähes aina vielä paljon syvemmällä kuin tällaiset tunnelit, joten yhteys ei varmasti toimi kumpaan- kaan suuntaan. Tilanne on samanlainen langatonta lähiverkkoa käytettäessä. Langatto- man lähiverkon yhteys on usein vielä huomattavasti heikompi kuin yhteys matkapuhe- linverkon välityksellä, sillä lähetysteho on pienempi. Lisäksi taajuus voi olla suurempi, jolloin signaali vaimenee voimakkaammin. Koska työkoneiden kanssa käytetään tavallisesti langatonta lähiverkkoa, on vaihtoehtoja pääasiassa kaksi. Helpompi tapa on se, että jos kaivos sijaitsee esimerkiksi tehtaan lä- hellä ja tehtaalla on langaton lähiverkko, niin työkoneella voidaan silloin tällöin nousta maan pinnalle, jolloin verkkoon voidaan liittyä. Tämä on tosin melko epäkäytännöllistä, 32 jos kaivoksesta täytyy nousta pelkästään sen takia. Tämä riippuu toki siitä, millainen työkone on kyseessä, mutta sellaisia työkoneita, jotka muuten olisivat paljon maan alla, ei ole kannattavaa tuoda ylös vain yhteyden takia. Toinen vaihtoehto on rakentaa kai- vokseen oma verkkoinfrastruktuuri, joka tarjoaa langattoman lähiverkon kaivoksen si- sällä. Tämä edellyttää kaapeleiden vetämistä kaivokseen ja useiden langattomien silto- jen tai langattomien reitittimien asennusta kaivoksen kokoluokasta riippuen. Tämä on kallista, sillä se vie aikaa ja resursseja, mutta toisaalta siinä saavutetaan suuri hyöty tie- toliikenteen reaaliaikaisuudella. 4.2 Uusi tiedonsiirtojärjestelmä Tarkoituksena on kehittää sellainen järjestelmä, jonka avulla kaivoksen työkoneiden tuottama data saadaan siirrettyä ReDi-palvelun REST-palvelimelle. Koska vaatimukse- na on ainoastaan datan saaminen palvelimelle, niin tiedonsiirron reaaliaikaisuudesta voidaan luopua. Tällöin data voidaan siirtää tallennusvälineen avulla yhteydettömästi. Yhteydettömällä tiedonsiirrolla tarkoitetaan tässä tapauksessa sitä, että kun data lähtee työkoneelta, se ei heti pääse palvelimelle. Itse asiassa data ei välttämättä koskaan pääse oikealle palvelimelle, vaikka työkoneen ohjausjärjestelmän näkökulmasta data onkin lähetetty onnistuneesti. Tarkoitus tietenkin olisi, että data pääsee aina palvelimelle asti. Tästä johtuen voidaan käyttää termiä yhteydetön tiedonsiirto, koska ylemmällä tasolla nähdään vain työkone ja REST-palvelin. Tällä tasolla työkone lähettää dataa ja palvelin vastaanottaa tätä dataa, mutta lähetys ja vastaanotto tapahtuvat selvästi eri aikoina. Se, mitä tapahtuu tällä välillä, ei ole osapuolten tiedossa. Alemmalla tasolla osakokonai- suuksissa tiedonsiirto on toki yhteydellistä johtuen käytetyistä menetelmistä ja protokol- lista. Yksinkertaisin esimerkki tällaisesta tapauksesta on ulkoisen tallennusmedian, kuten esimerkiksi USB-muistin käyttäminen. USB-muistia voitaisiin kuljettaa työkoneen ja palvelimen välillä ja sitä voisi käyttää siihen valtuutettu kaivostyöntekijä. Työkoneen päässä ohjausjärjestelmään kiinnitettäisiin USB-muisti, jolloin data siirtyisi USB- muistille. Tämän jälkeen USB-muisti kuljetettaisiin fyysisesti palvelimelle ja data siir- 33 rettäisiin sinne. Tällaista järjestelmää kutsutaan leikkisästi nimellä sneakernet. Siinä da- ta siirretään fyysiselle tallennusmedialle paikassa A ja kuljetetaan sellaisenaan paikkaan B, jossa data puretaan tallennusmedialta. (Ulz, Pieber, Steger, Haas & Matischek 2017: 261.) Tällaisenaan järjestelmä on kuitenkin erittäin kömpelö, sillä USB-muistia ei kan- nata kuljettaa mahdollisesti maasta toiseen palvelimelle asti. Itse palvelimen sijaintia ei edes tarkasti tiedetä työkoneen päässä, sillä palvelinta ylläpitää Exertus. Täten datan kuljettaminen palvelimelle on mahdotonta. Sen sijaan USB-muistia voitaisiin kuljettaa työkoneen ja internetiin kytketyn tietokoneen välillä, jolloin USB-muistilla oleva data siirrettäisiin ensin tietokoneeseen, josta data sen jälkeen siirtyisi internetin välityksellä palvelimelle. Huonona puolena tässä on edelleen se, että USB-muisti pitäisi aina kiinnit- tää fyysisesti kaikkiin työkoneisiin erikseen. Tämä vie tietenkin paljon aikaa, jos työko- neita pitää etsiä kaivoksesta ja mahdollisesti pitää kirjaa niistä työkoneista, joista data on jo siltä erää siirretty USB-muistille. Lisäksi työkoneen toiminta pitää joissakin tapa- uksissa pysäyttää hetkellisesti tai ainakin noudattaa äärimmäistä varovaisuutta, jotta USB-muisti päästään kiinnittämään työkoneen ohjausyksikköön. Tämän jälkeen USB- muisti pitäisi vielä viedä sellaiseen paikkaan, jossa on tietokone ja internet-yhteys. Täl- laisia paikkoja saattaa olla vain tehtaassa tai toimistossa, joka voi olla pitkänkin matkan päässä. Koska työkoneet kykenevät langattomaan tiedonsiirtoon, niin eikö kannattaisi hyödyn- tää sitä myös tässä yhteydettömässä tiedonsiirrossa? Tiedonsiirtoa ei tarvitse välttämättä tehdä oikeasti yhteydettömänä pelkkien tallennusvälineiden avulla, kuten edellä kuvat- tiin. Työkoneen langaton datasiirtolaite tarvitsee vain samanlaisen liityntäpisteen, kuin olisi normaalissakin tapauksessa käytettäessä esimerkiksi tehtaan langatonta lähiverk- koa. Edellä mainittua ajatusta jalostamalla, voitaisiin kehittää eräänlainen liikkuva tietokone, johon olisi kytketty kaksi langatonta reititintä, joista toinen on asennettu tukiasemaksi ja toinen tavalliseksi asiakkaaksi. Työkoneessa olisi tällöin langattoman sillan sijaan myös langaton reititin asiakastilassa, joka voisi liittyä liikkuvan tietokoneen tukiasemaan ja lähettää datan sinne. Sieltä data lähetettäisiin oman asiakastilassa olevan reitittimen avulla edelleen tehtaan langattoman lähiverkon tukiasemalle sitten, kun tällainen verkko 34 on saatavilla. Sieltä data pääsee internetiin ja edelleen oikealle palvelimelle. Tällä ta- voin data saataisiin siirtymään automaattisesti langatonta tekniikkaa hyödyntämällä. Näin dataa keräävää tietokonetta voitaisiin vain liikutella kaivoksessa lähellä työkoneita ja kun data on kerätty, noustaan ylös ja lähetetään data palvelimelle. Tällaisen liikkuvan tietokoneen voidaan ajatella olevan eräänlainen välityspalvelin, joka muodostaa koko järjestelmästä osittaisen viivesietoisen verkon (delay-tolerant network). Siinä dataa siirretään ainoastaan yksi solmuväli kerrallaan (hop-by-hop), jolloin solmul- le saapunut viesti tallennetaan pysyväismuistiin odottamaan reititystä uuteen solmuun (store-and-forward). Solmut voivat myös liikkua fyysisesti paikasta toiseen, jolloin ne kuljettavat viestejä mukanaan (store-carry-and-forward). (Dunkels, Alonso, Voigt, Rit- ter & Schiller 2004: 146; Syrjänen 2007: 7.) Tässä tapauksessa liikkuva solmu on siis välityspalvelin ja se voi olla internet-yhteyden ulottumattomissa hyvinkin pitkän ajan. Tällöin viive tiedonsiirrossa kasvaa moninkertaiseksi verrattuna perinteiseen, millise- kunteja kestävään päästä–päähän-yhteyteen, johon esimerkiksi internet perustuu. Tässä tapauksessa puhutaan minuuteista tai jopa tunneista. Tällöin on käytännöllistä siirtää toimitusvastuu työkoneelta aina välityspalvelimelle (custody transfer), jolloin työko- neen ei tarvitse saada tietoa oikealta palvelimelta viestin perillemenosta. Riittää, että välityspalvelin ilmoittaa työkoneelle olevansa oikea palvelin ja vastaanottaneensa tämän viestin. (Fall 2003: 31–32; Syrjänen 2007: 7.) Edellä mainitut tekniikat edellyttävät kuitenkin sitä, että viivesietoisen verkon solmulla on tarkoitukseen sopiva ohjelmisto sekä oma, verrattain suurikin tietovarasto riippuen käyttötarkoituksesta. Vaatimus tietovarastosta laitteistotasolla toteutuu diplomityön ai- kana, mutta tulevat ohjelmistoratkaisut määrittävät lopulta sen, perustuuko järjestelmä täysin viivesietoiseen verkkoon. Viivesietoisessa verkossa myös lähettäjällä ja vastaan- ottajalla pitää olla tarkoitukseen sopiva ohjelmisto, sillä viivesietoinen verkko on sovel- lustason kateverkko (overlay network), jossa siirretään viestinippuja (bundle) tarkoituk- seen sopivalla protokollalla (Syrjänen 2007: 6). Viivesietoinen verkko toimii siten ole- massa olevien protokollapinojen yläpuolella. Esimerkiksi internet-liikenteeseen se ra- kennettaisiin TCP/IP-protokollaperheen päälle. (Fall 2003: 30.) 35 4.2.1 Arkkitehtuuri yleisellä tasolla Uusi järjestelmä toimii siis eräänlaisena liikuteltavana välityspalvelimena, joka ottaa vastaan työkoneelta lähetetyn datan ja lähettää sen edelleen eteenpäin oikealle palveli- melle. Tiedonsiirto näiden kolmen osan välillä hoidetaan langattomia lähiverkkoja käyt- tämällä, jolloin toimenpiteet saadaan automatisoitua mahdollisimman pitkälle ennen varsinaisia ohjelmistoratkaisuja. Järjestelmästä olisi tarkoitus tehdä sellainen, että se kykenee toimimaan myös sellaise- naan ilman välityspalvelintakin, jolloin välityspalvelinta ei ole pakko käyttää, jos inter- net-yhteys on muuten aina helposti saatavilla. Näin järjestelmä kykenee toimimaan myös entiseen tapaan, eikä välityspalvelin sulje mitään toimintoja ulkopuolelle. Tässä mielessä järjestelmä muodostaa kokonaisuutena eräänlaisen dynaamisen reitityksen tie- toliikenteelle, sillä järjestelmän tulee mukautua kumpaankin tilanteeseen automaattises- ti. Käytännössä tämä tarkoittaa sitä, että kaivostyökoneet lähettävät dataa joko välitys- palvelimelle tai oikealle palvelimelle ja valinta näiden kahden välillä tehdään itsenäises- ti ilman ulkopuolista toimijaa. Kuvasta 8 nähdään uuden tiedonsiirtojärjestelmän arkkitehtuurikuvaus yleisellä tasolla. Kuvassa näkyy myös suunniteltuja laitteisto- ja ohjelmistoratkaisuja, mutta tässä vai- heessa kuvasta kannattaa huomioida erityisesti kolme laatikkoa: Work machine, Data mule ja Server. Nämä kolme osaa ovat uuden järjestelmän pääosat. Nykyisen järjestel- män muodostavat Work machine eli kaivostyökone ja Server eli tässä tapauksessa ReDi ja sen REST-palvelin. Tähän on nyt siis tarkoitus lisätä kolmas osa eli välityspalvelin, joka on kuvassa markkinointisyistä nimellä Data mule. Kuvan kaaviota kannattaa verra- ta erityisesti kuvan 4 samantyyliseen kaavioon, jossa näytetään nykyisen järjestelmän arkkitehtuurikuvaus. Jos kuvan 8 järjestelmästä pudotetaan välityspalvelin pois, niin järjestelmä toimii kuten kuvassa 4. Itse asiassa järjestelmä toimii ensisijaisesti aina ku- ten kuvassa 4, sillä järjestelmän on tarkoitus toimia siten, että kun välityspalvelin on työkoneiden lähellä, niin järjestelmästä tulee kuvan 8 kaltainen, mutta muussa tapauk- sessa tiedonsiirtojärjestelmä toimii kuten kuvassa 4. 36 Kuva 8. Uuden tiedonsiirtojärjestelmän tietoliikenne Norsmart-ohjausjärjestelmässä (Exertus 2013: 7). 4.3 Verkkoarkkitehtuuri Uusi järjestelmä koostuu siis kolmesta osakokonaisuudesta, joita ovat työkone, REST- palvelin ja välityspalvelin. Suunnitellaan seuraavaksi näiden kolmen osakokonaisuuden verkkoarkkitehtuurit. Verkkoarkkitehtuurin näkökulmasta on hyvä tarkastella kaikkia kolmea osaa aluksi erikseen ja lopuksi yhdistää ne yhdeksi kokonaisuudeksi. Sanotta- koon vielä, että REST-palvelimen verkkoarkkitehtuuri on tietenkin jo olemassa, mutta käydään se silti läpi ylemmällä tasolla, sillä se helpottaa kokonaiskuvan muodostamista. 4.3.1 Työkone Työkone on järjestelmän yksinkertaisin kokonaisuus verkkoarkkitehtuurin näkökulmas- ta, sillä laitteiston puolesta se koostuu sulautetulla Linux-käyttöjärjestelmällä varuste- 37 tusta ohjausyksiköstä ja langattomasta reitittimestä. Ohjausyksikkö on aina jokin Exer- tuksen ohjausyksiköistä. Ohjausyksikköön kiinnitetään langaton reititin Ethernet- kaapelilla. Täten tällä osakokonaisuudella on oma langallinen lähiverkko eli LAN. Lan- gallisen lähiverkon puolella reitittimen DHCP-palvelin antaa ohjausyksikölle IP- osoitteen, joka on samassa aliverkossa reitittimen langallisen verkkosovittimen eli Et- hernet-sovittimen kanssa. DHCP-palvelimen antaman IP-osoitteen sijaan voitaisiin käyttää myös kiinteää IP-osoitetta ohjausyksikössä, jolloin se olisi aina sama. Ongel- maksi muodostuu kuitenkin se, että jos ohjausyksikkö vaihdetaan toiseen, sille pitäisi asettaa IP-osoite, aliverkon maski ja yhdyskäytävä aina käsin. Tästä ei toki olisi suurta vaivaa, mutta koska se ei tuo etua, niin on parempi jättää asia DHCP-palvelimen hoidet- tavaksi. Langaton reititin toimii asiakastilassa, eli se on niin sanottu langaton asiakas (wireless client). Tämä tarkoittaa sitä, että langaton reititin pystyy yhdistymään tukiasemaan (ac- cess point) niin kuin mikä tahansa langattomalla verkkosovittimella varustettu laite, ku- ten esimerkiksi tietokone tai älypuhelin. Tässä tapauksessa se vain sattuu olemaan lan- gattomaksi asiakkaaksi asennettu reititin, sillä ohjausyksikössä ei ole langatonta verk- kosovitinta. Koska langaton reititin yhdistyy tukiasemaan, reitittimen langaton verk- kosovitin saa IP-osoitteen ja muut tarvittavat IP-parametrit tukiaseman DHCP- palvelimelta. Täten sen IP-osoite voi vaihdella paljonkin riippuen siitä, monenko eri tu- kiaseman alueella työkone liikkuu. Tällä ei sinänsä ole merkitystä, sillä langaton asiakas saa aina internet-yhteyttä varten tarvittavat asetukset automaattisesti tukiasemalta. Reitittimen langattoman verkkosovittimen ja Ethernet-sovittimen välinen liikenne toteu- tetaan käyttämällä osoitteenmuunnosta. Tässä tapauksessa käytetään täysimääräistä osoitteenmuunnosta, sillä osoite pitää saada muunnettua molempiin suuntiin. Täysimää- räistä osoitteenmuunnosta käytettäessä tarvitaan lähdeosoitteenmuunnos ja kohdeosoit- teenmuunnos. Täysimääräisen osoitteenmuunnoksen avulla oman yksityisen lähiverkon laitteen IP-osoite muunnetaan joksikin julkiseksi IP-osoitteeksi. Tässä tapauksessa osoitteenmuunnos toimii siten, että reititin muuntaa lähdeosoitteenmuunnoksen avulla langallisen lähiverkon puolella olevan ohjausyksikön IP-osoitteen näyttäytymään lan- gattomalle lähiverkolle sillä osoitteella, jonka reitittimen langaton verkkosovitin saa tu- 38 kiaseman DHCP-palvelimelta. Tästä syystä lähdeosoitteenmuunnos on itse asiassa mas- querade, koska langattoman verkkosovittimen IP-osoite voi vaihdella. Ohjausyksikön IP-osoite ei nyt siis näy langattoman lähiverkon puolella. Langallisen lähiverkon näkö- kulmasta langaton lähiverkko on julkinen verkko, vaikka oikeasti julkinen verkko eli internet onkin vasta tehtaan tukiaseman oman osoitteenmuunnoksen takana. Kohde- osoitteenmuunnoksen avulla reititin muuntaa langattoman verkkosovittimen IP- osoitteen takaisin ohjausyksikön IP-osoitteeksi. Tämä pitää kuitenkin järjestellä siten, että langattoman verkon puolelta ei voida ottaa yhteyttä mihinkään tiettyyn kohdeosoit- teeseen langallisen lähiverkon puolella. Edellä suunniteltu työkoneen verkkoarkkiteh- tuuri nähdään kuvasta 9. Siinä työkoneen ohjausyksikkö on kiinnitetty langattomaan reitittimeen, joka toimii asiakastilassa. Osoitteenmuunnos on sijoitettu näiden kahden välille kuvaamaan sitä, että langallisen lähiverkon puolella on työkoneen oma verkko ja langattoman lähiverkon puolella on työkoneen näkökulmasta julkinen verkko. Kuva 9. Työkoneen verkkoarkkitehtuuri. 4.3.2 ReDi Käsitteellä ReDi tarkoitetaan diplomityössä Exertuksen palvelua kokonaisuudessaan. Verkkoarkkitehtuurin näkökulmasta ReDi on REST-palvelin, joka sijaitsee internetissä. Laajennetaan ReDi koskemaan nyt myös tehtaan langattoman verkon tarjoavaa tu- kiasemaa, johon työkoneet yhdistyvät. Edellä mainittu tilanne on kuvattu kuvassa 10. Siinä REST-palvelin ja tukiasema ovat yhdistettyinä internetiin, jolloin tukiasemalta on yhteys REST-palvelimelle. Nämä voitaisiin pilkkoa pienemmiksikin osakokonaisuuk- siksi, mutta kun tarkastellaan tulevaa järjestelmää kokonaisvaltaisesti, niin työkoneen ja 39 välityspalvelimen kannalta on samantekevää missä palvelin sijaitsee ja miten palvelin on kytketty internetiin, kunhan sinne pääsee tukiaseman kautta. Kuva 10. Laajennettu ReDi-palvelun verkkoarkkitehtuuri. ReDi-palvelun REST-palvelin sijaitsee siis internetissä ja sillä on julkinen IP-osoite. Tämä osoite on palvelimella kiinteä. Palvelimella on myös oma verkkotunnus, mutta sitä ei tarvita uuden tiedonsiirtojärjestelmän suunnittelussa tai toteutuksessa, sillä tule- vassa järjestelmässä ei ole sellaisia komponentteja, jotka erityisesti vaatisivat verkko- tunnuksen käyttöä tällä hetkellä. Laitteiston kanssa voidaan aivan hyvin käyttää pelkkiä IP-osoitteita, sillä verkkotunnukset on tarkoitettu ensisijaisesti ihmisille, jotta osoittei- den muistaminen olisi helpompaa. Kuvassa 10 näkyvä tukiasema ei ole mikään tietty tukiasema, vaan se kuvaa yleisesti tukiasemaa, johon työkoneet ja myöhemmin myös välityspalvelin voivat yhdistyä. Se voi olla siis mikä tahansa tukiasema missä tahansa, kunhan se on yhteydessä internetiin ja kaivostyökoneet voivat käyttää sitä. Tämän tukiaseman DHCP-palvelimen pitää 40 myös olla toiminnassa, jotta se voi jakaa IP-parametrit siihen liittyville asiakkaille. Muuten järjestelmä ei toimi. 4.3.3 Välityspalvelin Välityspalvelimen verkkoarkkitehtuuri on näistä kolmesta osakokonaisuudesta suurin. Tietenkin ReDi on siinä mielessä suurin, että se on kiinni internetissä, mutta internet onkin siinä vain välikappaleena, joten siinä mielessä välityspalvelimen verkko on mo- nimutkaisempi. Välityspalvelin on ikään kuin työkone ja ReDi yhdistettynä, sillä välityspalvelimen täy- tyy sisältää elementtejä molemmista osista, jotta järjestelmä toimii kokonaisuutena. Täs- tä syystä välityspalvelimella on kaksi langatonta reititintä, joista toinen on välityspalve- limen oma tukiasema ja toinen oma langaton asiakas. Kuvassa 11 tukiasemareititin on kuvattu samalla tavalla kuin kuvassa 10 ja asiakasreititin on kuvattu samalla tavalla kuin kuvassa 9. Kuva 11. Välityspalvelimen verkkoarkkitehtuuri. 41 Tukiasemaa tarvitaan siksi, että työkoneet voivat tarvittaessa yhdistyä siihen langatto- masti ja lähettää dataa aivan kuten ne tekisivät yhdistyessään tehtaan tukiasemaan. Lan- gatonta asiakasta puolestaan tarvitaan siihen, että välityspalvelin voi itse yhdistyä teh- taan tukiasemaan ja lähettää työkoneilta vastaanotetun datan oikealle palvelimelle. Jär- jestelmään tarvitaan myös tietokone, joka varastoi työkoneilta vastaanotetun datan sekä hoitaa myöhemmin palvelimen toimintoja ja mahdollisesti myös muita ohjelmistotekni- siä toimintoja. Tässä voidaan käyttää samanlaista ohjausyksikköä, jota työkonekin käyt- tää, sillä siinä on tarkoitukseen hyvin sopiva Linux-käyttöjärjestelmä. Edellä mainittu- jen laitteiden lisäksi tarvitaan vielä verkkokytkin, joka yhdistää edellä mainitut kolme laitetta. Kuvasta 11 nähdään kuinka verkkokytkin yhdistää välityspalvelimen ohjausyk- sikön, tukiaseman ja asiakastilassa olevan langattoman reitittimen. Vaikka verkkoarkkitehtuurin näkökulmasta laitteisto onkin jo selvillä, niin tarvitaan silti vielä eräitä tekniikoita, jotta järjestelmä toimii oikein. Kysymys on erityisesti siitä, mi- ten työkone pystyy lähettämään datansa välityspalvelimelle siten, että työkone luulee välityspalvelimen olevan oikea palvelin. Tämä voidaan ratkaista siten, että välityspalve- limen tukiasemassa käytetään kohdeosoitteenmuunnosta. Voidaan puhua eräänlaisesta mies välissä -hyökkäyksestä (man-in-the-middle attack), jossa kahden pisteen välissä on vihamielinen hyökkääjä, joka kaappaa osapuolten liikenteen. Tässä tapauksessa välissä ei ole vihamielinen hyökkääjä, vaan mies välissä -hyökkäyksen periaatetta käyttävä it- senäinen välityspalvelin, jonka kautta data kulkee. Kohdeosoitteenmuunnos toimii siten, että sille määritetään IP-osoite, joka näkyy ulko- verkolle ja IP-osoite, joka ohjaa tähän ulkoverkolle näkyvään IP-osoitteeseen tulevat paketit oikeaan paikkaan sisäverkossa. Tämän avulla välityspalvelimen ohjausyksikkö saadaan näyttäytymään REST-palvelimen IP-osoitteella välityspalvelimen tukiaseman puoleiselle langattomalle lähiverkolle. Tämän johdosta ohjausyksiköllä täytyy olla aina sama IP-osoite. Siksi sille kannattaa määrittää kiinteä IP-osoite, sillä jos ohjausyksikön IP-osoite muuttuu, kohdeosoitteenmuunnos ei enää ohjaa liikennettä tähän muuttunee- seen osoitteeseen. Kohdeosoitteenmuunnos on merkitty kuvaan 11 tukiaseman ja ohja- usyksikön välille. 42 Lisäksi kun käytetään TCP-yhteyttä, niin kohdeosoitteenmuunnosta käytettäessä pitää perille saapuneen paketin tietää reitti takaisin lähettäjälle, sillä kohdeosoitteenmuunnos ei sitä kerro. Tässä tapauksessa ohjausyksikön täytyy kertoa paluupaketille reitti takai- sin, eli kertoa mistä pääsee siihen langattomaan lähiverkkoon, jossa paketti oli ennen kohdeosoitteenmuunnosta. Toisin sanoen ohjausyksikkö reitittää paketin tukiasemarei- tittimen Ethernet-sovittimelle, josta se pääsee langattoman lähiverkon puolelle, jonka jälkeen paketti tietääkin jo reitin takaisin lähettäjälle. Välityspalvelimen langattomana asiakkaana toimiva reititin puolestaan tarvitsee täysimääräisen osoitteenmuunnoksen samaan tapaan kuin työkoneenkin langaton reititin. Koska välityspalvelimen ohjausyksiköllä on kiinteä IP-osoite, niin välityspalvelimen lähiverkossa ei ole ollenkaan tarvetta DHCP-palvelulle, sillä myös molemmilla reititti- millä on kiinteät IP-osoitteet. Ainoastaan tukiaseman täytyy jakaa IP-osoitteita siihen liittyville työkoneiden reitittimille, joten tukiaseman langattoman verkon puolella täytyy olla DHCP-palvelu toiminnassa. 4.3.4 Kokonaisuus Edellä esiteltiin kolme osakokonaisuutta, joista uusi tiedonsiirtojärjestelmä koostuu. Nyt yhdistetään nämä osat yhdeksi kokonaiseksi järjestelmäksi, joka voi toimia sekä väli- tyspalvelimen kanssa että ilman sitä. Tässä vaiheessa mukaan tulevat myös laitteiden IP-osoitteet. Esitetyt IP-osoitteet ovat ainoastaan esimerkkejä, eikä niitä tulla käyttä- mään järjestelmän tuotantoversiossa. Järjestelmän lähiverkoissa tullaan käyttämään aliverkon maskia 255.255.255.0, jolloin käytössä ovat aina osoitteet 1–254 ja levitysviestiosoitetta varten on osoite 255. Vaikka lähiverkoissa ei tule olemaan näin monta laitetta, on kyseinen verkon koko silti hyvä ratkaisu. Ensinnäkin se yksinkertaistaa osoitteiden käsittelyä, kun esimerkiksi ylläpito- vaiheessa tietyn lähiverkon kokoa ei tarvitse erikseen selvittää, vaan tiedetään, että ver- kon koko on kaikkialla sama. Lisäksi tämän kokoinen verkko tekee uusien laitteiden lisäämisestä helppoa. Jos verkkoon pitäisi myöhemmin lisätä laitteita ja verkko olisikin liian pieni, niin verkon kokoa täytyisi kasvattaa. Nyt kun verkon koko on tarpeeksi suu- 43 ri, niin laitteita voidaan huoletta lisätä montakin, jos sille on tarvetta. Liian suuresta verkosta ei muutenkaan ole mitään haittaa, sillä kyseessä on yksityinen lähiverkko. Kuvasta 12 nähdään uuden järjestelmän verkkoarkkitehtuuri kokonaisuutena, johon on yhdistetty edellä mainitut osakokonaisuudet IP-osoitteineen. Myös osakokonaisuuksien väliset langattomat yhteydet näkyvät kuvassa. Kuva 12. Uuden järjestelmän verkkoarkkitehtuuri kokonaisuudessaan. Kuvassa näkyvistä langattomista yhteyksistä täytyy huomata se, että työkone voi olla yhdellä kertaa yhdistyneenä vain yhteen tukiasemaan, eli käytössä on joko oranssi yhte- ys tai vihreä yhteys. Tämän johdosta kannattaa huomata myös se, että järjestelmän on tarkoitus toimia kahdessa tapauksessa eli välityspalvelimen kanssa ja ilman sitä. Tarkas- tellaan näitä kahta tilannetta tarkemmin. Aloitetaan yksinkertaisemmasta tilanteesta eli 44 tilanteesta ilman välityspalvelinta. Tätä tilannetta voidaan havainnollistaa kuvassa 12 siten, että jätetään välityspalvelin huomiotta, jolloin työkone käyttää oranssia yhteyttä. Työkoneen ohjausyksikössä toimiva ohjausjärjestelmä on nyt tallentanut dataa työko- neen liikkeistä ja nämä tiedot pitäisi saada lähetettyä ReDi-palvelun REST-palvelimelle. Ohjausyksiköllä on oma IP-osoite, jonka se on saanut työkoneen langattomalla reititti- mellä sijaitsevalta DHCP-palvelimelta. Työkoneen langallinen lähiverkko on 192.168.7.0/24. Tällöin aliverkon maski on 255.255.255.0, jolloin jaossa oleva osoi- teavaruus on 192.168.7.1–192.168.7.254 osoitteen 192.168.7.255 ollessa levitysvies- tiosoite. Reitittimen Ethernet-sovittimella on kiinteä IP-osoite 192.168.7.1. DHCP- palvelimet voivat antaa IP-osoitteita joko osoiteavaruuden alku- tai loppupäästä. Sovi- taan, että tämän diplomityön aikana DHCP-palvelin antaa osoitteita aina osoiteavaruu- den loppupäästä. Koska levitysviestiosoite on tässä tapauksessa 192.168.7.255, niin en- simmäinen vapaa osoite, jonka DHCP-palvelin antaa työkoneen ohjausyksikölle, on 192.168.7.254. Työkoneen reitittimen langaton verkkosovitin saa langattoman lähiverkon osoitteensa nyt tässä tapauksessa tehdasverkon tukiaseman DHCP-palvelimelta. Sen osoiteavaruus ei ole tässä tapauksessa tiedossa ja se voi vaihdella eri tukiasemilla, joten käytetään täs- sä verkkoa i.j.k.0/24. Koska määrittelimme tämän verkon aliverkon maskiksi 255.255.255.0, niin voimme olettaa, että tukiaseman langattoman verkkosovittimen IP- osoite on silloin i.j.k.1. Työkoneen reitittimen langaton verkkosovitin saa tukiaseman DHCP-palvelimelta osoitteen i.j.k.254. Näin tukiasema ja työkoneen reitittimen langa- ton verkkosovitin ovat samassa langattomassa lähiverkossa. Tehtaan tukiasema on yhdistetty internetiin. Miten tehdasverkko on tukiaseman jälkeen suunniteltu, ei ole tämän diplomityön kannalta merkityksellistä. Tässä tapauksessa riit- tää ainoastaan tieto siitä, että tukiasemalta on yhteys internetiin. Tilanne on kuvattu pa- lomuurilla ja reitittimellä kuvissa 10 ja 12. Todellisuudessa tehtaan sisäinen verkko saattaa olla hyvinkin paljon monimutkaisempi kuin kuvissa, mutta sillä ei ole nyt merki- tystä. Palomuurit saattavat toki rajoittaa liikennettä esimerkiksi sulkemalla portteja, mutta tällaiset tilanteet ovat erikoistapauksia ja ne voidaan ratkaista asiakkaan kanssa erikseen. 45 Tehdasverkon tukiasemalta on siis yhteys internetiin ja sitä kautta ReDi-palvelun REST-palvelimelle. REST-palvelimen julkinen IP-osoite on x.y.z.a. Jos tarkastellaan palvelimen sijaintia sen lähiverkossa, niin tilanne on sama kuin tehdasverkon tapaukses- sa, eli se ei ole tiedossa eikä sillä ole järjestelmän toiminnan kannalta edes merkitystä. Tässä tapauksessa riittää tieto REST-palvelimen julkisesta IP-osoitteesta. Nyt koko ket- ju työkoneen ohjausyksiköltä REST-palvelimelle on tiedossa. Nyt kun TCP-paketti läh- tee työkoneen ohjausyksiköltä osoitteesta 192.168.7.254, se etenee reitittimen Ethernet- sovittimelle osoitteeseen 192.168.7.1. Tässä kohdassa osoite muunnetaan käyttäen läh- deosoitteenmuunnosta. Tässä vaiheessa poistutaan työkoneen lähiverkosta 192.168.7.0/24 ja siirrytään tehdasverkon langattomaan lähiverkkoon i.j.k.0/24, jolloin paketti etenee verkon yhdyskäytävään tukiasemalle osoitteeseen i.j.k.1. Tästä paketti siirtyy tehtaan langalliseen lähiverkkoon ja sieltä internetiin. Internetin kautta paketti päätyy lopulta REST-palvelimelle osoitteeseen x.y.z.a. Paluupaketti menee perille sa- maa reittiä kuin tullessakin. Lähdeosoite näyttää kuitenkin nyt osoitteenmuunnoksen johdosta osoitetta i.j.k.254, mutta reititin osaa kääntää paketin kohdeosoitteenmuunnok- sen avulla takaisin. Tästä paketti palaa takaisin ohjausyksikölle osoitteeseen 192.168.7.254. Nyt kun tiedetään, miten järjestelmä toimii ilman välityspalvelinta, voidaan toimintaa tarkastella välityspalvelimen kanssa. Tämä tilanne nähdään kuvasta 12 siten, että käyte- tään vihreää- ja violettia yhteyttä. Lähtötilanne on työkoneen päässä sama lähiverkon osalta, eli ohjausyksikkö saa osoitteen 192.168.7.254 DHCP-palvelimelta ja työkoneen reitittimen Ethernet-sovittimen IP-osoite on 192.168.7.1 verkon ollessa 192.168.7.0/24. Tässä vaiheessa tilanne muuttuu aiempaan, sillä nyt työkoneen reitittimen langaton verkkosovitin saa osoitteensa välityspalvelimen tukiasemalta. Käytämme välityspalve- limen tukiaseman langattomassa lähiverkossa verkkoa 192.168.133.0/24. Tällöin aliver- kon maski on 255.255.255.0 ja osoiteavaruus on siten 192.168.133.1–192.168.133.254, jolloin levitysviestiosoite on 192.168.133.255. Tukiaseman langattoman verkkosovitti- men IP-osoite on 192.168.133.1. Tukiaseman DHCP-palvelin antaa työkoneen reititti- men langattomalle verkkosovittimelle osoitteen 192.168.133.254. Käytetään välityspal- velimen sisällä verkkoa 192.168.7.0/24, vaikka samannimistä verkkoa käytetään myös 46 työkoneen sisällä. Periaatteessa voitaisiin käyttää jotain muutakin verkkoa, mutta koros- tetaan tällä sitä, että vaikka verkoilla on sama osoite, niin ne ovat kuitenkin täysin eri verkkoja, koska verkot on eristetty toisistaan. Muutenkin työkoneita on oikeasti monta ja niillä kaikilla on käytössään samanniminen verkko. Koska kaikkialla on käytössä sa- manniminen verkko, niin ylläpito helpottuu jonkin verran. Koska suunnitelman mukaan välityspalvelimen ohjausyksiköllä on kiinteä IP-osoite, niin välityspalvelimen langallisessa lähiverkossa ei ole tarvetta DHCP-palvelulle, sillä myös reitittimien Ethernet-sovittimilla on kiinteät IP-osoitteet. Koska verkko on 192.168.7.0/24, niin laitteilla on käytössä jälleen 254 osoitetta. Osoitteet voitaisiin jakaa mielivaltaisesti laitteiden kesken, mutta selkeyden vuoksi määritetään tukiasemareitit- timen Ethernet-sovittimelle osoite 192.168.7.1 ja asiakasreitittimen Ethernet- sovittimelle osoite 192.168.7.2. Osoite 192.168.7.2 eli asiakasreitittimen Ethernet- sovitin pitää määrittää välityspalvelimen ohjausyksikön yhdyskäytäväksi, sillä ainoas- taan asiakasreitittimen kautta on pääsy internetiin. Lisäksi määritetään ohjausyksikölle osoite 192.168.7.10. Ainoa sovitin, joka saa osoitteen DHCP-palvelimelta, on langatto- mana asiakkaana toimivan reitittimen langaton verkkosovitin. Se yhdistyy tehtaan tu- kiasemaan ja saa sieltä osoitteensa. Nyt jos TCP-paketti on lähdössä työkoneelta ja yhteyttä internetiin ei ole, mutta välitys- palvelin on kantaman sisällä, niin työkoneen langattomana asiakkaana toimiva reititin yhdistyy välityspalvelimen tukiasemaan ja saa sieltä osoitteen 192.168.133.254. Paketti kulkee nyt työkoneen ohjausyksiköltä osoitteesta 192.168.7.254 työkoneen langattoman reitittimen Ethernet-sovittimelle osoitteeseen 192.168.7.1. Reitittimessä tehdään lähde- osoitteenmuunnos ja paketti lähtee välityspalvelimen tukiaseman langattomalle verk- kosovittimelle osoitteeseen 192.168.133.1. Kun paketti saapuu välityspalvelimen tu- kiaseman langattomaan verkkosovittimeen, niin tukiasemana toimivalle reitittimelle määritelty kohdeosoitteenmuunnos (DNAT kuvissa 11 ja 12) muuntaa välityspalveli- men ohjausyksikön osoitteen näyttäytymään REST-palvelimen osoitteena. Tämä tar- koittaa sitä, että osoite 192.168.7.10 muunnetaan osoitteeksi x.y.z.a. 47 Kohdeosoitteenmuunnoksen käytössä on kuitenkin se ongelma, että se ei kerro paluupa- ketille reittiä takaisin, joten yhteys ei vielä toimi. Paketin pitäisi löytää verkko 192.168.133.0/24, jossa se oli viimeksi. Ainoa osoite, jonka takaa tämä verkko löytyy, on tukiasemana toimivan reitittimen Ethernet-sovittimen osoite 192.168.7.1. Koska määrittelimme välityspalvelimen langallisen lähiverkon yhdyskäytäväksi langattomana asiakkaana toimivan reitittimen Ethernet-sovittimen eli osoitteen 192.168.7.2, niin pa- ketti yrittäisi normaalisti sitä kautta löytää reittiä takaisin, mikä ei tietenkään ikinä on- nistu. Jos langallisen lähiverkon yhdyskäytäväksi olisikin määritetty tukiaseman Ether- net-sovittimen osoite 192.168.7.1, niin paketti löytäisi verkon 192.168.133.0/24 sen ta- kaa, mutta silloin välityspalvelimen internet-yhteys ei toimisi, koska osoite 192.168.7.2 ei ole yhdyskäytävänä. Tässä tilanteessa paketille pitää siis kertoa minkä osoitteen kaut- ta tähän verkkoon pääsee. Lisätään siis verkko 192.168.133.0/24 ohjausyksikön reititys- tauluun ja osoite 192.168.7.1 yhdyskäytäväksi tähän verkkoon. Nyt paketti pääsee verk- koon 192.168.133.0/24. Tästä verkosta löytyy osoite 192.168.133.254, jossa tehdään kohdeosoitteenmuunnos ja paketti pääsee takaisin työkoneen ohjausyksikölle osoittee- seen 192.168.7.254. Nyt työkone on saanut paketin lähetettyä onnistuneesti ”REST-palvelimelle” eli oikeasti välityspalvelimen ohjausyksikölle ja voidaan ajatella, että paketti on tallennettu ohjaus- yksikölle. Tässä vaiheessa ohjausyksikön tuleva ohjelmisto suorittaisi toimenpiteitä, joiden jälkeen paketti voitaisiin lähettää oikealle palvelimelle sitten, kun välityspalveli- mella on internet-yhteys käytettävissä. Koska yhdyskäytäväksi on määritetty asiakasrei- tittimen Ethernet-sovittimen osoite 192.168.7.2, niin paketti yrittää tämän kautta löytää reittiä REST-palvelimelle. Tämä onnistuu tietenkin vain silloin, kun reitittimen langaton verkkosovitin on yhteydessä tehtaan tukiasemaan. Tällöin paketti lähtee ohjausyksiköltä osoitteesta 192.168.7.10 ja etenee osoitteeseen 192.168.7.2. Sieltä paketti etenee edel- leen reitittimen lähdeosoitteenmuunnoksen jälkeen tehtaan langattomaan lähiverkkoon i.j.k.0/24, sillä välityspalvelimen asiakasreitittimen langaton verkkosovitin on saanut tehtaan tukiaseman DHCP-palvelimelta osoitteen i.j.k.253. Nyt paketti pääsee tehtaan tukiaseman langattomalle verkkosovittimelle osoitteeseen i.j.k.1 ja sieltä edelleen teh- taan langalliseen lähiverkkoon. Tästä eteenpäin tilanne on sama, kuin tilanteessa ilman välityspalvelinta, jolloin paketti kulkee internetin kautta REST-palvelimelle osoittee- 48 seen x.y.z.a. Paluupaketti kulkee samaa reittiä vastakkaisessa järjestyksessä takaisin vä- lityspalvelimen ohjausyksikölle. Välityspalvelimen asiakasreitittimen kohdeosoitteen- muunnoksen avulla paluupaketti pääsee ohjausyksikölle. 4.4 Laitteistoarkkitehtuuri Uuden järjestelmän laitteistoa tarkasteltaessa pitää ottaa huomioon vain työkoneen ja välityspalvelimen laitteisto, sillä ReDi-osuuden laitteistoon ei voida tässä tapauksessa vaikuttaa millään tavalla – eikä tarvitsekaan. Suunniteltavaksi jää siten työkoneen ja vä- lityspalvelimen laitteisto. Uusi järjestelmä ReDi pois lukien koostuu Exertuksen ohja- usyksiköistä, langattomista reitittimistä ja verkkokytkimestä. Aiemmin kuvatun suunni- telman mukaan välityspalvelimeen tarvitaan yksi ohjausyksikkö, kaksi langatonta reiti- tintä ja nämä yhdistävä verkkokytkin. Tiedonsiirron näkökulmasta työkoneen laitteisto koostuu yhdestä ohjausyksiköstä ja yhdestä langattomasta reitittimestä. Koska välitys- palvelimessa ja työkoneissa käytetään samoja reitittimiä, niin ei ole tarpeen käydä niitä erikseen läpi. 4.4.1 Reititin Reititin on verkkokerroksen laite, joka hallitsee IP-tason protokollat. Se osaa reitittää IP-paketit kohdeverkkoon. (Kaario 2002: 31.) Uudessa järjestelmässä käytettävä reititin on merkiltään Mikrotik ja malliltaan Metal. Metal-sarja on vahvistettu mallisarja, eli se on vedenpitävä ja kestää iskuja. Lisäksi se pystyy toimimaan suurella lämpötilavälillä. Ominaisuuksiltaan reititin on todella moni- puolinen, sillä siitä löytyy todella paljon eri toimintoja. (Mikrotik 2017a.) Reitittimen asetuksien säätämiseen voidaan käyttää internet-selaimella toimivaa Webfig-ohjelmaa (Mikrotik 2012) tai Windows-käyttöjärjestelmällä toimivaa Winbox-ohjelmaa (Mikrotik 2018). Edellä mainitut säätötyökalut ovat graafisia. Myös Telnet-ohjelmaa voidaan käyttää, jolloin kaikki tehdään komentokehotteessa (Mikrotik 2007). 49 Mikrotik Metal-reitittimiä on saatavilla eri taajuusalueille standardin 802.11b/g/n mu- kaisesti. Vaihtoehtoja ovat Metal 2, Metal 5, Metal 52 ja Metal 9. Mallin numero viittaa langattoman verkon taajuuteen. Metal 2:n taajuus on 2,4 Ghz ja Metal 5:n taajuus on 5 GHz. Metal 52-mallissa molemmat taajuudet ovat valittavissa, jolloin voidaan käyttää joko 2,4 GHz:n taajuutta tai 5 GHz:n taajuutta. Metal 9 on erityinen 900 MHz:n malli. Mikrotik Metal-reitittimiin saa tarvittaessa hyvinkin suuren lähetystehon riippuen taa- juudesta ja tiedonsiirtonopeudesta. Suurimmillaan voidaan käyttää jopa 32 dBm:n eli noin 1585 mW:n lähetystehoa. (Mikrotik 2017a.) Lähetystehoa määriteltäessä on huo- mioitava maakohtaiset lähetystehorajoitukset, eli mikä on suurin sallittu lähetysteho ky- seessä olevalla taajuusalueella. Esimerkiksi Suomessa standardin 802.11b/g/n mukaisen datasiirtolaitteen suurin sallittu efektiivinen säteilyteho isotrooppisesta antennista on 100 mW taajuusalueella 2400–2483,5 MHz (Viestintävirasto 2018: 10). Käytännössä tämä tarkoittaa sitä, että jos antennin vahvistus on 0 desibeliä isotrooppiseen antenniin verrattuna, niin lähetysteho voidaan asettaa arvoon 100 mW. Jos taas antennin vahvistus on suurempi, täytyy lähetystehoa vastaavasti pienentää, jotta efektiivinen säteilyteho ei ylity. (Williams, Graham, Layer & Osenkowsky 2007: 1632.) Antennin vahvistus voi- daan merkitä desibeleinä isotrooppiseen antenniin verrattuna tai puoliaaltodipolianten- niin verrattuna. Näitä merkitään yksiköillä dBi ja dBd. 0 dBd:n vahvistus vastaa 2,14 dBi:n vahvistusta. Antennia varten reitittimestä löytyy jykevä N-liitin. Diplomityössä käytetään antenneina 6 dBi:n ympärisäteileviä vertikaaliantenneja, jotka toimitettiin rei- tittimien mukana. Mikrotik Metal-reititin käyttää PoE-tekniikkaa, jossa laitteen tarvitsema virta syötetään parikaapelin avulla eli samalla kaapelilla, missä data kulkee (Mikrotik 2017a). Tässä on se hyvä puoli, että reitittimelle kulkee vain yksi kaapeli, jossa kulkee sekä data että vir- ta. Tämä mahdollistaa ennen kaikkea sen, että reititin voidaan sijoittaa mahdollisimman ylös samalle korkeudelle kuin mihin antenni sijoitettaisiin. Näin antenni voidaan kiinnit- tää suoraan reitittimeen, jolloin reitittimen ja antennin välistä siirtolinjaa eli tässä tapa- uksessa koaksiaalikaapelia ei tarvita ollenkaan. Näin reitittimeltä lähtevä radioteho saa- daan hyödynnettyä mahdollisimman tehokkaasti suoraan antennissa ja tehohäviöt ovat mahdollisimman pienet. Parikaapelissa sen sijaan virta ja erityisesti data liikkuvat sa- manpituisella matkalla huomattavasti tehokkaammin. Parikaapelilla voi olla pituutta 50 enimmillään 100 metriä (Maniktala 2013: 39). Työkoneen tapauksessa tehohäviö koak- siaalikaapelissa ei olisi kuitenkaan kovin mittava, sillä puhutaan muutamista metreistä työkoneen sisältä ulkopuolelle, mutta sekin kuitenkin vaikuttaa jonkin verran näin suu- rilla taajuuksilla. Lisäksi erilaisten kaapeleiden vähentäminen helpottaa asennusta ylei- sesti. 4.4.2 Verkkokytkin Verkkokytkin on siirtoyhteyskerroksen laite. Se välittää eri lähdeporteista eri kohde- portteihin kulkevaa liikennettä samanaikaisesti liityntöjensä välillä. (Kaario 2002: 30). Verkkokytkimenä käytetään asennusvaiheessa ZyXEL-merkkistä GS-108B-mallin verkkokytkintä, jossa on kahdeksan porttia. Tätä ei tulla käyttämään tuotantoversiossa, vaan siinä tullaan käyttämään jotain vahvistettua verkkokytkintä, joka sopii paremmin kyseessä oleviin olosuhteisiin. Tässä vaiheessa ei ole väliä mitä verkkokytkintä käyte- tään, sillä verkkokytkimen toiminta pysyy samanlaisena, vaikka merkki tuleekin vaih- tumaan. 4.4.3 Ohjausyksikkö Välityspalvelimessa tullaan käyttämään MID070S-ohjausyksikköä. Se on Exertuksen kehittämä, sulautetulla Linux-käyttöjärjestelmällä varustettu ohjausyksikkö, jossa on myös oma näyttö ja navigointinäppäimistö. Diplomityön kannalta ohjausyksikön tär- keimmät ominaisuudet ovat juuri Linux-käyttöjärjestelmä ja Ethernet-liitäntä. Ohjaus- yksikön Linux sisältää ainoastaan komentorivikäyttöliittymän. Lisäksi Linuxissa käyte- tään Busybox-ohjelmaa, joka sisältää yleisimmät UNIX-työkalut pieneen kokoon pakat- tuna. Komentotulkkina on Almquist shell. Työkoneessa käytetään diplomityön aikana MIC1100S-ohjausyksikköä. Normetin työ- koneissa käytetään muitakin ohjausyksiköitä, mutta tässä vaiheessa ei ole väliä mitä oh- jausyksikköä käytetään, sillä kaikista löytyy Linux-käyttöjärjestelmä ja Ethernet- 51 liitäntä, joita nyt tarvitaan. Tässä ohjausyksikössä ei siis ole omaa näyttöä, mutta siihen voi halutessaan kytkeä erillisen näytön. Koska ohjausyksiköiden Linux on Debian-pohjainen, niin verkkoasetusten määrittämi- seen voidaan käyttää tiedostoa /etc/network/interfaces. Tämän tiedoston avulla voidaan esimerkiksi määritellä käyttääkö Linux kiinteitä IP-parametrejä vai saako se ne DHCP- palvelimelta. (LaCroix 2015: 57–61.) Tiedoston manuaalisivulta löytyy perustietoa tie- doston käytöstä. Manuaalisivun saa näkyviin Linuxissa komennolla man 5 interfaces. Pakatusta tiedostosta /usr/share/doc/ifupdown/examples/network-interfaces.gz löytyy lisäksi esimerkkejä interfaces-tiedostosta. 4.5 Ohjelmistoarkkitehtuuri Välityspalvelimen ohjelmistoarkkitehtuuri ei ole kovin suuressa osassa tässä diplomi- työssä, sillä pääpaino on juuri verkkoarkkitehtuurissa. Koska välityspalvelimen tekniik- ka suunnitellaan verkkolaitteisto edellä, niin ohjelmisto voidaan myöhemmin räätälöidä tarpeen mukaan. 52 5 ASENNUS Uutta järjestelmää lähdetään rakentamaan siten, että se jaetaan pienempiin osakokonai- suuksiin sen mukaan mistä ja mihin dataa lähetetään yhdellä kertaa. Tällaisia tapauksia ovat yhteydet työkoneelta REST-palvelimelle, työkoneelta välityspalvelimelle ja väli- tyspalvelimelta REST-palvelimelle. Vaikka toteutuksessa keskitytään laitteisto- ja verkkoarkkitehtuurin rakentamiseen, niin järjestelmän tuotantoversio rakennetaan laitteiston osalta Normetin toimesta. Tässä käy- tävä toteutus on siten edelleen suunnitelma lopullista laitteistokokoonpanoa silmällä pi- täen ja tähän eivät sisälly esimerkiksi akku ja latauskomponentit. Tarkoitus onkin raken- taa toimivaksi todettu verkkolaitteisto lopullista tuotetta varten. Vaikka Mikrotik-reitittimien asennus olisi havainnollisempaa tehdä Winbox-ohjelmalla graafisesti, niin käytetään siitä huolimatta Telnet-ohjelmaa asetuksien asettamiseen, sillä sen käyttö on huomattavasti tehokkaampaa. Asetuskomennot voidaan liittää osaksi teks- tiä, mikä vie vähemmän tilaa kuin kuvien käyttö. Komennot on muodostettu Discherin (2011: 66–98, 160–167, 209–219) ja Burgessin (2011: 80–105, 124–168, 202–212) kir- joissa esitettyjen teorioiden ja esimerkkien pohjalta. Huomautettakoon vielä, että reitit- timille on tehty tehdasasetusten palautus ja kaikki vakiona tulevat asetukset on otettu pois käytöstä. Asennuksen yhteydessä tarvitaan tehtaan langattoman verkon SSID ja WPA2-avain. Koska nämä eivät ole tiedossa ja muuttuvat toimijasta riippuen, sovitaan tässä, että asennuksen yhteydessä tehtaan langattoman verkon SSID on factory ja WPA2-avain IJK12kji. Myös välityspalvelimen tukiasema käyttää WPA2-todennusta. Olkoon sen avain XYZ98zyx ja SSID proxy. Edellä mainitut avaimet ja SSID:t ovat esimerkkejä, eikä niitä tulla käyttämään järjestelmän tuotantoversiossa. Sovitaan myös, että koko jär- jestelmässä käytetään kaikissa langattomissa reitittimissä 2,4 GHz:n taajuutta, joten Mikrotik-reitittimen täytyy olla malliltaan Metal 2 tai Metal 52. 53 Ohjausyksiköiden asentamisessa käytetään niiden Linux-käyttöjärjestelmiä. Ohjausyk- siköiden asennus kattaa verkkoasetusten määrittämisen. 5.1 Työkone Aloitetaan asentaminen työkoneen laitteistosta. Tähän sisältyvät ohjausyksikön ja lan- gattoman reitittimen asennus. Työkoneen laitteistosta asennetaan ensimmäisenä ohjaus- yksikkö, jonka jälkeen reititin asennetaan langattomaksi asiakkaaksi. 5.1.1 Ohjausyksikkö Suunnitelman mukaan työkoneen ohjausyksikkö saa IP-parametrit reitittimen DHCP- palvelimelta. Ohjausyksikön verkkoasetustiedostossa on tavallisesti DHCP-asetus va- kiona päällä, mutta tarkistetaan, että asetukset ovat oikein. Koska kyseessä on Debian- pohjainen Linux, niin asetukset ovat tiedostossa /etc/network/interfaces ja tiedoston pi- täisi olla seuraavanlainen: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp Aluksi siinä määritetään sisäinen verkkosovitin (lo) takaisinkaiutusosoitteeksi. Sen jäl- keen määritetään Ethernet-sovitin (eth0) saamaan IP-parametrit DHCP-palvelimelta. Näin ohjausyksiköltä lähtevä liikenne reitittyy oikein ja yhteys toimii odotetusti, sillä IP-osoite, aliverkon maski ja yhdyskäytävä tulevat ohjausyksikölle reitittimen DHCP- palvelimelta. 5.1.2 Reititin Työkoneen ohjausyksiköltä tulee siis olla yhteys internetiin tai vaihtoehtoisesti välitys- palvelimeen. Ideana onkin tehdä langattomana asiakkaana toimivaan reitittimeen kaksi profiilia, joista toinen on tarkoitettu tehtaan langattomaan lähiverkkoon ja toinen väli- 54 tyspalvelimen langattomaan lähiverkkoon. Tarvitaan siis tiedot tehtaan langattomasta lähiverkosta ja välityspalvelimen langattomasta lähiverkosta. Näiden avaimet ja SSID:t sovittiin aiemmin. Aloitetaan reitittimen asennus langattomasta verkkosovittimesta. Siinä reitittimen langa- ton verkkosovitin asetetaan toimimaan asiakastilassa, jolloin se voi yhdistyä tukiase- maan. Taajuudeksi asetetaan aiemmin sovittu 2,4 GHz. Langaton verkkosovitin asenne- taan seuraavalla komennolla: /interface wireless set [ find default-name=wlan1 ] band=2ghz-b/g/n \ channel-width=20/40mhz-Ce \ default-authentication=no disabled=no \ frequency=auto mode=station ssid="" Luodaan tämän jälkeen turvallisuusprofiilit langattomille lähiverkoille, joita tässä tapa- uksessa ovat välityspalvelimen tukiaseman tarjoama langaton lähiverkko ja tehtaan lan- gaton lähiverkko. Molemmille verkoille tarvitaan omat turvallisuusprofiilit ja niille an- netaan yksilölliset nimet, joita tarvitaan asennuksen myöhemmässä vaiheessa. Annetaan profiileille nimet proxySP ja factorySP. Turvallisuusprofiilissa määritetään todennus- menetelmä, joka on molemmille verkoille aiemmin sovittu WPA2. Lisäksi asetetaan aiemmin sovitut WPA2-avaimet. Luodaan profiilit seuraavalla komennolla: /interface wireless security-profiles add authentication-types=wpa2-psk eap-methods="" \ group-ciphers=tkip,aes-ccm \ management-protection=allowed mode=dynamic-keys \ name=proxySP supplicant-identity="" \ unicast-ciphers=tkip,aes-ccm wpa2-pre-shared-key=\ XYZ98zyx add authentication-types=wpa2-psk eap-methods="" \ group-ciphers=tkip,aes-ccm \ management-protection=allowed mode=dynamic-keys \ name=factorySP supplicant-identity="" \ unicast-ciphers=tkip,aes-ccm wpa2-pre-shared-key=\ IJK12kji 55 Verkkoja varten tarvitaan lisäksi profiilit yhteysluetteloon. Yhteysluettelossa kerrotaan minkä nimiseen langattomaan verkkoon reititin yrittää yhdistyä ja mitä turvallisuuspro- fiilia juuri kyseisessä toimenpiteessä käytetään. Yhteysluettelon profiileja varten tarvi- taan langattomista lähiverkoista SSID ja turvallisuusprofiilin nimi. SSID on tehtaan esimerkkiverkossamme factory, ja vastaava turvallisuusprofiilin nimi factorySP. Väli- tyspalvelimen SSID puolestaan on proxy ja vastaava turvallisuusprofiilin nimi on pro- xySP. Yhteysluettelon profiiliin pitää määrittää myös yhteyden voimakkuusväli. Tällä tarkoitetaan väliä, jolla nyt kyseessä oleva asiakasreititin yrittää yhdistyä kyseiseen lan- gattomaan verkkoon. Vastaavasti jos kyseiseen verkkoon ollaan yhdistyneenä ja signaa- lin voimakkuus ei ole tällä välillä, yhteys katkaistaan. Voimakkuusväli annetaan desibe- limilliwatteina. Käytetään molemmissa verkoissa väliä -70–120. Edellä mainitut asetuk- set lisätään seuraavalla komennolla: /interface wireless connect-list add interface=wlan1 security-profile=proxySP \ signal-range=-70..120 ssid=proxy add interface=wlan1 security-profile=factorySP \ signal-range=-70..120 ssid=factory Huomautettakoon, että yhteysluetteloon voi lisätä haluamansa määrän profiileja, joilla on prioriteetti. Tässä tapauksessa prioriteetti määräytyy profiilin luontiajan mukaan, eli tämä reititin yrittäisi ensisijaisesti liittyä välityspalvelimen langattomaan verkkoon ja jos se ei onnistu, niin se yrittää liittyä tehtaan verkkoon. Lisäksi jos reititin on yhdisty- nyt toissijaiseen verkkoon, yhteyttä ei katkaista, vaikka ensisijainen verkko tulisikin kuuluviin. Jos yhteysluetteloon haluttaisiin lisätä profiileja, täytyy kaikille luoda myös omat turvallisuusprofiilit. Määritetään seuraavaksi IP-asetukset reitittimelle. Reitittimen Ethernet-sovitin sijaitsee ohjausyksikön kanssa samassa lähiverkossa ja kuten ohjausyksiköstä aiemmin kerrot- tiin, se saa IP-osoitteensa ulkoiselta DHCP-palvelimelta. Suunnitelman mukaan verkko, jossa työkoneen laitteet sijaitsevat on 192.168.7.0/24. Reitittimen Ethernet-sovittimelle määritetään osoite 192.168.7.1, joka on verkon yhdyskäytävä. DHCP-palvelin asetetaan jakamaan osoitteita tästä verkosta, jolloin mahdolliset osoitteet ovat välillä 192.168.7.2– 192.168.7.254. Sen sijaan reitittimen langaton verkkosovitin saa asiakkaana osoitteensa 56 ulkoiselta DHCP-palvelimelta eli joko tehtaan tukiasemalta tai välityspalvelimen tu- kiasemalta. Se pitää siten määrittää DHCP-asiakkaaksi. IP-asetukset määritetään seu- raavalla komennolla: /ip pool add name=default-dhcp \ ranges=192.168.7.2-192.168.7.254 /ip dhcp-server add address-pool=default-dhcp disabled=no \ interface=ether1 name=defconf /ip address add address=192.168.7.1/24 interface=ether1 \ network=192.168.7.0 /ip dhcp-client add comment=defconf dhcp-options=hostname,clientid \ disabled=no interface=wlan1 /ip dhcp-server network add address=192.168.7.0/24 gateway=192.168.7.1 Suunnitelman mukaan työkoneen reitittimen Ethernet-sovittimen ja langattoman verk- kosovittimen välille tarvitaan osoitteenmuunnos. Koska kyseessä on täysimääräinen osoitteenmuunnos, niin tarvitaan lähdeosoitteenmuunnos ja kohdeosoitteenmuunnos. Näistä lähdeosoitteenmuunnos on vielä tarkemmin masquerade, koska käytetään langa- tonta verkkosovitinta, jolloin lähdeosoitetta ei muuteta miksikään yksittäiseksi IP- osoitteeksi. Mikrotik-reitittimillä täysimääräinen osoitteenmuunnos toteutetaan siten, että lähdeosoitteenmuunnos määritetään reitittimen osoitteenmuunnosasetuksiin ja koh- deosoitteenmuunnos reitittimen palomuuriasetuksiin. Luodaan lähdeosoitteenmuunnos seuraavalla komennolla: /ip firewall nat add action=masquerade chain=srcnat out-interface=wlan1 Kuten edellä mainittiin, määritetään kohdeosoitteenmuunnos tässä tapauksessa palo- muuriasetuksiin. Näin kohdeosoitteenmuunnos saadaan toimimaan oikein paluupake- teille. Varmistetaan palomuurilla myös se, että esimerkiksi langattomasta lähiverkosta ei ole suoraa pääsyä langallisen lähiverkon laitteille. Tarvittavat asetukset palomuuriin asetetaan seuraavalla komennolla: 57 /ip firewall filter add chain=input comment=\ "defconf: accept established,related" \ connection-state=established,related add action=drop chain=input comment=\ "defconf: drop all from WAN" in-interface=wlan1 add chain=forward comment=\ "defconf: accept established,related" \ connection-state=established,related add action=drop chain=forward comment=\ "defconf: drop invalid” connection-state=invalid add action=drop chain=forward comment=\ "defconf: drop all from WAN not DST-NATed" \ connection-nat-state=!dstnat \ connection-state=new in-interface=wlan1 Työkoneen reititin on nyt asennettu langattomaksi asiakkaaksi ja sille on asetettu tarvit- tavat tiedot, joilla se voi muodostaa yhteyden langattomiin lähiverkkoihin. 5.2 Välityspalvelin Nyt kun työkoneen verkko on rakennettu, voidaan lähteä rakentamaan välityspalvelimen verkkoa. Välityspalvelimen tapauksessa asennetaan ohjausyksikkö ja kaksi langatonta reititintä, joista toinen asennetaan tukiasemaksi ja toinen langattomaksi asiakkaaksi. Edetään asennuksessa tiedonkulun suunnan mukaan eli kun järjestelmää käytetään, pa- ketti saapuu ensimmäisenä tukiasemareitittimelle, josta se etenee ohjausyksikölle ja sieltä edelleen asiakasreitittimelle. Ensimmäisenä asennetaan reititin tukiasemaksi, jon- ka jälkeen tehdään tarvittavat asetukset ohjausyksikköön ja lopuksi asennetaan jäljelle jäänyt reititin langattomaksi asiakkaaksi. 5.2.1 Tukiasemareititin Aloitetaan välityspalvelimen tukiaseman asennus määrittämällä turvallisuusprofiili, sillä sitä tarvitaan langattoman verkkosovittimen asentamiseen. Määritetään ensinnäkin tur- vallisuusprofiilin nimi. Sen ei tarvitse olla sama kuin työkoneella, mutta käytetään tässä silti samaa nimeä, joka on siis proxySP, sillä se kuvaa hyvin kyseessä olevaa profiilia. 58 Lisäksi määritetään käytettävä todennusmenetelmä, joka on tässä tapauksessa WPA2. Asetetaan myös WPA2-avain, jonka tukiasemaan liittyvän asiakkaan täytyy tietää. Tä- mä on sama avain, joka määritettiin työkoneenkin reitittimelle. Edellä mainitut toimin- not asennetaan seuraavalla komennolla: /interface wireless security-profiles add authentication-types=wpa2-psk eap-methods="" \ group-ciphers=tkip,aes-ccm \ management-protection=allowed mode=dynamic-keys \ name=proxySP supplicant-identity="" \ unicast-ciphers=tkip,aes-ccm wpa2-pre-shared-key=\ XYZ98zyx Seuraavaksi tehdään määritykset langattomaan verkkosovittimeen. Tehdään reitittimestä tukiasema siten, että muutetaan reitittimen toimintatila tukiasemaksi. Riippuen Mikrotik Metal-mallista, taajuus voidaan valita tässä vaiheessa. Aiemmin sovimme koko järjes- telmän kattavaksi taajuudeksi 2,4 GHz, joten käytetään sitä. Valitaan tukiasemalle SSID, joka tässä tapauksessa on proxy. Tässä vaiheessa valitaan myös tukiaseman lähe- tysteho. Tukiasemaa asennettaessa täytyy ottaa huomioon lähetystehon suuruus. Langat- tomaksi asiakkaaksi asennettaessa lähetystehoasetusta ei oteta huomioon, sillä tieto tar- vittavasta lähetystehosta tulee tukiasemalta. Kuten standardin IEEE 802.11 mukaisista datasiirtolaitteista aiemmin mainittiin, suurin sallittu lähetysteho Suomessa on 100 mW (EIRP). Reitittimessä lähetystehon voisi asettaa käsin desibelimilliwatteina, jolloin 100 mW olisi 20 dBm. Koska antennina käytetään 6 dBi:n antennia, täytyy lähetysteho mi- toittaa sen mukaan. Tätä ei kuitenkaan tarvitse itse laskea, sillä reitittimessä on auto- maattinen laskuri tätä varten. Sille asetetaan maa ja antennin vahvistus, jonka yksikkö on dBi. Näiden parametrien perusteella reititin osaa itse mitoittaa tarvittavan lähetyste- hon, sillä reitittimellä on tieto maakohtaisista lähetystehorajoituksista. Tässä ei kuiten- kaan oteta huomioon siirtolinjassa tapahtuvia häviöitä, jotka voisi periaatteessa vähen- tää antennin vahvistuksesta. Tällöin reitittimestä lähtevä teho kasvaisi. Tässä tapaukses- sa antenni on kuitenkin kiinnitetty suoraan reitittimeen, joten tätä ei tarvitse huomioida. Muutenkin siirtolinjan pitäisi olla hyvin pitkä, jotta sen aiheuttama häviö voitaisiin vä- hentää antennin vahvistuksesta, sillä antennin vahvistusasetukseen voidaan asettaa vain 59 kokonaislukuarvoja. Edellä mainittujen seikkojen perusteella langaton verkkosovitin asennetaan seuraavanlaisella komennolla: /interface wireless set [ find default-name=wlan1 ] antenna-gain=6 \ band=2ghz-b/g/n channel-width=20/40mhz-Ce \ country=finland disabled=no frequency=auto \ mode=ap-bridge security-profile=proxySP ssid=proxy Tämän jälkeen määritetään IP-asetukset. Suunnitelman mukaan langallinen lähiverkko on 192.168.7.0/24 ja langaton lähiverkko on 192.168.133.0/24. Verkkosovittimien IP- osoitteet ovat edellä mainituissa verkoissa 192.168.7.1 ja 192.168.133.1. Lisäksi langat- tomassa lähiverkossa täytyy olla DHCP-palvelu toiminnassa, joten määritetään DHCP- palvelin antamaan osoitteita asiakkaille siten, että osoiteavaruus on 192.168.133.2– 192.168.133.254. Tällöin asennuskomento on seuraavanlainen: /ip pool add name=dhcp ranges=192.168.133.2-192.168.133.254 /ip dhcp-server add address-pool=dhcp disabled=no interface=wlan1 \ name=dhcp1 /ip address add address=192.168.7.1/24 interface=ether1 \ network=192.168.7.0 add address=192.168.133.1/24 interface=wlan1 \ network=192.168.133.0 /ip dhcp-server network add address=192.168.133.0/24 gateway=192.168.133.1 Määritetään seuraavaksi osoitteenmuunnos. Suunnitelman mukaan tässä tulee käyttää kohdeosoitteenmuunnosta, joka muuntaa osoitteen x.y.z.a ohjausyksikön osoitteeksi 192.168.7.10. Tässä tapauksessa sallitaan vain TCP-yhteydet. Tämä asetetaan seuraa- valla komennolla: /ip firewall nat add action=dst-nat chain=dstnat dst-address=x.y.z.a \ protocol=tcp to-addresses=192.168.7.10 60 Reitittimen palomuuriin tarvitaan lisäksi oikeanlaiset asetukset, joilla mahdollistetaan reitittimen oikeanlainen toiminta verkkojen osalta. Asetukset palomuuriin asetetaan seu- raavalla komennolla: /ip firewall filter add chain=input comment=\ "defconf: accept established,related" \ connection-state=established,related add action=drop chain=input comment=\ "defconf: drop all from WAN" in-interface=wlan1 add chain=forward comment=\ "defconf: accept established,related" \ connection-state=established,related add action=drop chain=forward comment=\ "defconf: drop invalid” connection-state=invalid add action=drop chain=forward comment=\ "defconf: drop all from WAN not DST-NATed" \ connection-nat-state=!dstnat \ connection-state=new in-interface=wlan1 Reititin on nyt asennettu tukiasemaksi. 5.2.2 Ohjausyksikkö Välityspalvelimen verkkoarkkitehtuurin näkökulmasta ohjausyksikölle täytyy asettaa kiinteä IP-osoite ja yhdyskäytävä. Lisäksi täytyy kertoa reitti ohjausyksiköltä tukiase- man puoleiselle langattomalle lähiverkolle. Tiedostossa /etc/network/interfaces verkko- asetukset ovat normaalisti seuraavanlaiset: auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp Siinä määritetään sisäinen verkkosovitin (lo) takaisinkaiutusosoitteeksi. Lisäksi määrite- tään Ethernet-sovitin (eth0) saamaan IP-parametrit DHCP-palvelimelta. Suunnitelman mukaan välityspalvelimen lähiverkossa ei käytetä DHCP-palvelua ollenkaan, vaan oh- jausyksikölle ja reitittimille asetetaan kiinteät IP-osoitteet. Ohjausyksikön verkkoase- tuksia täytyy muokata siten, että sille tulee kiinteä IP-osoite, joten asetetaan tiedostoon 61 IP-osoitteeksi suunniteltu 192.168.7.10. Lisäksi täytyy määrittää aliverkon maski, joka tässä tapauksessa on 255.255.255.0. IP-osoitteesta ja maskista käyttöjärjestelmä laskee käytettävän verkon (192.168.7.0/24) ja levitysviestiosoitteen (192.168.7.255) automaat- tisesti, joten niitä ei tähän tarvitse erikseen asettaa. Yhdyskäytävä sen sijaan merkitään tiedostoon. Suunnitelman mukaan ohjausyksikön yhdyskäytäväksi tulee 192.168.7.2. Näillä asetuksilla ohjausyksikkö pystyy lähettämään paketin eteenpäin yhdyskäytävälle, mutta tukiasemana toimivan reitittimen kohdeosoitteenmuunnoksen kautta tulleet pake- tit eivät vielä löydä reittiä takaisin lähettäjälle. Asetetaan tiedostoon reitti verkkoon 192.168.133.0/24, joka löytyy osoitteen 192.168.7.1 takaa. Näin paketit osaavat takaisin siihen verkkoon, jossa olivat ennen kohdeosoitteenmuunnosta. Muokkauksien jälkeen interfaces-tiedosto näyttää seuraavanlaiselta: auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.7.10 netmask 255.255.255.0 gateway 192.168.7.2 up route add -net 192.168.133.0/24 gw 192.168.7.1 5.2.3 Asiakasreititin Välityspalvelimen sisällä verkko on nyt rakennettu tukiaseman ja ohjausyksikön välille. Vielä täytyy asentaa jäljelle jäänyt reititin langattomaksi asiakkaaksi välityspalvelimen verkkoon. Jotta välityspalvelimen reititin voidaan asentaa asiakastilaan, tarvitaan tiedot tehtaan langattomasta lähiverkosta. Tarvittavia tietoja ovat jälleen SSID, käytettävä to- dennusmenetelmä, todennusmenetelmän mukainen avain ja langattoman verkon taajuus. Aloitetaan reitittimen asennus määrittämällä langattoman verkkosovittimen asetukset. Reitittimestä tehdään nyt langaton asiakas tukiaseman sijaan, eli se voi liittyä langatto- maan lähiverkkoon aivan kuten työkoneenkin reititin. Tässä vaiheessa asetetaan myös toimintataajuus, joka esimerkkiverkossamme on 2,4 GHz. Nämä asetukset asetetaan seuraavalla komennolla: 62 /interface wireless set [ find default-name=wlan1 ] band=2ghz-b/g/n \ channel-width=20/40mhz-Ce \ default-authentication=no disabled=no \ frequency=auto mode=station ssid="" Seuraavaksi luodaan turvallisuusprofiili tehtaan verkkoa varten. Tässä voidaan käyttää täsmälleen samaa profiilia, jota käytettiin toisena profiilina työkoneen reitittimessä. An- netaan profiilille nimeksi tässäkin tapauksessa factorySP. Lisäksi määritetään toden- nusmenetelmäksi jälleen WPA2 ja avaimeksi sama avain kuin työkoneenkin tapaukses- sa. Luodaan turvallisuusprofiili seuraavalla komennolla: /interface wireless security-profile add authentication-types=wpa2-psk eap-methods="" \ group-ciphers=tkip,aes-ccm \ management-protection=allowed mode=dynamic-keys \ name=factorySP supplicant-identity="" \ unicast-ciphers=tkip,aes-ccm wpa2-pre-shared-key=\ IJK12kji Tehtaan langatonta lähiverkkoa varten tarvitaan vielä profiili yhteysluetteloon. Yhteys- luettelon profiilia varten tarvitaan SSID ja turvallisuusprofiilin nimi. SSID on esimerk- kiverkossamme factory, ja turvallisuusprofiilin nimi on factorySP. Yhteysluettelon pro- fiiliin pitää määrittää myös signaalin voimakkuusväli desibelimilliwatteina eli väli, jolla asiakasreititin yrittää yhdistyä kyseessä olevaan langattomaan lähiverkkoon. Käytetään tässä tapauksessa väliä -70–120. Nämä asetukset lisätään seuraavalla komennolla: /interface wireless connect-list add interface=wlan1 security-profile=factorySP \ signal-range=-70..120 ssid=factory Toisin kuin työkoneen tapauksessa, nyt yhteysluettelossa on vain yksi profiili. Tämä tarkoittaa yksinkertaisesti sitä, että langaton asiakas yrittää yhdistyä vain tähän verk- koon ja jos sitä ei ole saatavilla, yhteyttä ei muodosteta mihinkään. Seuraavaksi määritetään IP-asetukset. Reititin sijaitsee fyysisesti välityspalvelimen lä- hiverkossa, joka on 192.168.7.0/24. Suunnitelman mukaan langattoman verkkosovitti- men osoitteeksi tulee 192.168.7.2. DHCP-palvelinta ei tarvita, sillä välityspalvelimen 63 langallisessa lähiverkossa kaikilla laitteilla on kiinteä IP-osoite. Sen sijaan langattomana asiakkaana langattoman verkkosovittimen pitää saada osoitteensa tukiasemalta, joten asetetaan langaton verkkosovitin DHCP-asiakkaaksi. Edellä mainitut asetukset asete- taan seuraavalla komennolla: /ip address add address=192.168.7.2/24 interface=ether1 \ network=192.168.7.0 /ip dhcp-client add dhcp-options=hostname,clientid disabled=no \ interface=wlan1 Suunnitelman mukaan välityspalvelimen asiakasreitittimen Ethernet-sovittimen ja lan- gattoman verkkosovittimen välille tarvitaan täysimääräinen osoitteenmuunnos. Tässä tapauksessa tämä luodaan samalla tavalla kuin työkoneenkin tapauksessa, eli lähde- osoitteenmuunnos määritetään osoitteenmuunnosasetuksiin ja kohdeosoitteenmuunnos palomuuriasetuksiin. Määritetään lähdeosoitteenmuunnos seuraavalla komennolla: /ip firewall nat add action=masquerade chain=srcnat out-interface=wlan1 Palomuuriin asetetaan kohdeosoitteenmuunnos, kuten edellä mainittiin ja lisäksi perus- asetukset, jotka estävät suoran pääsyn verkosta toiseen. Asetetaan palomuuriasetukset seuraavalla komennolla: /ip firewall filter add chain=input comment=\ "defconf: accept established,related" \ connection-state=established,related add action=drop chain=input comment=\ "defconf: drop all from WAN" in-interface=wlan1 add chain=forward comment=\ "defconf: accept established,related" \ connection-state=established,related add action=drop chain=forward comment=\ "defconf: drop invalid” connection-state=invalid add action=drop chain=forward comment=\ "defconf: drop all from WAN not DST-NATed" \ connection-nat-state=!dstnat \ connection-state=new in-interface=wlan1 64 Välityspalvelimen toinen reititin on nyt asennettu langattomaksi asiakkaaksi ja sillä on tarvittavat tiedot, joilla se voi liittyä tehtaan langattomaan lähiverkkoon. 65 6 TESTAUS Nyt kun kaikki laitteet on asennettu suunnitelman mukaisesti, niin tietoliikennettä voi- daan testata. Testataan tietoliikenteen toimivuutta ohjausyksiköiden välillä, jolloin voi- daan olettaa, että myös reitittimet toimivat oikein, sillä ne ovat ohjausyksiköiden välis- sä. Myös REST-palvelin voidaan ottaa mukaan testaukseen, jolloin yhteys internetiin tulee testattua samalla. Ensimmäisessä testitapauksessa testataan yhteys työkoneen oh- jausyksiköltä REST-palvelimelle. Tämän jälkeen testataan yhteys työkoneen ohjausyk- siköltä välityspalvelimen ohjausyksikölle. Viimeisenä testataan yhteys välityspalveli- men ohjausyksiköltä REST-palvelimelle. Näin kuvassa 12 näkyvät reitit on käyty läpi. Edellä mainituissa tapauksissa tulevat testatuiksi langalliset lähiverkot ja välityspalve- limen osoitteenmuunnoksen- sekä reitityksen oikeanlainen toiminta. 6.1 Työkoneelta lähtevä tietoliikenne Työkoneelta lähtevien yhteyksien testaamisessa lähtöpiste on työkoneen ohjausyksikkö. Aluksi testataan yhteyden toimivuus REST-palvelimelle ja internetiin. Data kulkee työ- koneen ohjausyksiköltä työkoneen langattomaksi asiakkaaksi asennetulle reitittimelle, joka on liittynyt tehtaan langattomaan lähiverkkoon ja tästä verkosta on pääsy interne- tiin. Ennen varsinaisen yhteyden kokeilua on kuitenkin syytä testata reitittimen yhteysluette- lon toiminta. Tämä tarkoittaa sitä, että reitittimen langaton verkkosovitin todella liittyy yhteysluettelossa oleviin langattomiin verkkoihin. Tämän testaamiseen tarvitaan siten luettelossa mainittu langaton verkko ja koska nyt testataan yhteyttä internetiin ja REST- palvelimeen, tarvitaan tehtaan langaton lähiverkko. Jotta tätä verkkoa voitaisiin simu- loida, tarvitaan sen SSID ja WPA2-avain. Yhteysluettelossa määriteltiin tehdasverkon SSID:ksi factory ja WPA2-avaimeksi IJK12kji. Nyt tarvitaan vielä tukiasema, jolla on edellä mainittu SSID ja avain. Lisäksi tukiasemalta pitää olla yhteys internetiin, sillä simuloimme oikeaa tehtaan langatonta lähiverkkoa. Myös taajuus täytyy olla sama kuin reitittimessä eli tässä tapauksessa 2,4 GHz. Koska tukiasemalle ei ole muita erityisiä 66 vaatimuksia, voidaan yksinkertaisesti käyttää esimerkiksi älypuhelimesta löytyvää tu- kiasematoimintoa. Asetetaan oikea SSID, WPA2-avain ja taajuus. Yhdistyminen voi- daan havaita Winbox- tai Webfig-ohjelman Quick Set-välilehdeltä. Samalta välilehdeltä nähdään myös langattoman lähiverkon muita tietoja, joita ovat esimerkiksi SSID ja sig- naalin voimakkuus. Yhdistyminen voidaan havaita myös ilman ohjelmia reitittimessä olevien LED-valojen avulla. Nyt kun tukiasema käynnistetään, niin langaton asiakasrei- titin yhdistyy tukiasemaan. Voidaan siis todeta, että ainakin tehtaan verkkoon liittymi- nen toimii automaattisesti. Nyt voidaan kokeilla itse yhteyden toimivuutta työkoneen ohjausyksiköltä REST- palvelimelle, joka sijaitsee internetissä osoitteessa x.y.z.a. Yhteyttä voidaan kokeilla kätevästi lähettämällä POST-pyyntö REST-palvelimelle, sillä palvelin antaa vastauksen sen mukaan, hyväksyykö se sille lähetetyn datan. Palvelin ottaa vastaan vain tietyntyyp- pistä JSON-dataa, mutta lähetämme tässä vain yleistä tekstimuotoista dataa sen sijaan. POST-pyyntö voidaan lähettää esimerkiksi Linuxin komentokehotteessa ohjelmalla cURL. Lähetyskomento on seuraavanlainen: curl -–connect-timeout 5 –s –X POST \ –-data "yhteyskokeilu" x.y.z.a/jsonimport.php Kun pyyntö lähetetään, niin REST-palvelin vastaa lähettämällä seuraavanlaisen merkki- jonon: >>>R,ERS,DATANOTVALID<<< Palvelin ei siis huolinut vastaanottamaansa dataa, eikä siten tallentanut sitä tietokantaan. Se ei ollut tarkoituskaan, vaan tärkeintä on se, että palvelin lähetti vastauslähetyksen, jolloin voidaan olla varmoja siitä, että yhteys ohjausyksiköltä palvelimelle ja internetiin toimii. Seuraavaksi testataan yhteys työkoneen ohjausyksiköltä välityspalvelimen ohjausyksi- kölle. Tässä tapauksessa data kulkee ensin työkoneen ohjausyksiköltä reitittimelle, joka puolestaan on yhdistyneenä välityspalvelimen tukiasemaan. Tukiaseman kohdeosoit- 67 teenmuunnoksen kautta data kulkee edelleen välityspalvelimen ohjausyksikölle. Myös tässä tapauksessa testataan aluksi reitittimen yhdistyminen välityspalvelimen langatto- maan lähiverkkoon yhteysluettelon avulla. Nyt tukiasemana toimii välityspalvelimen oma tukiasema. Kun työkoneen reititin ja välityspalvelimen tukiasemana toimiva reititin käynnistetään, niin huomataan, että työkoneen reititin yhdistyy tukiasemaan automaatti- sesti, joten yhteysluettelon mukainen yhdistyminen toimii odotetusti. Nyt voidaan kokeilla yhteyden toimivuutta välityspalvelimen ohjausyksikölle. Tätä voi- daan testata yksinkertaisesti Linuxista löytyvällä ohjelmalla nimeltä Netcat. Sitä voi- daan käyttää TCP- ja UDP-yhteyksien muodostamiseen. Tässä tapauksessa välityspal- velimen ohjausyksikkö asetetaan kuuntelemaan TCP-yhteyksiä tietystä portista. Työko- neen ohjausyksiköltä voidaan sitten lähettää TCP-paketti ”REST-palvelimelle” ja sa- maan porttiin, jota ohjausyksikkö kuuntelee. Asetetaan välityspalvelimen ohjausyksikkö kuuntelemaan TCP-yhteyksiä portista 50000 seuraavalla komennolla: nc –l 50000 Työkoneen ohjausyksiköltä lähetetään viesti ”REST-palvelimelle” osoitteeseen x.y.z.a eli oikeasti ohjausyksikölle porttiin 50000 seuraavalla komennolla: echo "yhteyskokeilu" | nc -v –w 5 x.y.z.a 50000 Nyt kun paketti lähetettiin työkoneen ohjausyksiköltä, niin välityspalvelimen ohjausyk- sikön Netcat tulostaa viestin ”yhteyskokeilu” ja työkoneen ohjausyksikön näytölle tu- lostuu seuraavanlainen ilmoitus: Connection to x.y.z.a 50000 port [tcp/*] succeeded! Voidaan siis todeta, että yhteys toimii odotetulla tavalla. Koska työkoneen reitittimen yhteysluettelossa on kaksi profiilia, niin on paikallaan tes- tata vielä yhteysluettelon toiminta kokonaisuudessaan. Toisin sanoen testataan asiakas- reitittimen automaattinen yhdistyminen saatavilla oleviin langattomiin lähiverkkoihin. Tätä voidaan testata siten, että annetaan työkoneen reitittimen yhdistyä näkyvissä ole- 68 vaan lähiverkkoon, jonka jälkeen käynnistetään toinen tukiasema. Tämän jälkeen sam- mutetaan ensimmäinen tukiasema, mikä simuloi kyseisen verkon katoamista. Tällöin reitittimen tulisi yhdistyä automaattisesti jäljellä olevan tukiaseman langattomaan lähi- verkkoon, sillä se on ainut verkko, joka on kuuluvissa sillä hetkellä. Tämän jälkeen teh- dään vielä sama toimenpide vastakkaisessa järjestyksessä, eli käynnistetään sammutettu tukiasema ja sammutetaan se tukiasema, johon reititin on nyt yhdistyneenä. Nyt reititti- men tulisi yhdistyä takaisin alkuperäiseen langattomaan lähiverkkoon, sillä se on nyt ainoa verkko, joka on käytettävissä. Tätä voidaan testata aiemmin käytetyillä tu- kiasemilla eli välityspalvelimen tukiasemalla ja älypuhelimella simuloidulla tehtaan tu- kiasemalla. Käynnistetään tehtaan tukiasema, jolloin huomataan, että työkoneen reititin liittyy tämän tukiaseman verkkoon muutaman sekunnin viiveellä. Sitten laitetaan väli- tyspalvelimen tukiasema päälle ja sammutetaan tehdasverkko. Reititin kadottaa yhtey- den tehdasverkkoon ja siirtyy etsimään verkkoja, jolloin se löytää välityspalvelimen langattoman verkon ja liittyy siihen. Nyt käynnistetään tehdasverkko uudelleen ja sam- mutetaan välityspalvelimen tukiasema. Myös tällä kertaa tapahtuu samoin, eli yhteys katkaistaan ja löydetään uusi verkko, johon liitytään. Voidaan siis todeta, että yhteys- luettelo toimii odotetusti ja työkone voi suunnitelman mukaisesti liittyä sekä välityspal- velimen langattomaan lähiverkkoon että tehtaan langattomaan lähiverkkoon. 6.2 Välityspalvelimelta lähtevä tietoliikenne Välityspalvelimelta yhteydet lähtevät ohjausyksiköltä. Data kulkee aluksi välityspalve- limen langattomalle asiakkaalle, joka on yhdistynyt tukiasemaan. Tukiasemalta on sitten yhteys internetiin ja REST-palvelimelle. Tilanne muistuttaa työkoneen ensimmäistä tes- titapausta, joten myös tässä tapauksessa voidaan käyttää samoja menetelmiä yhteyden testaamiseen. Aluksi testataan kuitenkin yhteysluettelon toiminta. Koska välityspalve- limen langattomana asiakkaana toimiva reititin muodostaa yhteyden tehtaan langatto- maan verkkoon työkoneen reitittimen tavoin, voidaan simulointi tehdä käyttäen samaa tukiasemaa kuin työkoneenkin tapauksessa, sillä tehdasverkko on molemmissa tapauk- sissa täsmälleen sama. Käynnistetään välityspalvelimen asiakasreititin ja tehdasverkon 69 simuloitu tukiasema älypuhelimesta. Langaton asiakas yhdistyy tukiasemaan automaat- tisesti, joten todetaan yhteysluettelon toimivan oikein. Yhteyden toimivuus REST-palvelimelle voidaan testata samalla menetelmällä kuin työ- koneenkin tapauksessa, eli lähetetään POST-pyyntö seuraavalla komennolla: curl -–connect-timeout 5 –s –X POST \ –-data "yhteyskokeilu" x.y.z.a/jsonimport.php REST-palvelin vastaa samanlaisella viestillä kuin työkoneenkin tapauksessa eli seuraa- vanlaisella merkkijonolla: >>>R,ERS,DATANOTVALID<<< Palvelin ei siis edelleenkään huolinut sille tulevaa dataa ja lähetti vastauksena viestin, joka kertoo, että data ei ole oikeassa muodossa. Voimme kuitenkin todeta yhteyden toimivan, sillä saimme palvelimelta vastauksen. 70 7 TULOKSET Tuloksena syntyi toimiva järjestelmä tulevaisuuden ohjelmistoratkaisuja varten. Uuden järjestelmän tärkein ominaisuus on se, että sen avulla on mahdollista siirtää dataa kai- vostyömaan työkoneelta palvelimelle internetiin, vaikka työkoneella itsellään ei ole in- ternet-yhteyttä lainkaan käytettävissä. Tiedon siirron puolestaan mahdollistaa järjestel- mässä toimiva välityspalvelin, joka sisältää elementtejä sekä tehtaan langattomasta lähi- verkosta että työkoneen verkkoarkkitehtuurista. Välityspalvelin uskottelee työkoneille olevansa oikea Exertuksen ReDi-palvelun REST-palvelin internetissä. Tämän ansiosta työkoneilla käytössä olevaan ohjausjärjestelmään ei tarvitse tehdä lainkaan muutoksia tähän liittyen. Eräs järjestelmän vahvuus on sen dynaamisuus. Järjestelmän välityspalvelinta ei ole ni- mittäin pakko käyttää, jos sellaiselle ei ole mitään tarvetta. Jos esimerkiksi kaivokseen on rakennettu oma verkkoinfrastruktuuri, niin ei ole mitään järkeä käyttää välityspalve- linta kaivoksessa. Pahimmassa tapauksessa tämä vain hidastaisi datan siirtoa ja välitys- palvelimeksi valjastettu ajoneuvo olisi vain tiellä. Järjestelmään ei tarvitse tehdä edes muutoksia liittyen välityspalvelimen käyttöön. Samat asetukset käyvät järjestelmään, jossa käytetään välityspalvelinta sekä järjestelmään, jossa ei käytetä välityspalvelinta. Tämä helpottaa myös järjestelmän asentamista ja ylläpitoa. Esimerkiksi jos järjestelmää halutaan kokeilla aluksi ilman välityspalvelinta, voidaan näin helposti tehdä. Järjestel- mällä on siitä huolimatta täysi valmius käyttää välityspalvelinta, jos sellaista myöhem- min tarvitaan. Uusi järjestelmä rakennettiin internetin perustana olevaa TCP/IP-protokollaperhettä käyttäen. Tämän ansiosta järjestelmään voidaan räätälöidä hyvin monenlaisia ohjelmis- toratkaisuja, sillä TCP/IP-protokollaperheen mukaisia tekniikoita on runsaasti saatavilla ja niitä voidaan soveltaa monilla eri tavoilla. Välityspalvelimen ytimenä voidaan katsoa olevan osoitteenmuunnos. Juuri sen avulla välityspalvelin saadaan näyttäytymään työ- koneille oikean palvelimen IP-osoitteella. Tällä tavoin yhteydellisestä TCP:stä tehtiin periaatteessa yhteydetön protokolla, sillä dataa voidaan siirtää TCP-yhteyden avulla työkoneelta oikealle palvelimelle yhteydettömästi tulevien ohjelmistoratkaisujen avulla. 71 Näin TCP:stä saadaan käyttöön sen hyvät puolet, joita ovat esimerkiksi luotettavuus ja valmiiden ohjelmistoratkaisujen määrä. Uudessa järjestelmässä käytettävää osoitteen- muunnosta toivoisi tekniikkana sovellettavan muuhunkin kuin sen alkuperäiseen tarkoi- tukseen eli IPv4-osoitteiden säästämiseen. Tämä liittyy juuri täysimääräiseen osoit- teenmuunnokseen, mutta lähde- ja kohdeosoitteenmuunnoksen käyttöä erikseen voitai- siin tällä hetkellä hyödyntää enemmänkin erilaisissa IPv4-osoitteisiin perustuvissa ver- koissa. Yksi lähitulevaisuuden visio järjestelmän ohjelmistoarkkitehtuuriin liittyen on MQTT- protokollan käyttö järjestelmän tiedonsiirrossa. MQTT on esineiden internetin tiedon- siirtoon sopiva yksinkertainen tuottaja–tilaaja-protokolla. Se sopii hyvin alhaisen kais- tanleveyden- ja korkean viiveen verkkoihin, joissa laitteilla on pienet resurssit. Kuten nykyisessäkin järjestelmässä käytössä oleva JSON-formaatti, myös MQTT-protokolla on muodostumassa de facto -standardiksi IoT-alalla. (Hassan, Khan & Madani 2018: 200.) MQTT-protokollan avulla uuden järjestelmän verkon toimintaa päästään testaa- maan pienellä vaivalla, sillä MQTT toimii TCP/IP-protokollaperheen päällä (Gastón 2017: 9–10). Jos MQTT-protokollan toimivuus järjestelmässä todetaan myöhemmin käyttökelpoiseksi, voidaan sitä soveltaa myös aiemmin mainitun viivesietoisen verkon toteutuksessa, jos sellainen päätetään kehittää. Järjestelmän yksittäisten laitteiden suorituskykyä sivuttiin nopeasti testauksen yhteydes- sä. Käytännössä järjestelmässä käytettävät langattomat reitittimet toimivat hyvin nope- asti. Jos reitittimet ovat päällä, niin ne pystyvät liittymään automaattisesti langattomaan lähiverkkoon noin viidessä sekunnissa siitä kun langaton verkko tulee kuuluviin. Aika ei juuri kasva tilanteessa, jossa reititin kadottaa yhteyden sen hetkiseen langattomaan verkkoon ja liittyy toiseen kuuluvissa olevaan langattomaan verkkoon. Tässä kestää alle kymmenen sekuntia. Jos reititin ei ole päällä, niin käynnistyksestä verkkoon liittymi- seen menee noin puoli minuuttia. 72 7.1 Kehitysideat Vaikka uusi järjestelmä mahdollistaa monenlaisten ohjelmistoratkaisujen käytön jo nyt, niin järjestelmän verkkoarkkitehtuuria voidaan edelleen kehittää. Kuten aiemmin mai- nittiin, voidaan reitittimien yhteysluetteloon lisätä useita profiileja. Jos kaivoksen ja teh- taan alueella on esimerkiksi useita langattomia lähiverkkoja, voidaan näille kaikille teh- dä profiilit yhteysluetteloon, jolloin reitittimet voivat yhdistyä kaikkiin verkkoihin ja internet-yhteyden saatavuus alueena laajenee. Tätä voidaan soveltaa myös tilanteeseen, jossa välityspalvelimia olisi kaksi tai jopa enemmän. Tällainen järjestely voi olla tar- peen, jos kaivostyömaa on todella suuri ja siellä on paljon kaivostyökoneita eri alueilla. Tästä olisi lisäksi se hyöty, että kaikkien työkoneiden data ei olisi yhdessä paikassa ja välityspalvelimessa olevan ohjausyksikön kuormaa saataisiin tasattua. Diplomityön tu- loksena syntynyt järjestelmä suunniteltiin siten, että välityspalvelimia on yksi ja työko- neita monta, mutta teoriassa järjestelmän pitäisi toimia myös monella välityspalvelimel- la pienin muutoksin. Tämä vaatisi uuden välityspalvelinprofiilin yhteysluetteloon. Tä- män perusteella monen välityspalvelimen järjestelmässä kaikilla välityspalvelimilla olisi oma SSID ja oma WPA2-avain. Tätä puolestaan voitaisiin jalostaa edelleen siten, että kaikille välityspalvelimille asetettaisiin sama SSID ja WPA2-avain kuin tehtaan langat- tomalla lähiverkolla. Työkoneen reitittimen yhteysluetteloon tulisi täten vain yksi pro- fiili, joka kattaisi tehtaan langattoman lähiverkon ja välityspalvelimet. Vaikka tehtaalla olisi useita langattomia lähiverkkoja, niin silloinkin edellä mainittua tilannetta voitaisiin käyttää soveltuvilta osin. Yhdellä profiililla työkoneiden reitittimet yhdistyisivät oletet- tavasti aina vahvimman signaalin verkkoon riippumatta siitä, onko verkko välityspalve- limen vai tehtaan. Tämä vaatii kuitenkin lisätutkimuksia varsinkin tietoturvan näkökul- masta. Tästä syystä järjestelmä suunniteltiin siten, että välityspalvelimen tukiasema tar- joaa aivan oman langattoman lähiverkkonsa omalla salausavaimella, jotta se ei vaaranna tehtaan langatonta lähiverkkoa ja sen salausavainta. Tietoturvaan liittyen lisätutkimusta vaativat myös reitittimien palomuuriasetukset. Dip- lomityön toteutusvaiheessa reitittimiin asennettiin yksinkertaiset palomuuriasetukset. Nämä asetukset ovat periaatteeltaan sellaiset, että palomuuri sallii vain sellaiset yhtey- det, jotka on erikseen sallittu palomuurin asetuksissa. Tämä tarjoaa riittävän tietoturvan 73 järjestelmälle, mutta asetukset saattavat olla liian tiukat joihinkin sovelluksiin. Palo- muurin asetukset vaativatkin laajaa tutkimusta, jossa pohditaan tietoturvan ja helppo- käyttöisyyden suhdetta. Palomuuriasetusten perustana on käytetty Discherin (2011: 66– 88) kirjassa esitettyjä suosituksia perustavanlaatuisesta palomuurista. Mikrotikin (2017b) verkkosivuilla olevaa esimerkkiä palomuurin perusasetuksista on myös sovel- lettu tässä tapauksessa. Palomuuriasetuksia kannattaakin lähteä kehittämään näiden poh- jalta ottaen samalla huomioon tulevien ohjelmistoratkaisujen vaatimukset. Tietoturvaan liittyy tietenkin muitakin asioita, kuin pelkkä palomuuri. Palomuureilla estetään pääsy verkosta toiseen verkkoon. Toisin sanoen palomuuri on ulkoisia uhkia varten. Tilanne kuitenkin muuttuu oleellisesti, jos tietomurto tapahtuu paikallisesti. Tästä syystä on ää- rimmäisen tärkeää estää reitittimien luvaton käyttö myös paikallisesti. Tällaisessa tilan- teessa voidaan hyödyntää Mikrotik-reitittimen kirjautumisominaisuutta. Reitittimelle voidaan luoda käyttäjätunnus ja salasana kirjautumista varten. Jos kirjautumistiedot ei- vät ole tiedossa, asetuksia ei pääse muokkaamaan. Oletuksena reitittimissä on käyttäjä admin, jonka salasana on tyhjä. Kun oma käyttäjätunnus on luotu, on oletuskäyttäjä syy- tä poistaa kokonaan. Näitä asetuksia ei käyty läpi toteutusvaiheessa, sillä ne eivät liity tietoliikenteen toimintaan toisin kuin palomuuri. Edellä kuvattu uuden käyttäjän lisäys ja oletuskäyttäjän poisto voidaan tehdä siten, että muutetaan oletuskäyttäjän nimi ja sa- lasana (Mikrotik 2017c). Seuraavanlaisella komennolla muutettaisiin oletuskäyttäjän nimeksi Maintenance ja salasanaksi 1k3e7TQ0r: /user set 0 name=Maintenance /user set 0 password="1k3e7TQ0r" Mikrotikin (2017c) verkkosivuilta löytyy myös muita tietoturvaan liittyviä asetuksia, joiden avulla reitittimestä saadaan turvallisempi. DNS ei ollut vaatimuksena uudessa järjestelmässä, sillä laitteiston näkökulmasta IP- osoitteen käyttäminen on suoraviivaisempaa. DNS kuitenkin toimii työkoneen reititti- messä suoraan tällä hetkellä. Toisin sanoen työkoneen reitittimen voi kytkeä omaan tie- tokoneeseen ja selata sen avulla internetiä normaalisti verkkotunnuksia käyttäen. Tämä johtuu siitä, että työkoneen ohjausyksikkö ja myös edellä mainittu tietokone saavat IP- parametrit reitittimen DHCP-palvelimelta. Välityspalvelimessa DNS ei toimi suoraan, 74 mutta sen saa toimimaan siten, että määrittää nimipalvelimen osoitteen ohjausyksikölle käsin. Tulevaisuudessa ReDi-palvelun REST-palvelimen IP-osoite saattaa muuttua, jos palvelin vaihdetaan toiseen. Jos palvelin ja IP-osoite vaihtuvat useamminkin, niin silloin kannattaa siirtyä käyttämään nimipalvelua koko järjestelmässä. Tällöin osoitteena voi- taisiin käyttää aina samaa verkkotunnusta muuttuvan IP-osoitteen sijaan, mikä helpottaa järjestelmän ylläpitoa. Siinä tilanteessa välityspalvelimelle pitäisi lisätä tuki nimipalve- lulle. Edellisten asioiden lisäksi on aiheellista pohtia välityspalvelimen reititystä. Toteutuk- sessa välityspalvelimen ohjausyksikölle asetettiin kiinteät IP-parametrit kohdeosoit- teenmuunnosta varten ja DHCP-palvelu ei ole käytössä välityspalvelimen langallisessa lähiverkossa. Tämä ratkaisu on hyvä siinä mielessä, että se on yksinkertainen ja aina samanlainen laitteiston vaihtuessakin. Kiinteiden IP-parametrien asettamiseen tarvitaan kuitenkin pääkäyttäjän oikeudet ohjausyksikön Linuxissa, mutta se ei ole suuri ongelma tässä tapauksessa. Tulevaisuuden ohjelmistoratkaisut saattavat nekin vaatia pääkäyttäjän oikeuksia, joten kiinteiden IP-parametrien asettamisesta ei tule ylimääräistä taakkaa. Välityspalvelimen langallisessa lähiverkossa voitaisiin siitä huolimatta käyttää DHCP- palvelua, koska sen avulla esimerkiksi DNS saataisiin toimimaan automaattisesti. Kuten edellä pohdittiin, niin DNS vaatii tällä hetkellä kiinteän määrittelyn välityspalvelimen ohjausyksikölle, jos sitä haluttaisiin käyttää. Välityspalvelimen langattomana asiakkaa- na toimivalla reitittimellä voitaisiin ottaa DHCP-palvelin käyttöön. Tämän johdosta verkkotunnus ja myös muut IP-parametrit saataisiin asetettua automaattisesti ohjausyk- sikölle. Ongelmaksi muodostuu se, että ohjausyksikön IP-osoite täytyy olla aina sama, jotta kohdeosoitteenmuunnos toimii oikein. Tämä voidaan kuitenkin ratkaista monella- kin eri tavalla. Reitittimen DHCP-palvelimelle voidaan esimerkiksi tehdä sellainen ase- tus, joka yhdistää aina saman IP-osoitteen ennalta määriteltyyn MAC-osoitteeseen. Ky- seessä on tällöin käsin määritys, kuten teoreettisessa viitekehyksessä aiemmin mainit- tiin. Tämän MAC-osoitteen omistaja olisi sitten välityspalvelimen ohjausyksikkö. Täl- löin juuri tämä ohjausyksikkö saisi aina saman IP-osoitteen reitittimen DHCP- palvelimelta. Haittapuolena on se, että jos ohjausyksikkö joudutaan vaihtamaan, pitää reitittimen DHCP-asetuksiin määrittää uuden ohjausyksikön MAC-osoite. Parempi rat- 75 kaisu DHCP-palvelun käyttöön olisi sellainen, jossa reitittimen DHCP-palvelin antaa ohjausyksikölle satunnaisen IP-osoitteen, jolloin tuo IP-osoite yhdistettäisiin siis ohja- usyksikön fyysiseen Ethernet-sovittimeen, aivan kuten normaalisti tapahtuukin. Fyysi- sen Ethernet-sovittimen lisäksi Linuxiin voitaisiin luoda virtuaalinen verkkosovitin, jol- le määritetään IP-osoitteeksi se osoite, jonka kohdeosoitteenmuunnos vaatii. Virtuaali- nen verkkosovitin voitaisiin luoda ohjelmallisesti aina ohjausyksikön käynnistyessä. Tämä vaatii kuitenkin jälleen pääkäyttäjän oikeudet, mutta kuten aiemmin todettiin, ei siitä ole erityistä haittaa tässä vaiheessa. Todennäköisesti paras ja ehkä yllättäväkin rat- kaisu DHCP-palvelun käyttöönottamiseksi, olisi määrittää DHCP-palvelimen jaettavien IP-osoitteiden osoiteavaruus yhden osoitteen suuruiseksi. Tällöin DHCP-palvelin antaa aina tuon yhden ja saman IP-osoitteen ohjausyksikölle riippumatta siitä, mikä sen MAC-osoite on. Kaikissa edellä mainituissa tapauksissa, joissa DHCP-palvelua käytettäisiin, on se on- gelma, että reititys välityspalvelimen ohjausyksiköltä tukiaseman tarjoamaan langatto- maan lähiverkkoon ei toimi kohdeosoitteenmuunnoksen tapauksessa, sillä ohjausyksi- kön reititystaulussa ei ole nyt käsin asetettua reittiä tuohon verkkoon. Reititys voidaan kuitenkin kierrättää ohjausyksikön yhdyskäytävän kautta, koska DHCP-palvelua käytet- täessä ohjausyksikkö saa yhdyskäytävän IP-osoitteen DHCP-palvelimelta, joka toimii asiakasreitittimessä. Yhdyskäytävä on siis välityspalvelimen langattomana asiakkaana toimivan reitittimen Ethernet-sovitin. Tällöin yhdyskäytävänä toimivan reitittimen reiti- tystauluun lisätään reitti siihen verkkoon, jossa oltiin ennen kohdeosoitteenmuunnosta. Tämä verkko löytyy siis tukiasemana toimivan reitittimen takaa. Tällä järjestelyllä TCP- paketti pääsee takaisin. Kuvitellaan nyt, että paketti tulee kohdeosoitteenmuunnoksen kautta välityspalvelimen ohjausyksikölle, joka on saanut DHCP-palvelimelta yhdyskäy- täväkseen langattomana asiakkaana toimivan reitittimen Ethernet-sovittimen IP- osoitteen. Tämän reitittimen reititystaulun säännön mukaan sama verkko, jossa paketti oli ennen kohdeosoitteenmuunnosta, löytyy tukiasemana toimivan reitittimen Ethernet- sovittimen IP-osoitteen takaa. Näin reititykseen tulee yksi hyppy lisää, mutta yhteys saadaan toimimaan. Tämän ja viimeiseksi ehdotetun DHCP-asetuksen johdosta välitys- palvelimen ohjausyksikössä voidaan käyttää vakiona olevia verkkoasetuksia, joita myös työkoneen ohjausyksiköllä käytetään. Toisin sanoen ohjausyksikön verkkoasetuksia ei 76 tällöin tarvitse muuttaa lainkaan, jolloin laitteisto- ja verkkoarkkitehtuurin näkökulmas- ta ainoat asennettavat laitteet ovat reitittimet. Reititykseen liittyen välityspalvelimen reititystä voitaisiin kehittää vielä siten, että väli- tyspalvelin toimisi langattoman lähiverkon toistimena. Välityspalvelin toimii toistimena tilanteessa, jossa työkone ei yllä tehtaan langattomaan lähiverkkoon, mutta välityspalve- lin on näiden kahden välissä siten, että välityspalvelin yltää tehtaan langattomaan lähi- verkkoon ja työkone yltää välityspalvelimen tarjoamaan langattomaan lähiverkkoon. Näin työkoneelta voisi olla suora ja reaaliaikainen yhteys välityspalvelimen verkon kautta tehtaan langattomaan lähiverkkoon ja sitä kautta myös REST-palvelimelle. Täl- lainen toiminnallisuus on periaatteessa jo olemassa, mutta se vaatii rinnalleen tiettyjä ohjelmistoratkaisuja. Nämä ratkaisut ovat lähinnä sellaisia, että työkoneelta tullut data tallennetaan välityspalvelimen ohjausyksikölle, josta se sitten luetaan ja lähetetään heti kohti tehtaan langatonta lähiverkkoa. Teoriassa tällainen järjestelmä ei ole reaaliaikai- nen, mutta tietyillä ohjelmistoratkaisuilla viive saadaan käytännössä hyvin pieneksi. Oi- keana langattoman verkon toistimena välityspalvelin osaisi reitittää datapaketin suoraan tehtaan verkkoon, jolloin tallennusvaihe jäisi kokonaan pois. Paitsi että tällainen järjes- tely olisi täysin reaaliaikainen, se vähentäisi ohjausyksikön kuormitusta, koska ideaaliti- lanteessa reitityksen hoitaisivat yksin reitittimet. Koska välityspalvelimen luonteeseen kuuluu sen monipuolinen liikuteltavuus, eikä niinkään paikallaan olo, niin toistinomi- naisuus ei siten ole tarpeellinen vielä tässä vaiheessa. Muutenkin edellä esitetty tilanne, jossa työkone ei yltäisi tehtaan langattomaan verkkoon ja välityspalvelin yltäisi, on har- vinainen. On kuitenkin aiheellista pohtia tällaistakin skenaariota tulevaisuuden varalle. Yhteenvetona kehitysideoista voidaan todeta, että tuloksena syntyneen järjestelmän ase- tukset eivät tällä hetkellä häviä lainkaan esitetyille kehitysideoille, sillä kyse on lähinnä yksityiskohdista ja tulevaisuuden mahdollisuuksista. Juuri tulevaisuuden ratkaisuja sil- mällä pitäen, on hyvä pohtia erilaisia tekniikoita. Edellä esitetyt tulevaisuuden ideat ei- vät muutenkaan toimi sellaisenaan, vaan ne vaativat sekä teoreettisia että käytännönlä- heisiä lisätutkimuksia, jotta niitä voidaan alkaa soveltaa. 77 8 JOHTOPÄÄTÖKSET Diplomityön tuloksena syntynyt järjestelmä on hyvä pohja tulevaisuuden innovatiivisil- le ohjelmistoratkaisuille, joita voidaan helposti kehittää järjestelmän TCP/IP- pohjaisuutta hyödyntäen. Tulevaisuudessa järjestelmästä voidaan tehdä esimerkiksi ai- emmin mainitun viivesietoisen verkon kaltainen. Se voidaan aluksi räätälöidä tietyn ti- lanteen vaatimusten mukaisesti tai siitä voidaan tehdä jopa kokonaan yleiskäyttöinen. Kokonaan yleiskäyttöinen järjestelmä vaatii kuitenkin paljon kehitystyötä ja siksi alussa onkin tärkeää testata järjestelmää yksinkertaisemmilla tekniikoilla, kuten esimerkiksi MQTT-protokollalla. Tämä jo senkin takia, että järjestelmän toimintaa saadaan testattua kattavammin diplomityössä käydyn suppean testauksen lisäksi. Yksinkertaiset ja hel- posti toteutettavat tekniikat ohjelmistokehityksen alkuvaiheessa nopeuttavat myös jär- jestelmän käyttöönottoa sen luonnollisessa käyttöympäristössä. Testaus olisikin hyvä saada laajennettua toimiston ulkopuolelle, sillä kirjoituspöydän ääressä tehdyt testit ei- vät aina vastaa tilannetta kentällä. Laitteisto- ja verkkoarkkitehtuurin näkökulmasta uutta järjestelmää voitaisiin hyvin käyttää muissakin käyttökohteissa kuin kaivosteollisuudessa, joka itsessään on hyvin vaativa kohde. Muita käyttökohteita voisivat olla oikeastaan mitkä tahansa kohteet, jois- sa internet-yhteyttä ei ole saatavilla, mutta dataa haluttaisiin siitä huolimatta siirtää in- ternetin välityksellä. Vasta tulevaisuudessa nähdään millaiseksi MQTT-protokollan, viivesietoisen verkon ja mahdollisesti muiden protokollien ja tekniikoiden kombinaa- tioksi tämän diplomityön tuloksena syntynyt järjestelmä kehittyy ja missä kaikkialla sitä tullaan käyttämään. 78 LÄHDELUETTELO Anttila, Aki (2001). TCP/IP-tekniikka. 2. painos. Helsinki: Helsinki Media. 471 s. ISBN 951-832-061-6. Ballew, Scott M. (1998). IP-verkkojen hallinta Ciscon reitittimillä. 1. painos. Espoo: Suomen Atk-kustannus oy. 343 s. ISBN 951-762-644-4. Burgess, Dennis (2011). Learn RouterOS. 2. painos. Lulu Press. 448 s. ISBN 978-1- 105-06959-8. Discher, Stephen (2011). RouterOS by Example. 1. painos. ISP Services. 300 s. ISBN 978-0-615-54704-6. Dunkels, Adam, Juan Alonso, Thiemo Voigt, Hartmut Ritter & Jochen Schiller (2004). Connecting Wireless Sensornets with TCP/IP Networks. Teoksessa: Wired/Wireless Internet Communications, 143–152. Toim. Langendoerfer, Peter, Mingyan Liu, Ib- rahim Matta & Vassilis Tsaoussidis. Berliini: Springer-Verlag. International Con- ference on Wired/Wireless Internet Communications, WWIC 2004, Frankfurt/Oder, Saksa, 4.–6.2.2004. ISBN 978-3-540-24643-5. Exertus oy (2009). Norsmart Architecture. PowerPoint-esitys alkuperäisen Norsmart- ohjausjärjestelmän arkkitehtuurista. Exertus oy (2013). Norsmart 3. PowerPoint-esitys uudesta Norsmart 3 -ohjausjärjestel- mästä. Exertus oy (2016). ReDiService Overview [verkkodokumentti]. [Viitattu 4.3.2018]. Tie- toa Exertuksen ReDi-palvelusta. Saatavissa: http://www.exertus.fi/files/Tiedostot /TechDoc_ReDiService.pdf 79 Exertus oy (2017a). MIC1100S Technical Data Sheet [verkkodokumentti]. [Viitattu 4.3.2018]. Tietoa Exertuksen MIC1100S-ohjausyksiköstä. Saatavissa: http://www.exertus.fi/files/Tiedostot/TechDoc_MIC1100S.pdf Exertus oy (2017b). RD121S2 Technical Data Sheet [verkkodokumentti]. [Viitattu 4.3.2018]. Tietoa Exertuksen RD121S2-näytöstä. Saatavissa: http://www.exertus.fi /files/Tiedostot/TechDoc_RD121S2.pdf Exertus oy (2017c). RD084S2 Technical Data Sheet [verkkodokumentti]. [Viitattu 4.3.2018]. Tietoa Exertuksen RD084S2-näytöstä. Saatavissa: http://www.exertus.fi /files/Tiedostot/TechDoc_RD084S2.pdf Exertus oy (2018). Yritys | Exertus [verkkodokumentti]. [Viitattu 4.3.2018]. Tietoa yri- tyksestä. Saatavissa: http://www.exertus.fi/?lang=fi&id=127&page=Yritys Fall, Kevin (2003). A Delay-Tolerant Network Architecture for Challenged Internets. Teoksessa: SIGCOMM '03: Proceedings of the 2003 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, 27–34. Toim. Feldmann, Anja, Martina Zitterbart, Jon Crowcroft & David Wetherall. New York: ACM. SIGCOMM Conference 2003, Karlsruhe, Saksa, 25.–29.8.2003. ISBN 1-58113-735-4. Gastón, Hillar C. (2017). MQTT Essentials - A Lightweight IoT Protocol. 1. painos. Packt Publishing. 280 s. ISBN 978-1-78728-781-5. Gheorghe, Lucian (2006). Designing and Implementing Linux Firewalls with QoS using netfilter, iproute2, NAT, and L7-filter. 1. painos. Packt Publishing. 278 s. ISBN 1- 904811-65-5. Granlund, Kaj (2007). Tietoliikenne. 1. painos. Jyväskylä: Docendo oy. 487 s. ISBN 978-951-0-32821-7. 80 Hakala, Mika & Mika Vainio (2005). Tietoverkon rakentaminen. 1. painos. Jyväskylä: Docendo oy. 428 s. ISBN 951-846-263-1. Hassan, Qusay F., Atta ur Rehman Khan & Sajjad A. Madani (2018). Internet of Things. Challenges, Advances, and Applications. 1. painos. CRC Press. 436 s. ISBN 978-1-4987-7851-0. Internet Assigned Numbers Authority (2017). IANA IPv4 Special-Purpose Address Registry [verkkodokumentti]. [Viitattu 27.3.2018]. Saatavissa: https://www.iana.org /assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml Järvinen, Petteri (2003). IT-tietosanakirja. 1. painos. Jyväskylä: Docendo oy. 844 s. ISBN 951-846-184-8. Kaario, Kimmo (2002). TCP/IP-verkot. 1. painos. Jyväskylä: Docendo oy. 396 s. ISBN 951-846-107-4. Korotkevitch, Dmitri (2016). Pro SQL Server Internals. 2. painos. Apress. 830 s. ISBN 978-1-4842-1963-8. LaCroix, Jay (2015). Mastering Linux Network Administration. 1. painos. Packt Pub- lishing. 260 s. ISBN 978-1-78439-959-7. Maniktala, Sanjaya (2013). Power over Ethernet Interoperability. 1. painos. McGraw- Hill. 480 s. ISBN 978-0-07-179826-6. Massé, Mark (2011). REST API Design Rulebook. 1. painos. O’Reilly Media. 116 s. ISBN 978-1-449-31050-9. Mikrotik (2007). Telnet Server and Client [verkkodokumentti]. [Viitattu 17.3.2018]. Tietoa Telnet-ohjelman käytöstä Mikrotik-reitittimessä. Saatavissa: https://mikrotik.com/testdocs/ros/3.0/admin/telnet.pdf 81 Mikrotik (2012). Manual:Webfig [verkkodokumentti]. [Viitattu 17.3.2018]. Tietoa se- lainpohjaisesta Webfig-ohjelmasta ja sen käytöstä. Saatavissa: https://wiki.mikrotik.com/wiki/Manual:Webfig Mikrotik (2017a). Metal [verkkodokumentti]. [Viitattu 17.3.2018]. Yleistä tietoa Mikro- tik Metal-reitittimestä. Saatavissa: https://i.mt.lv/routerboard/files /metal2-171002090102.pdf Mikrotik (2017b). Tips and Tricks for Beginners and Experienced Users of RouterOS: Basic router protection based on connection state and IP address type by using Firewall [verkkodokumentti]. [Viitattu 25.3.2018]. Saatavissa: https://wiki.mikrotik.com/wiki/Tips_and_Tricks_for_Beginners_and_Experienced_ Users_of_RouterOS#Basic_router_protection_based_on_connection_state_and_IP_ address_type_by_using_Firewall Mikrotik (2017c). Manual:Securing Your Router [verkkodokumentti]. [Viitattu 19.4.2018]. Ohjeita Mikrotik-reitittimen tietoturvan kehittämiseen. Saatavissa: https://wiki.mikrotik.com/wiki/Manual:Securing_Your_Router Mikrotik (2018). Manual:Winbox [verkkodokumentti]. [Viitattu 17.3.2018]. Tietoa Winbox-ohjelmasta ja sen käytöstä. Saatavissa: https://wiki.mikrotik.com /wiki/Manual:Winbox Syrjänen, Seppo (2007). Viivesietoisten verkkojen nykytila ja tulevaisuuden haasteet. Helsingin yliopisto. Tietojenkäsittelytieteen laitos. Pro Gradu -tutkielma. Ulz, Thomas, Thomas Pieber, Christian Steger, Sarah Haas & Rainer Matischek (2017). Sneakernet on Wheels: Trustworthy NFC-based Robot to Machine Communication. Teoksessa: 2017 IEEE International Conference on RFID Technology Application (RFID-TA), 260–265. IEEE. International Conference on RFID Technology and Applications, RFID-TA 2017, Varsova, Puola, 20.–22.9.2017. ISBN: 978-1-5386- 1833-2. 82 Viestintävirasto (2018). Määräys luvasta vapaiden radiolähettimien yhteistaajuuksista ja käytöstä [verkkodokumentti]. [Viitattu 18.3.2018]. Saatavissa: https://www.viestintavirasto.fi/attachments/maaraykset/Maarays_15AM.pdf Williams, Edmund A., Graham A. Jones, David H. Layer & Thomas G. Osenkowsky (2007). National Association of Broadcasters Engineering Handbook. 10. painos. Focal Press. 2120 s. ISBN 978-0-240-80751-5. Yellavula, Naren (2017). Building RESTful Web Services with Go. 1. painos. Packt Pub- lishing. 316 s. ISBN 978-1-78829-428-7.