Nopeuta teollisten IoT-sovellusten kehitystä – Osa 1: IoT-laitetietojen simulointi

Toimittajan huomautus: Sulautetut sovelluskehitysprojektit viivästyvät usein, kun kehittäjät odottavat uusien laitteistototeutusten valmistumista. Teollisen esineiden internetin (IIoT) sovelluskehityksessä esiintyy samanlaisia pullonkauloja, kun odotetaan anturidataa koneoppimismenetelmiin perustuvien teollisten ennakkohuoltojärjestelmien tai laitosautomaatiojärjestelmien tueksi. Tässä kaksiosaisessa sarjassa tutkitaan vaihtoehtoja IIoT-sovelluskehityksen nopeuttamiseen tarvittavien datavirtojen tuottamiseksi. Osassa 1 kuvataan simulointimenetelmien käyttöä näiden datavirtojen synnyttämiseen. Osassa 2 kerrotaan vaihtoehdoista, joilla tietoa voidaan generoida luomalla anturijärjestelmistä nopeita prototyyppejä.

Laajoissa teollisissa esineiden internetin (IIoT) sovelluksissa on useita haasteita, jotka voivat pysäyttää käyttöönottohankkeita ja saada yritykset miettimään, tarjoavatko toteutukseen vaaditut resurssit tuottoa sijoitukselle. Jotta tällaiset tilanteet vältetään ja voidaan auttaa kehittäjiä tunnistamaan IIoT-käyttöönoton hyödyt nopeammin, tarvitaan pääsy käyttöönottosimuloinnissa käytettävään dataan.

Kun kehittäjät käyttävät simulointimenetelmiä realististen datavirtojen luomiseen, IIoT-sovellusten kehitys voidaan aloittaa jo kauan ennen IoT-verkon käyttöönottoa ja jopa itse IIoT-anturiverkon määrityksiä voidaan hienosäätää.

Tässä artikkelissa esitetään, miten erilaiset IoT-pilvialustat mahdollistavat datan simuloinnin, ja siinä käytetään esimerkkinä Multi-Tech Systems Inc:n yhdyskäytäviä, joilla käyttöönottoa voi nopeuttaa entisestään.

Miksi IIoT-dataa kannattaa simuloida

Simuloidun tiedon käyttämisessä sovellusten tai järjestelmien kehitykseen ei tietenkään ole mitään uutta. Kehittäjät ovat vuosikymmenien ajan käyttäneet järjestelmätason simulaatiomenetelmiä ajaakseen stressitestejä laskentainfrastruktuureille ja liitettävyyspalveluille. Nämä testit ovat tärkeässä osassa varmistettaessa staattisten kokoonpanojen kestävyyttä. Pilvipalvelualustoilla testit tarjoavat suhteellisen helpon tavan varmistaa virtuaalikoneiden ja muiden pilviresurssien automaattinen skaalautuminen.

IIoT-sovelluksia koskevat nämä samat vaatimukset. Näiden lisäksi IIoT-sovelluksilla on omia lisävaatimuksiaan. Paitsi, että datan simulointi auttaa kuormitustestauksessa ja automaattisessa skaalauksessa, se tarjoaa myös tärkeän työkalun haluttaessa vahvistaa, että yritystason IIoT-sovelluksen kaltaisen monimutkaisen ohjelmiston vaatimien eri palveluiden ja resurssien integrointi toimii. Näiden peruskäyttötarkoitusten lisäksi datan simuloinnilla voidaan nopeuttaa johtavien pilvipalvelujen tuottajien hienostuneille palvelualustoille rakennettavien monimutkaisten IIoT-sovellusten kehitystä.

Ohjelmistonäkökulma

