Sovelluskerroksen protokollavaihtoehtoja M2M- ja & IoT-käyttöön

Esineiden internetin (Internet of Things, IoT) ja Teollisuus 4.0:n käyttö lisää laitteiden välistä teollisuusprotokollien avulla tapahtuvaa viestintää. Myös koneiden välisen viestinnän (M2M) standardiratkaisut perustuvat näihin protokolliin. Asioita mutkistaa se, ettei IoT-protokollissa kuvailla mitään tiettyä sovelluskerroksen protokollaa, vaan käytössä on useita standardeja. Alkuvaiheen IoT-toteutuksissa käytettiin tavallisia internetprotokollia, mutta nykyään on saatavana myös erityisesti IoT-käyttöön suunniteltuja protokollia.

Viestintärakenteiden mallintaminen ja oikean protokollan tunnistaminen tiettyyn sovellukseen saattaa olla hankalaa. Tässä artikkelissa kuvaillaan eri protokollia sekä niiden tarjoamia vaihtoehtoja, jotta suunnittelijat pystyvät valitsemaan sopivimman vaihtoehdon integrointia varten.

Kuva 1: Teollisuusautomaation IIoT-toiminnot perustuvat yhä enemmän toisiinsa kytkettyihin laitteisiin, joissa yhteydet muodostetaan teollisuuden verkkoprotokollien avulla. Näiden verkkojen abstraktit kerrokset eivät edellytä kunkin alapuolisen kerroksen toimintojen tuntemusta, minkä vuoksi suunnittelussa keskitytään nykyään pitkälti koneverkon ylimpään kerrokseen (sovelluskerrokseen). (Kuvan lähde: Getty Images)

Sovelluskerroksen protokollan määrittely teollisiin verkkoihin

Digitaalisten M2M- ja IoT-järjestelmien viestintäprotokollat jakautuvat käsitteellisesti abstrakteihin kerroksiin, joita on useimmiten kolme, neljä, viisi tai seitsemän. Näissä käsitteellisissä viitekehyksissä oletetaan, että jokainen kerros oikeastaan ”piilottaa” tietyn laite- tai ohjelmistokerroksen yksityiskohtaisen toiminnan muilta laitteilta tai algoritmeilta, joiden kanssa se viestii. Kerrokset nimittäin määritellään sisältämään täsmälleen vain ne tiedot, joita kyseisessä tietojenvaihdossa tarvitaan.

Kuva 2: Perinteiset järjestelmäarkkitehtuurit ovat rakenteeltaan hierarkkisia, mutta pilvi- ja sumulaskenta ovat hämärtäneet komponenttien toimintojen välisiä rajaviivoja, mikä on edistänyt uusien verkkoprotokollamallien käyttöä. (Kuvan lähde: motioncontroltips.com)

Kaikki mallit sisältävät sovelluskerroksen, joka toimii verkossa keskenään viestivien laitteiden ylimpänä abstraktiokerroksena. Sovelluskerrosta voidaan pitää Open Systems Interconnection (OSI) ‑mallin käsitteenä, minkä Kansainvälinen standardisointijärjestö (ISO) määritteli verkkoviestintään ensimmäisen kerran lähes kolme vuosikymmentä sitten. Tämä klassinen seitsenkerroksinen malli on turhankin monimutkainen joidenkin nykyisten protokollien kuvailuun, mutta se auttaa kuitenkin hahmottamaan järjestelmien välisiä datavirtoja:

Protokollan fyysinen kerros huolehtii raakadatan (digitaalisten bittien) siirrosta sähköisinä, radio- tai optisina signaaleina. Tämä kerros määrittää datan siirtämiseen käytettävien fyysisten komponenttien jalkajärjestyksen, jännitetasot, datanopeudet ja johtojen impedanssit. Esimerkiksi Ethernet on yleinen fyysisen kerroksen protokolla. Lue lisää Digi-Keyn artikkelista EtherNet/IP versus PROFINET.

Datalinkkikerros yhdistää verkon solmut toisiinsa, jolloin laitteet pystyvät muodostamaan yhteyksiä ja korjaamaan fyysisen kerroksen virheitä. IEEE 802 ‑standardi jakoi datalinkkikerroksen edelleen MAC-kerrokseen (Medium Access Control) (jota käytetään laitteiden välisten yhteyksien muodostamisen) ja LLC-kerrokseen (Logical Link Control), jolla tunnistetaan seuraava käytettävä kerros (verkkokerros), tarkistetaan virheitä ja huolehditaan synkronoinnista. Lue lisää datalinkkikerroksen toiminnoista Digi-Keyn artikkelista Implementing Industrial Ethernet with 32-bit MCUs. Verkkokerros puolestaan sallii datapakettien lähettämisen edelleen verkko-osoitteisiin. Internetprotokollissa viitataan TCP-protokollasta ja IP-protokollasta koostuvaan malliin (TCP/IP) (jota käsitellään tämän artikkelin seuraavassa kohdassa): datalinkkikerroksen ja verkkokerroksen välissä on internetverkkokerros. Internetkerrosta pidetään itse asiassa usein verkkokerroksen osana.