IIoT-sovellukset toimivat monimutkaisissa arkkitehtuureissa, jotka näyttävät hyvin erilaisilta sovellusohjelmiston kehittäjille kuin anturi- ja toimilaitejärjestelmän kehittäjille. Jälkimmäisten näkökulmasta IIoT-arkkitehtuuri on valtava määrä antureita ja toimilaitteita, jotka toimivat yhdessä sovelluksen ohjaamien fyysisten prosessien kanssa. Sovellusohjelmiston kehittäjille yritystason IIoT-arkkitehtuuri koostuu useista palveluista, joiden koordinoitu toiminta tuottaa lopulta sovelluksen toiminnallisuuden.

Microsoft Azuren IoT-referenssiarkkitehtuuri tarjoaa edustavan esimerkin tyypillisistä IIoT-sovelluksista (ja yleisemminkin IoT-sovelluksista) sovellusohjelmiston näkökulmasta. Tässä näkymässä tiivistyvät ne erilaiset toiminnalliset palvelut, jotka tyypillinen sovellus yhdistää pilvessä tuottaakseen lisätietoa ja toimenpiteitä päätepisteestä ja verkon reunoilla sijaitsevilta laitteilta saadun datan perusteella (kuva 1).

Kuva 1: Microsoft Azuren IoT-referenssiarkkitehtuurissa näkyvät monet eri pilvipalvelut ja resurssit, joita IIoT-sovellus tyypillisesti tarvitsee tuottaakseen hyödyllistä lisätietoa ja toimenpiteitä laiteverkkojen tuottaman datan perusteella. (Kuvan lähde: Microsoft Corp.)

Yksittäiset sovellusratkaisut käyttävät näitä pilviresursseja sopivina kombinaatioina. Ne yhdistetään toiminnallisesti standardoitujen tiedonsiirtomekanismien kautta ja niitä ohjaa sovelluslogiikka. Amazon Web Services (AWS) esittelee verkkoon yhdistetyn ajoneuvon ratkaisussaan, miten pilvipalveluita voidaan yhdistellä moduuleista, jotka tarjoavat sovellukselle erilaisia ominaisuuksia ja kykyjä (kuva 2).

Kuva 2: AWS:n verkkoon yhdistetyn ajoneuvon ratkaisu on edustava esimerkki siitä, miten tyypillinen suuren mittakaavan IoT-sovellus yhdistää pilvipalveluita tarvittavien kykyjen saamiseksi. (Kuvan lähde: Amazon Web Services)

Kuten näistä arkkitehtuuriesityksistä käy ilmi, IIoT-sovelluksen luontiin liittyvä ohjelmistokehitys on aivan yhtä haastavaa ja kattavaa kuin anturi- ja toimilaiteverkkojen toteuttaminen. Organisaatioilla ei useinkaan ole varaa viivyttää ohjelmiston kehitystä niin pitkään, että laiteverkko kykenee synnyttämään riittävästi tietoa. Itse asiassa laiteverkon käyttöönottoa saatetaan viivästyttää, jotta analytiikan ja koneoppimisen asiantuntijat voivat tehdä siihen tarvittavat hienosäädöt sovelluksen tuottamien tulosten perusteella. Pahimmassa tapauksessa laiteverkon käyttöönotto ja ohjelmistokehitys saattavat jäädä takalukkoon, jossa molemmat riippuvat toistensa tuloksista.

Onneksi ongelman ratkaisu löytyy IoT-arkkitehtuurien luonteesta. Vaikka pilvipalveluiden arkkitehtuureissa onkin joitakin samankaltaisuuksia, kuten yllä kuvatut Microsoftin ja AWS:n esimerkit osoittavat, niiden yksityiskohdat luonnollisesti poikkeavat toisistaan. Tästä huolimatta niissä näkyy samankaltainen IoT-pilvialustoista löytyvä ominaisuus: hyvin määritelty rajapintamoduuli tai kerrostoiminnallisuus, joka erottaa IoT-laitteiden verkon pilvipohjaisesta sovelluksesta. Sen lisäksi että nämä rajapintapalvelut tarjoavat yhtenäisen liitettävyyden, ne ovat keskeisessä roolissa laitteiden hallinnan ja tietoturvan sekä muiden suuren mittakaavan IIoT-sovellukselta vaadittujen kykyjen kannalta.

Microsoft Azure -pilvessä rajapinnan nimi on Azure IoT Hub (ks. kuva 1), kun taas AWS-pilvessä se on AWS IoT Core (ks. kuva 2). Google Cloud Platformissa rajapinta on Cloud IoT Core, IBM Cloudissa taas IBM Watson IoT Platform Service. Muut alustat kuten ThingWorx IoT Platform yhdistävät samalla tavoin liitettävyyspalvelun kautta, jollaisia ovat mm. ThingWorx Edge Microserver, ThingWorx Kepware Server tai protokollasovitinten työkalusarjat. Lyhyesti voidaan sanoa, että minkä tahansa pilvialustan on tarjottava yhtenäinen rajapintapalvelu, joka kanavoi dataa ulkopuolisesta verkosta pilvipalveluihin. Näin vältetään monimutkainen tilanne, jossa lisälaitteet käyttävät suoraan pilvessä olevia resursseja.

Simuloidun datan syöttäminen

Kunkin IoT-alustan ohjelmistokehityssarjan (SDK) avulla kehittäjät voivat syöttää simuloitua anturitietoa suoraan alustan rajapintapalveluun soveltaen oikeita määriä, nopeutta ja vaihteluvälejä, joita tarvitaan vahvistamaan sovelluksen toiminta ja suorituskyky. Halutulla nopeudella ja tarkkuudella generoitu simuloitu tieto siirretään rajapinnalle käyttäen standardinmukaista protokollaa, joita ovat mm. MQ Telemetry Transport (MQTT) ja Constrained Application Protocol (CoAP). Rajapintapalvelun (ja sitä seuraavan sovelluksen) näkökulmasta simuloidut datavirrat ovat täysin samanlaisia kuin laitteistoantureista tallennettu data. Kun laiteverkot ovat valmiina käyttöönottoon, niiden antureiden tuottamat datavirrat korvaavat rajapintapalveluun syötetyt simuloidut datavirrat.

Pilvipalveluiden tarjoajat tukevat yleensä tätä datan simulointia eri tasoilla. Esimerkiksi Google esittelee yksinkertaista simulaatiopohjaista sovellusta referenssiarkkitehtuurilla ja esimerkkikoodilla, jolla toteutetaan lämpötilaohjatun tuulettimen yksinkertainen ohjaussilmukka. Aiemmin esiteltyjen arkkitehtuurien tavoin tämä hyödyntää Google Cloud Platform -palveluita, joita syötetään Google Cloud IoT Core -palvelurajapinnan kautta (kuva 3).

Kuva 3: Missä tahansa IoT-alustassa laitesimulaattorit syöttävät rajapintapalveluun dataa käyttäen samoja viestintäprotokollia kuin fyysiset laitteet; tässä esimerkissä näkyy Google Cloud IoT Core ja Google Cloud Platform -sovellusarkkitehtuuri. (Kuvan lähde: Google)

Tässä esimerkkisovelluksessa lämpötila-anturisimulaattorit generoivat dataa valitulla päivitysnopeudella ja välittävät datan Google Cloud IoT Core -rajapintapalveluun MQTT-viestiprotokollan kautta. Tämä rajapintapalvelu puolestaan käyttää alustan normaaleja julkaisu- ja tilausprotokollia (pub/sub) siirtääkseen datan simuloidulle palvelulle, joka vastaa tuulettimen käynnistys- tai sammutuskomennolla tarpeen mukaan (kuva 4).

Kuva 4: Googlen esimerkkisovellus esittelee perustason ohjaussilmukan, jossa simuloitu laite lähettää dataa Google Cloud IoT Coren kautta simuloidulle palvelimelle käyttäen standardeja tiedonsiirtomenetelmiä. (Kuvan lähde: Google)