OSI-mallin kolmesta seuraavasta kerroksesta ensimmäinen on kuljetuskerros, joka varmistaa tiedonsiirron luotettavuuden ja turvallisuuden datasekvenssien siirron aikana. Sen jälkeen tuleva istuntokerros määrittää, milloin laitteet muodostavat yhteyden toisiinsa sekä milloin yhteys on yksisuuntainen (simpleksi) ja milloin kaksisuuntainen (dupleksi). Lopuksi esityskerros muuntaa datan siten, että eri syntakseja käyttävät laitteet voivat viestiä keskenään.

Tässä artikkelissa keskitytään sovelluskerrokseen, korkeimpaan abstraktiotasoon eli tasoon, jonka kanssa käyttäjät ja järjestelmäohjelmisto ovat vuorovaikutuksessa.

Kuva 3: Moderneja verkkoprotokollia (ja sovelluskerrosta) havainnollistetaan usein teollisten (ja kaupallisten) verkkojen klassisen OSI-mallin avulla. Sen sijaan kolmikerroksissa IoT-arkkitehtuurimalleissa sovelluskerros asetetaan havainto- ja verkkokerrosten yläpuolelle; nelikerroksissa malleissa se sijoittuu datan käsittely-, verkko- ja tunnistuskerrosten yläpuolella. Viisikerrokset IoT-protokollamallit ovat muuten samanlaisia, mutta niissä on lisäksi prosessointi- ja yrityskerrokset. (Kuvalähde: Design World)

Teollisuusautomaation internetprotokollat

Internetprotokollat ovat tiedonsiirtojärjestelmiä, jotka ovat saaneet nimensä tavasta, jolla ne välittävät dataa verkkojen välillä (yleensä vastavuoroisesti). Niiden toimintoja kuvaillaan usein edellä mainitun nelikerroksisen TCP/IP-mallin avulla. Sen fyysinen verkko eli linkkikerros vastaa OSI-mallin fyysistä kerrosta. TCP/IP-protokollan internetkerros (joka on tavallaan OSI-mallin datalinkki- ja verkkokerrostoimintojen yhdistelmä) huolehtii puolestaan yhteyksistä ja datapaketeista. IPv6:ssa tämä kerros tunnistaa verkon isäntäkoneet 128-bittisten IP-osoitteiden perusteella. Verkkoon voidaan määrittää peräti yli 10³⁸ eri isäntää.

TCP/IP-protokollan kuljetuskerros koostuu yleensä joko TCP-protokollasta tai UDP-protokollasta. TCP:tä käytetään yleensä vuorovaikutukseen ihmisen kanssa, esimerkiksi sähköpostissa ja verkon selailussa. Se hoitaa loogiset yhteydet, lähetettyjen pakettien kuittaukset, hävinneiden pakettien uudelleenlähetyksen sekä virtauksen hallinnan. Sulautetuissa järjestelmissä käytetään sen sijaan UDP-protokollaa, joka kuormittaa järjestelmää vähemmän ja toimii reaaliaikaisemmin. UDP-protokollaa käytetään verkkotunnuspalvelimien (DNS) ja DHCP-protokollan kanssa sekä uusissa IoT-sovelluksissa.

Verkkojen TCP/IP-mallin ylimmän kerroksen muodostaa sovelluskerros. Sen toiminnot vastaavat esimerkiksi OSI-mallin istunto- ja esityskerrosten toimintoja.

Geneeriset TCP/IP-sovelluskerroksen protokollat

Eri sovelluskerrosprotokollilla on erilaiset datakaistanleveydet, reaaliaikaisuusominaisuudet ja laitteistovaatimukset. Näiden tekijöiden lisäksi tärkeisiin valintakriteereihin kuuluu myös se, onko jokin protokolla valmiiksi tuttu laitokselle tai OEM-tiimille. Vaikka HTTP- ja SMTP-protokollien kaltaisia internetin alkuvaiheen protokollia käytetään laajalti ihmisen käynnistämään ja kuluttamaan viestintään, IIoT-suuntautuneet TCP/IP-protokollat keskittyvät enemmän koneiden väliseen viestintään (M2M) ja muuhun teolliseen viestintään.