Google tarjoaa Python-esimerkkikoodin, jolla tämä perussovellus voidaan toteuttaa. Tässä koodissa Device-luokan instanssi sisältää metodin, joka päivittää simuloitua lämpötilaa perustuen simuloidun tuulettimen tilaan. Päärutiini kutsuu tätä metodia määritellyin väliajoin ja lähettää datan käyttäen MQTT-yhteyspalvelua, joka saadaan Eclipsen paho-mqtt Python MQTT -asiakasmoduulista (listaus 1).

Kopioi
class Device(object):
     """Represents the state of a single device."""

    def __init__(self):
         self.temperature = 0
         self.fan_on = False
         self.connected = False

    def update_sensor_data(self):
         """Pretend to read the device's sensor data.
        If the fan is on, assume the temperature decreased one degree,
        otherwise assume that it increased one degree.
        """
         if self.fan_on:
             self.temperature -= 1
         else:
             self.temperature += 1
.
.
.
def main():
.
.
.
    device = Device()


    client.on_connect = device.on_connect
     client.on_publish = device.on_publish
     client.on_disconnect = device.on_disconnect
     client.on_subscribe = device.on_subscribe
     client.on_message = device.on_message


    client.connect(args.mqtt_bridge_hostname, args.mqtt_bridge_port)


    client.loop_start()


    # This is the topic that the device will publish telemetry events
     # (temperature data) to.
     mqtt_telemetry_topic = '/devices/{}/events'.format(args.device_id)


    # This is the topic that the device will receive configuration updates on.
     mqtt_config_topic = '/devices/{}/config'.format(args.device_id)


    # Wait up to 5 seconds for the device to connect.
     device.wait_for_connection(5)


    # Subscribe to the config topic.
     client.subscribe(mqtt_config_topic, qos=1)


    # Update and publish temperature readings at a rate of one per second.
     for _ in range(args.num_messages):
         # In an actual device, this would read the device's sensors. Here,
         # you update the temperature based on whether the fan is on.
         device.update_sensor_data()


        # Report the device's temperature to the server by serializing it
         # as a JSON string.
         payload = json.dumps({'temperature': device.temperature})
         print('Publishing payload', payload)
         client.publish(mqtt_telemetry_topic, payload, qos=1)
         # Send events every second.
         time.sleep(1)


    client.disconnect()
     client.loop_stop()
     print('Finished loop successfully. Goodbye!')

Listaus 1: Tämä osa Googlen esimerkkisovelluksesta näyttää, miten main-rutiini päivittää säännöllisesti Device-luokan instanssia, joka tallentaa simuloidun lämpötila-anturin nykyisen arvon ja tuottaa metodin, joka päivittää tätä arvoa simuloidun tuulettimen tilan perusteella. (Lähdekoodi: Google)

Server-luokan instanssi puolestaan tarjoaa moduulin, joka päivittää tuulettimen tilaa Device-luokan instanssilta saadusta lämpötiladatasta riippuen (listaus 2).

Kopioi
class Server(object):
     """Represents the state of the server."""
.
.
.
    def _update_device_config(self, project_id, region, registry_id, device_id,
                               data):
         """Push the data to the given device as configuration."""
         config_data = None
         print('The device ({}) has a temperature '
               'of: {}'.format(device_id, data['temperature']))
         if data['temperature'] < 0:
             # Turn off the fan.
             config_data = {'fan_on': False}
             print('Setting fan state for device', device_id, 'to off.')
         elif data['temperature'] > 10:
             # Turn on the fan
             config_data = {'fan_on': True}
             print('Setting fan state for device', device_id, 'to on.')
         else:
             # Temperature is OK, don't need to push a new config.
             return

Listaus 2: Tässä Googlen esimerkkisovelluksen katkelmassa metodi _update_device_config(), joka määritetään Server-luokassa, tarjoaa sovelluksen toimintalogiikan: se käynnistää tuulettimen, kun lämpötila nousee määritetyn arvon yli, ja sammuttaa tuulettimen lämpötilan laskiessa. (Lähdekoodi: Google)