Asioita mutkistaa jonkin verran se, että monia vakiintuneita sovelluskerrosprotokollia, joita käytetään verkkopohjaiseen ihmisvuorovaikutukseen informaation kanssa TCP/IP-protokollassa, käytetään myös kuluttajien ja teollisuuden IoT-sovelluksissa. Tämä pätee etenkin HTTP- ja SMTP-protokolliin, mutta myös SSH- ja FTP-protokolliin. IoT-toimintoja voidaan usein toteuttaa web-teknologioilla käyttämällä XML- ja JSON-kieliä. Yksi haittapuoli on se, että HTTP:n käyttöön liittyy turvallisuusongelmia. Sen vuoksi on parasta, että tällaisissa järjestelmissä käytettävissä IoT-laitteissa on vain asiakaskone, ei palvelinta. Laite ei silloin pysty ottamaan vastaan verkkopyyntöjä, jotka saattaisivat sallia luvattoman pääsyn verkkoon ulkopuolelta. Kaksisuuntainen viestintä HTTP:n kautta voidaan tässä tapauksessa hoitaa WebSocket-protokollalla. XMPP sopii muuten paremmin asennuskohteisiin, joissa suuri laitemäärä tarvitsee suojattua ja reaaliaikaista viestintää.

Jos IoT-hankkeiden johtajilla on IT-alan tausta, he saattavat suosia näitä ihmisten lukemasta verkosta tuttuja standardeja. Uudemmat IIoT-protokollat saattavat kuitenkin joissakin tilanteissa sopia paremmin M2M- ja muuhun teolliseen viestintään.

MQTT vertikaalisien yhteyksien siirtofunktioihin

MQTT on IIoT:ssa nopeimmin yleistyvä kevyt protokolla. Se on alun perin tarkoitettu IoT-laitteisiin, joissa on muistia vain rajallisesti. IBM kehitti tämän vain vähän prosessitehoa ja erittäin vähän kaistanleveyttä käyttävän protokollan öljyputkien anturien yhdistämiseen. Toisin kuin CoAP-protokolla, MQTT on jo standardoitu ISO/IEC 20922 ‑standardissa. MQTT käyttää hieman enemmän resursseja vaativaa TCP-kuljetuskerrosta ja kuluttaa sen vuoksi enemmän tehoa, mutta toisaalta viestien koko saattaa olla vain kaksi tavua eli vieläkin vähemmän kuin CoAP-protokollassa.

MQTT:n toteuttaminen voi myös olla erittäin helppoa, koska protokolla on avoin. Amazon Web Services AWS:n IoT käyttääkin MQTT:tä viestien kuljetukseen ja tukee (tietyin haittapuolin) MQTT:tä v3.1.1-spesifikaation mukaisesti.

MQTT:ssä onkin eräitä rajoituksia, jotka saattavat johtua siitä, että se on kehitetty alun perin telemetriaprotokollaksi, toisin kuin hieman myöhemmin käsiteltävä, erityisesti IoT-käyttöön kehitetty LwM2M. Standardi ei sisällä objektien, yhteyden muodostamisen valvonnan ja laitteen etätoimintojen kaltaisia ominaisuuksia, joten niiden toteutukset ovat yleensä toimittajakohtaisia, mikä heikentää hieman standardoidun protokollan arvoa. MQTT ei myöskään tarjoa virheenkäsittelytoimintoja. Ja vaikka MQTT:stä saadaan turvallinen täydellisen TLS-protokollan avulla, se lisää kuormitusta.

Etenkin yritystasolla: AMQP

AMQP-protokolla on avoin standardi, jolla on joitakin yhteisiä piirteitä MQTT:n kanssa. Sen edistyneisiin ominaisuuksiin kuuluu muun muassa sanomajono. AMQP aiheuttaa kuitenkin MQTT:tä enemmän kuormitusta, minkä vuoksi se sopii huonosti laitteisiin, joissa on vain hyvin rajallisesti kapasiteettia. Sitä käytetäänkin tehokkaassa yritysviestinnässä enemmän kuin teollisuuden IoT-sovelluksissa.

CoAP yhdistää yksinkertaiset laitteet