Googlen esimerkkikoodin lisäksi GitHubin kaltaisissa tietovarastoissa on kymmenittäin avoimeen lähdekoodiin pohjautuvia IoT-laitteiden, -järjestelmien ja -verkkojen simulaattoreita. Esimerkiksi Microsoftin avoimen lähdekoodin Raspberry Pi -järjestelmäsimulaattorikoodi sisältää valmiin integroinnin Azure IoT Hubiin, mikä nopeuttaa Raspberry Pi -korttien kanssa toimivien pilvipohjaisten sovellusten kehitystä. Lisäksi Node-REDin kaltaiset vähän koodaamista vaativat ohjelmointityökalut tukevat valmiita moduuleja (solmuja), joilla simuloitua anturidataa voidaan syöttää johtavien pilvialustojen IoT-palveluiden rajapintoihin. Näiden lähestymistapojen avulla kehittäjät voivat helposti generoida anturidatavirran.

Simulaatioiden suorittaminen suuressa mittakaavassa

Laitetason simulaattorien ja niihin liittyvien työkalujen käytön vaikeutena on se, että datan simuloinnin hallinta voi itsessään muuttua projektiksi. Kehittäjien tulee varata ja ylläpitää resursseja simulaattorien suorittamiseen muiden sovellusten tavoin. Suurempi huolenaihe on se, että realistisen datan generointiin käytetyistä laitemalleista muodostuu erillinen projekti IIoT-sovelluksen kehitysprosessin ulkopuolelle. Projektin edetessä kehittäjien tulee varmistaa, että laitemallit on toiminnoiltaan synkronoitu IIoT-laiteverkon ja sovelluksen muutoksiin. Yritystason IIoT-sovellusten kehittäjät saattavat havaita, että simulaatioiden skaalaaminen on vaikeaa, ja se voi alkaa kuluttaa jopa sovelluksen kehittämiseen tarvittavia resursseja.

Suurimmat IoT-pilvialustojen tarjoajat ovat ottaneet nämä huolenaiheet huomioon tarjoamalla IoT-laitteiden simulointiratkaisuja, jotka on suunniteltu skaalautumaan yhtä helposti kuin alustojen muutkin pilviresurssit. Esimerkiksi AWS IoT Device Simulator tarjoaa CloudFormation-konfiguraatiopalvelulle AWS-mallipohjan, joka käyttää virtuaalista yksityisverkkoa yhdistämään mikropalveluita, jotka on toteutettu ilman palvelinta toimivaan AWS Fargate -rutiiniin pohjautuvilla säilöillä (kuva 5).

Kuva 5: AWS IoT Device Simulator yhdistää useita AWS-palveluita tuottaakseen skaalautuvan laitedatavirran samaan AWS IoT Core -rajapintaan, jota fyysiset laitteet käyttävät. (Kuvan lähde: Amazon Web Services)

Kehittäjät voivat käyttää simulaatiota vuorovaikutteisesti Amazon S3 -palvelussa toimivan graafisen käyttöliittymäkonsolin kautta tai ohjelmallisesti käyttäen IoT Device Simulator -sovellusrajapintaa (API), jonka CloudFormation-mallipohja luo Amazon API Gateway -palveluun. Simulointiajon aikana IoT Device Simulator -mikropalvelu hakee laitteiden kokoonpanotiedot Amazon DynamoDB NoSQL -tietokannasta noudattaen simulaatiosuunnitelmaa, joka on kuvattu sen konfiguraatiokohteessa.

Laitekonfiguraatiot ovat JSON-tietueita, joissa määritetään muun muassa laitteen attribuuttien nimet (esim. lämpötila), arvoalueet (esim. -40 – 85), laitteen päivitysväli ja simulaation kesto. Kehittäjät voivat lisätä laitetyyppejä vuorovaikutteisesti konsolin kautta tai ohjelmallisesti APIn kautta. Normaaleja DevOps-menetelmiä käyttäen laitetyypit, konfiguraatio ja infrastruktuuri voidaan skaalata nopeasti siten, että saavutetaan AWS IoT Corelle ja sen kautta toimivalle sovellukselle tarvittava datamäärä.

Azure-laitesimulaattorissa kehittäjät voivat täydentää perusattribuuttien luetteloa lisäämällä joukon toimintatapoja, joita laite tukee simulaation aikana, sekä metodeja, joita pilvisovellus voi kutsua suoraan.

Digitaaliset kaksoset

Tällainen laitedatan simulointi on käsitteellisesti hyvin lähellä kaupallisten IoT-pilvialustojen lisääntyviä digitaalisia kahdennusominaisuuksia. Toisin kuin laitevarjot (shadows), jotka tarjoavat yleensä vain staattisen esityksen laitteen tilasta, digitaalinen kaksonen laajentaa virtuaalista laitemallia vastaamaan sekä laitteen fyysistä tilaa että sen käytöstä.

Microsoft Azuren Digital Twins -palvelussa kehittäjät voivat lisätä käyttäjän funktioita määrittämään toimintaa laitteen simuloinnin aikana, syöttäen samalla tulokset Azure IoT Hubiin entiseen tapaan. Riippumatta siitä, onko tuleva data simuloitua vai todellista, se lähetetään tapahtuman reitityspalveluun jaeltavaksi sovelluksessa. Microsoft käyttää digitaalisen kaksosen dataa myös luomaan paikkatietokaavioita, joissa kuvataan vuorovaikutukset ja elementtien väliset tilat monimutkaisissa hierarkkisissa ympäristöissä, kuten useita verkkoja sisältävässä teollisuusautomaatiojärjestelmässä (kuva 6).

Kuva 6: Microsoft Azuren Digital Twins -palvelussa kehittäjät voivat rakentaa virtuaalilaitteita, jotka vastaavat fyysisiä laitteita ominaisuuksiltaan ja kyvyiltään sekä tarjoavat perustan sofistikoituneille palveluille, kuten monimutkaisten IIoT-hierarkioiden paikkatietokaavioille. (Kuvan lähde: Microsoft)

IIoT-sovelluksille digitaaliset kaksoset voivat tarjota tehokkaan mekanismin, joka pystyy tukemaan näiden kykyjen ympärille rakennettujen sovellusten koko elinkaarta. Kehityksen varhaisessa vaiheessa digitaalisia kaksosia voidaan ohjata alustan laitesimulointipalveluiden kautta suuressakin mittakaavassa. Kun fyysiset IIoT-verkot käynnistyvät, digitaaliselle kaksoselle syötetty simuloitu data voidaan korvata laitteen datasyötteillä. Myöhemmin, kun IIoT-sovellus on täysin käytössä, kehittäjät voivat käyttää fyysisen laitteen ja sen digitaalisen kaksosen välisiä eroja lisäsyötteenä ennakkohuoltoalgoritmeille tai apuna tietoturvaloukkausten tunnistamisessa. Digitaaliset kaksoset voivat koko käyttöiän ajan suojata sovellusta verkkokatkoksilta tai merkittäviltä IIoT-laiteverkkojen konfiguraatiomuutoksilta.

Digitaalisten kaksosten yleistyminen IoT-alustoilla tarjoaa myös toisen edun, sillä niiden kautta saadaan määriteltyä standardoitu lähestymistapa laitemallien attribuuttien ja käyttäytymisen kuvaukselle. Kuvauskielenä Microsoftin Azure Digital Twins -palvelu käyttää JSON-LD:tä (JavaScript Object Notation for Linked Data). World Wide Web Consortiumin (W3C) tukema JSON-LD tarjoaa standardoidun muodon linkitetyn datan muuntamiselle sarjamuotoon. Se perustuu standardimuotoiseen JSON-formaattiin, joka on jo käytössä monissa muissa sovellussegmenteissä.