Laitteet voivat viestiä pienitehoisissa verkoissa ja käyttää siihen erittäin vähän muistia ja prosessointitehoa, kun protokollana käytetään Internet Engineering Task Forcen (IETF) kehittämää CoAP-protokollaa. Sen aiheuttama kuormitus on erittäin pieni, ja pyyntöjen ja vastausten koko saattaa olla vain neljä tavua. CoAP-protokolla käyttää monimutkaisen kuljetuspinon sijaan UDP-protokollaa. Lue UDP:stä lisää Digi-Keyn artikkelista ”EtherNet/IP versus PROFINET” (ks. aiemmin annettu linkki). CoAP käyttää HTTP:n tapaan REST-mallia, jossa palvelimet tarjoavat resurssit URL-osoitteen perusteella ja asiakaskoneet käyttävät niitä POST-, GET-, DELETE- ja PUT-metodeilla. CoAP voidaan myös helposti kääntää HTTP-protokollaksi muiden web-toimintojen integrointia sekä XML- ja JSON-kielten käyttöä varten. Suunnittelijat huomaavat luultavasti, että IoT-laitteiden yhdistäminen CoAP-protokollalla muistuttaa huomattavasti laitteiden yhdistämistä Web API ‑rajapinnan kautta.

Kuva 4: Nordicin SiP on vähävirtainen mikroprosessori, jossa on integroitu LTE-M ja kapeakaistainen (NB)-IoT-modeemi sekä GPS. CoAP voidaan määrittää ohjelmistokehityssarjan avulla. (Kuvan lähde: Nordic Semiconductor)

Paristo- tai akkukäyttöisten laitteiden yhdistäminen LwM2M-protokollalla

Open Mobile Alliancen kehittämä LwM2M-sovelluskerrosprotokolla on kehitetty erityisesti IoT-sovelluksia varten. Sitä käytetään älykaupunkisovelluksissa, konttien ja rahdin seurannassa, automaattisissa maatalouskoneissa ja käyttöhyödykkeiden valvonnassa. LwM2M perustuu CoAP-protokollaan ja tarjoaa käyttöön monia samoja ominaisuuksia. Standardi sisältää laajan valikoiman selvästi määriteltyjä ja ylläpidettäviä standardiobjekteja sekä yhteyden tarkkailuun ja etälaitteisiin liittyviä toimintoja. Myös automaattiset laiteohjelmistopäivitykset helpottavat LwM2M-protokollalla yhdistettyjen laitteiden hallintaa. Vaikka JSON:n kaltaisten moduulien lisääminen kasvattaa protokollan järjestelmään aiheuttamaa kuormitusta, se myös helpottaa suunnittelijoiden työtä. LwM2M on suunniteltu erityisesti IoT-sovelluksiin, joten se pystyy hyödyntämään myös vahvaa DTLS-suojausprotokollaa kuormituksen lisääntymättä.

DDS reaaliaikaisiin hajautettuihin sovelluksiin

DDS-protokolla on hieman erilainen vaihtoehto, joka luokitellaankin sovelluskerrosprotokollan sijaan usein M2M-väliohjelmistoksi. Se tarjoaa turvalliset ja suorituskykyiset yhteydet esimerkiksi autonomisiin ajoneuvoihin, sähköntuotantoon ja lennonvalvontajärjestelmiin. DDS tukee sulautettujen järjestelmien yhdistämistä hajautettuun valvontaan, jolloin yhdyskäytäviin ei jouduta tukeutumaan liiallisesti. DDS hoitaa myös sanomien reitityksen ja toimituksen ilman sovellusten toimenpiteitä. DDS:n palveluparametrien laatu on konfiguroitavissa, joten verkkotoiminnot voidaan optimoida järjestelmän rajoitusten mukaisesti.

Kuva 5: Autonomisiin ajoneuvoihin tarkoitettu Connext Drive ‑protokolla perustuu DDS-väliohjelmistoon, joka toimii osaltaan AUTomotive Open System ARchitecture (AUTOSAR) Adaptive- ja ROS2-ohjelmistoarkkitehtuurien perustana. Tämä on vain yksi esimerkki siitä, miten DDS tukee IoT-ohjelmistointegraatiota. (Kuvan lähde: Real-Time Innovations)

Yhteenveto: IIoT-sovelluskerrosprotokollat

Kaikilla protokollilla on omat vahvuutensa ja heikkoutensa. IoT-sovelluksiin sopivat kuitenkin parhaiten avoimen lähdekoodin vaihtoehdot, jotka voidaan ottaa käyttöön nopeasti ja turvallisesti (ja joiden aiheuttama kuormitus on mielellään pieni). Sulautettujen järjestelmien ja järjestelmäpiirilaitteiden (SoC) jatkuvasti kasvava laskentakapasiteetti kannustaa IIoT:n toteuttamista ja laajentaa entisestään eri protokollien sovelluskerrosten tarjoamia mahdollisuuksia.