Standardoiduilla digitaalisten kaksosten kuvauksilla voidaan nopeuttaa kehitystä entisestään, kun antureista ja toimilaitteista alkaa ilmestyä saataville valmiiksi laadittuja kuvauksia. Esimerkiksi Bosch tarjoaa jo nyt monista antureistaan avoimen lähdekoodin digitaaliset kaksoskuvaukset. Ne on laadittu Eclipse Vorto -kielellä ja julkaistu Eclipse Vorto -tietovarastoissa. Useimmille ohjelmoijille tuttua rakennetta käyttävä Eclipse Vorto -kieli tarjoaa yksinkertaisen tavan kuvailla malleja ja rajapintoja digitaalisia kaksosia varten. Kehittäjät voivat myöhemmin kääntää Vorto-kieliset kuvaukset tarpeen mukaan JSON-LD:ksi tai muihin muotoihin.

IIoT-sovelluksen rakentaminen

Riippumatta siitä, tehdäänkö se erillisillä simulaattoreilla vai mikropalveluita hyödyntävillä alustoilla, laitedatan simulointi on tehokas ohjelmistopohjainen ratkaisu sovelluskehityksen nopeuttamiseen. Useita laiteverkkoja käyttävissä IIoT-sovelluksissa laitesimulaatioiden siirto verkon reunalle voi helpottaa käyttöönottoon siirtymistä ja mahdollistaa samalla edustavan datan saatavuuden kehityksen varhaisvaiheissa.

Edge Computing -järjestelmät ovat yhä tärkeämmässä roolissa laajamittaisissa IoT-sovelluksissa. Nämä järjestelmät tarjoavat paikallisia resursseja, joita vaaditaan yhä lisääntyviin vaatimuksiin, kuten datan esikäsittelyyn, jotta voidaan vähentää pilveen lähetettävää datamäärää, sekä kehittyneeseen luokitteluun muun muassa koneoppimisen päättelymalleja varten. Edge Computing -järjestelmät toimivat myös tärkeinä viestinnän yhdyskäytävinä kentällä sijaitsevien laiteverkkojen ja nopeiden taustaverkkojen välillä.

Multi-Tech Systemsin ohjelmoitavan MultiConnect Conduit -tuoteperheen kaltaiset yhdyskäytävät tarjoavat alustoja, jotka yhdistävät viestinnän ja verkon reunalla tapahtuvan prosessoinnin. Multi-Tech MTCAP-915-001A 915 megahertsin (MHz) alueille ja MTCAP-868-001A 868 MHz:n alueille tarjoavat LoRaWAN-yhteydet kentällä toimivan laiteverkon keräämiseen ja Ethernet- tai 4G-LTE-yhteyden pilveen. Avoimen lähdekoodin Multi-Tech Linux (mLinux) -käyttöjärjestelmään perustuvat alustat tarjoavat myös tutun ympäristön laitesimulaatioiden ajoon. Kun erillisten kenttäverkkojen fyysiset anturit ja muut laitteet käynnistyvät, yksiköt voivat palata rooliinsa viestinnän yhdyskäytävänä ja käyttää laskentatehoaan esimerkiksi datan esikäsittelyyn.

Yhteenveto

IIoT-sovellukset tuottavat merkittäviä haasteita, mitä tulee anturiverkkojen käyttöönottoon kentällä sekä anturien dataa käyttökelpoisiksi tuloksiksi muuttavan pilvipohjaisen sovellusohjelmiston kehittämiseen. Anturiverkostojen ja sovellusohjelmien keskinäisestä riippuvuudesta voi seurata kehityksen pysähtyminen, kun anturien käyttöönotto ja ohjelmistojen toteutus odottavat, että kumpikin saavuttaa kriittisen massan.

Kuten artikkelissa osoitetaan, kehittäjät voivat murtaa tämän takalukon ja nopeuttaa IIoT-sovellusten kehitystä simuloimalla datavirtoja realistisella määrällä, nopeudella ja vaihteluvälillä.