Akselerer utviklingen av industrielle IoT-applikasjoner – Del 1: Simulering av IoT-enhetsdata

Redaktørens merknad: Utviklingsprosjekter for innebygde applikasjoner blir ofte forsinket når utviklere venter på at maskinvareimplementeringer av nye enheter skal bli tilgjengelige. Applikasjonsutvikling for industrielt tingenes Internett (IIoT – Industrial Internet of Things) opplever en lignende flaskehals, som innebærer å vente på sensordataene som er nødvendig for applikasjoner som industrielle prediktive vedlikeholdssystemer eller automatiserte anleggssystemer basert på maskinlæringsmetoder. Denne serien i to deler utforsker ulike alternativer for å tilby tidlige datastrømmer som er nødvendig for å akselerere utviklingen av IIoT-applikasjoner. Her, i del 1, beskrives bruken av simuleringsmetoder for å generere disse datastrømmene. Del 2 tar for seg hvilke alternativer som kan brukes for rask prototyputvikling av sensorsystemer for generering av data.

Applikasjoner for industrielt tingenes Internett (IIoT) i storskala byr på flere utfordringer som kan forsinke distribusjoner og føre til at selskaper begynner å vurderer om avkastningen er stor nok for de mange ressursene som kreves for implementering. For å forhindre at slike situasjoner oppstår og gjøre det enklere for utviklere å raskere forstå fordelene av en IIoT-distribusjon, er det nødvendig å ha lett tilgang til data for simulering av distribusjon.

Ved å bruke simuleringsmetoder for å generere realistiske datastrømmer, kan utviklere starte utviklingen av IIoT-applikasjoner i god tid før distribusjonen av IoT-nettverket, og til og med raffinere definisjonen av selve IIoT-sensornettverket.

Denne artikkelen tar for seg hvordan de forskjellige IoT-skyplattformene er tilrettelagt for datasimulering, og introduserer eksempelgatewayer fra Multi-Tech Systems Inc. som kan fremskynde distribusjonen ytterligere.

Fordelen av å simulere IIoT-data

Bruk av simulerte data til å drive applikasjoner og systemutvikling, er selvfølgelig ikke noe nytt. Utviklere har brukt simuleringsmetoder på systemnivå i flere tiår for å stressteste databehandlingsinfrastrukturer og tilkoblingstjenester. Disse testene yter en viktig funksjon ved at de bekrefter robustheten til statiske konfigurasjoner. For skytjenesteplattformer, tilbyr disse testene en relativt enkel måte å bekrefte automatisk skalering av virtuelle maskiner og andre skyeressurser.

IIoT-applikasjoner deler disse samme kravene, i tillegg til flere andre. I tillegg til å bidra til lasttesting og automatisk skalering, er datasimulering et viktig verktøy for å bekrefte integreringen av de mange ulike tjenestene og ressursene som er nødvendige for å implementere programvare, spesielt programvare som har kompleksiteten til en IIoT-applikasjon på bedriftsnivå. Utover disse grunnleggende fremgangsmåtene, kan datasimulering akselerere utviklingen av komplekse IIoT-applikasjoner som er bygd på de sofistikerte tjenesteplattformene som tilbys av ledende nettskyleverandører.

Programvareperspektiv

IIoT-applikasjoner opererer på komplekse arkitekturer som ser svært annerledes ut for utviklere av applikasjonsprogramvare enn for utviklere av sensor- og aktuatorsystemer. For sistnevnte er en IIoT-arkitektur i storskala en enorm samling av sensorer og aktuatorer som er sammenkoblet med de fysiske prosessene forbundet med den samlede applikasjonen. For utviklere av applikasjonsprogramvare, omfatter en IIoT-arkitektur på bedriftsnivå et antall tjenester som, med sin koordinerte aktivitet, til slutt leverer funksjonaliteten til applikasjonen.

Referansearkitekturen til Microsoft Azure IoT gir en representativ presentasjon av typiske IIoT-applikasjoner (og IoT-applikasjoner generelt) fra perspektivet til applikasjonsprogramvaren. Dette perspektivet oppsummerer de mange funksjonelle tjenestene som en typisk applikasjon forener i skyen for å levere innsikt og handlinger basert på data fra endepunktet og kantenheter (edge devices) i periferien/utkanten (figur 1).

Figur 1: Microsoft Azure IoT-referansearkitekturen illustrerer de mange typene skytjenester og ressurser en IIoT-applikasjon vanligvis krever for å kunne levere praktisk innsikt og handling fra data som er generert av enhetsnettverk i periferien. (Bildekilde: Microsoft Corp.)

Spesifikke applikasjonsløsninger distribuerer disse skyressursene i egnede kombinasjoner, og er funksjonelt sammenkoblet via standardiserte utvekslingsmekanismer og koordinert av applikasjonslogikk. I løsningen for tilkoblede kjøretøy, foreslår for eksempel Amazon Web Services (AWS) en måte som skytjenester kan mikses og matches i moduler som er ansvarlige for å tilby forskjellige funksjoner og muligheter i applikasjonen (figur 2).

Figur 2: Løsningen for AWS-tilkoblede kjøretøy gir et representativt bilde av orkestreringen av skytjenester for en typisk IoT-applikasjon i storskala som leverer nødvendige funksjonelle muligheter. (Bildekilde: Amazon Web Services)

Slik disse arkitektoniske representasjonene antyder, er programvareutviklingen som kreves for å opprette en IIoT-applikasjon like utfordrende og ekspansiv som å implementere eksterne nettverk av sensor- og aktuatorsystemer. Det er få organisasjoner som har råd til å utsette utviklingen av denne komplekse programvaren helt til enhetsnettverket er i stand til å generere tilstrekkelig med data. Distribusjon av enhetsnettverket må faktisk i noen tilfeller vente på ytterligere definisjoner og forbedringer som kan dukke opp når analysespesialister og maskinlæringseksperter begynner å jobbe med applikasjonsresultater. I verste fall kan distribusjonen av enhetsnettverket og programvareutviklingen plutselig stanse, fordi begge er avhengige av resultatene fra den andre parten.

Heldigvis ligger løsningen på dette dilemmaet i egenskapene til selve IoT-arkitektureren. Utover en viss generell likhet, har selvfølgelig skytjenestearkitekturer, for eksempel de som er illustrert ovenfor fra Microsoft og AWS, ulike egenskaper. Likevel demonstrerer de alle en lignende arkitektonisk funksjon som vi vanligvis finner i IoT-skyplattformer: En veldefinert grensesnittjenestemodul eller lagfunksjonalitet som skiller periferinettverket med IoT-enheter fra den skybaserte programvaren. I tillegg til å gi balanserte tilkoblingsmuligheter, er disse grensesnittjenestene veldig viktige for enhetsstyring og sikkerhet, i tillegg til andre viktige funksjoner som kreves av IIoT-applikasjoner i storskala.

I Microsoft Azure-skyen kalles denne grensesnittstjenesten Azure IoT Hub (se figur 1 igjen), og i AWS-skyen kalles denne AWS IoT Core (se figur 2 igjen). I Googles skyplattform (Google Cloud Platform) er dette grensesnittet Cloud IoT Core, og i IBM Cloud er det IBM Watson IoT Platform Service. Andre plattformer, for eksempel ThingWorx IoT Platform, tilkobles på samme måte gjennom tilkoblingstjenester som ThingWorx Edge Microserver, ThingWorx Kepware Server eller programverktøy for protokolladaptere. Kort sagt må enhver skyplattform være i stand til å tilby en konsistent grensesnittjeneste som sammenfører data fra periferien til skytjenester, eller risikere å ende opp med en forvirrende floke av tilkoblinger fra periferienheter direkte til individuelle ressurser som ligger dypt inne i skyen.

Injiserere simulerte data

Ved å bruke programvareutviklingssettet (SDK – software development kit) til hver enkelt IoT-plattform, kan utviklere injisere simulerte sensordata direkte til plattformens grensesnittjeneste, ved nødvendige nivåer av volum, hastighet og variasjon, for å bekrefte funksjonalitet og ytelse til applikasjonen. Simulerte data som er generert med ønsket hastighet og oppløsning når grensesnittjenesten ved å bruke standardprotokoller som MQ Telemetry Transport (MQTT), Constrained Application Protocol (CoAP) og andre. Grensesnittjenesten (og nedstrøms applikasjonsprogramvare) kan ikke skille de simulerte datastrømmene fra data som er innhentet av et maskinvarebasert sensorsystem. Når enhetsnettverk er klare til å komme på nett, erstatter sensordatastrømmene til disse nettverkene de simulerte datastrømmene som når frem til grensesnittjenesten.

Leverandører av skyplattformer støtter vanligvis denne tilnærmingen til datasimulering på forskjellige kapasitetsnivåer. Google demonstrerer for eksempel en enkel simuleringsdrevet applikasjon med en referansearkitektur og eksempelkode som implementerer en enkel reguleringssløyfe for en temperaturkontrollert vifte. Slik arkitekturene illustrerte tidligere, drar denne arkitekturen nytte av Google Cloud Platform-tjenester matet av Google Cloud IoT Core-tjenestegrensesnittet (figur 3).

Figur 3: I enhver IoT-skyplattform bruker enhetssimulatorer de samme kommunikasjonsprotokollene som brukes av fysiske enheter til å mate data til en grensesnittjeneste, for eksempel Google Cloud IoT Core for Google Cloud Platform-applikasjonsarkitekturen som er vist her. (Bildekilde: Google)

I denne eksempelapplikasjonen genererer simulatorer for tempererte sensorenheter data med en valgt oppdateringsfrekvens, og videresender dataene til Google Cloud IoT Core-grensesnittjenesten ved hjelp av MQTT-meldingsprotokollen. Denne grensesnittjenesten bruker så plattformens standardprotokoller for publisering-abonnement (pub/sub) til å overføre dataene til en simulert server, som responderer med en kommando om å slå av eller på viften etter behov (figur 4).

Figur 4: En Google-testapplikasjon demonstrerer en grunnleggende reguleringsløkke som omfatter en simulert enhet som sender data gjennom Google Cloud IoT Core til en simulert server ved hjelp av standard kommunikasjonsmetoder. (Bildekilde: Google)

Google leverer Python-eksempelkode som implementerer denne grunnleggende applikasjonen. Et Device-klasseeksempel i denne koden omfatter en metode som oppdaterer den simulerte temperaturen basert på tilstanden til den simulerte viften. «main»-rutinen kaller denne metoden med en bestemt hyppighet, og sender dataene med en MQTT-tilkoblingstjeneste som er levert av Eclipse paho-mqtt Python MQTT-klientmodulen (liste 1).

Copy
class Device(object):
     """Representerer tilstanden til en enkelt enhet."""
 
    def __init__(self):
         self.temperature = 0
         self.fan_on = False
         self.connected = False
 
    def update_sensor_data(self):
         """Gir seg ut for å lese enhetens sensordata.
        Hvis viften er på, antas det at temperaturen falt én grad,
        ellers antas det at den økte én grad.
        """
         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()
 
 
    # Dette er emnet som enheten vil publisere av telemetrihendelser
     # (temperature data) to.
     mqtt_telemetry_topic = '/devices/{}/events'.format(args.device_id)
 
 
    # Dette er emnet som enheten vil motta konfigurasjonsoppdateringer på.
     mqtt_config_topic = '/devices/{}/config'.format(args.device_id)
 
 
    # Vent opptil 5 sekunder på at enheten skal koble til.
     device.wait_for_connection(5)
 
     # Abonner på konfigurasjonsemnet.
     client.subscribe(mqtt_config_topic, qos=1)
 
 
    # Oppdaterer og publiserer temperaturavlesninger med en hyppighet på én per sekund.
     for _ in range(args.num_messages):
         # I en ekte enhet, vil dette lese sensorene til enheten. Her,
         # oppdaterer du temperaturen basert på om viften er på eller av.
         device.update_sensor_data()
 
 
        # Rapporterer enhetens temperatur til serveren ved å serialisere den (serializing it)
         # som en JSON-streng.
         payload = json.dumps({'temperatur': device.temperature})
         print('Publiserer nyttelast', payload)
         client.publish(mqtt_telemetry_topic, payload, qos=1)
         # Send hendelser hvert sekund.
         time.sleep(1)
 
 
    client.disconnect()
     client.loop_stop()
     print('Fullført løkke (loop). Ha det bra!')

Liste 1: Dette utdraget fra Google-eksempelapplikasjonen illustrerer hvordan main-rutinen periodisk oppdaterer en Device-klasseinstans som lagrer den nåværende verdien til den simulerte temperatursensoren, og tilbyr en metode som oppdaterer denne verdien basert på tilstanden til den simulerte viften. (Kodekilde: Google)

En Server-klasseinstans tilveiebringer så en modul som oppdaterer viftetilstanden avhengig av temperaturdata som er mottatt fra Device-klasseinstansen (liste 2).

Copy
class Server(object):
     """Representerer serverens tilstand."""
.
.
.     def _update_device_config(self, project_id, region, registry_id, device_id,
                               data):
         """Push dataene til den angitte enheten som konfigurasjon."""
         config_data = None
         print('Enheten ({}) har temperatur '
               'på: {}'.format(device_id, data['temperatur']))
         if data['temperatur'] < 0:
             # Slå av viften.
             config_data = {'fan_on': False}
             print('Innstille viftetilstand for enheten', device_id, 'til av.')
         elif data['temperatur'] > 10:
             # Skru på viften
             config_data = {'fan_on': True}
             print('Innstille viftetilstand for enheten', device_id, 'til på.')
         else:
             # Temperaturen er OK; det er ingen grunn til å pushe en ny konfigurasjon.
             return

Oppføring 2: I denne kodesnutten fra Google-eksempelapplikasjonen, definerer metoden _update_device_config () i Server-klassen virksomhetslogikken for applikasjonen, og angir viftestatusen som på når temperaturen stiger over en definert verdi og angir viftetilstanden som av når den faller. (Kodekilde: Google)

I tillegg til Google-eksempelkoden, kan utviklere finne dusinvis av åpen kildekode for IoT-enhets-, system- og nettverksimulatorer på programvarelager som GitHub. Microsofts åpne kildekode for Raspberry Pi-systemsimulatorkoden kommer forhåndsintegrert med Azure IoT Hub for å oppnå rask utvikling av skybaserte applikasjoner som samhandler med Raspberry Pi-kort. I tillegg støtter programmeringsverktøy for low-code (utvikling av applikasjoner med minimal bruk av koding), for eksempel Node-RED, forhåndsbygde moduler (noder) for å mate simulerte sensordata til de ledende IoT-tjenestegrensesnittene for skyplattformen. Ved å bruke disse metodene, kan utviklere enkelt generere en strøm av sensordata.

Kjøre simuleringer i skala

Utfordringen med å bruke simuleringer på enhetsnivå og relaterte verktøy, er at administrasjon av datasimuleringen kan bli et eget prosjekt i seg selv. For å kjøre simulatorene må utviklere forsyne og vedlikeholde ressurser, i likhet med alle andre applikasjoner. En større bekymring er at enhetsmodellene som brukes til å generere realistiske data blir et eget prosjekt i seg selv utenfor utviklingsprosessen av IIoT-applikasjonen. Etter hvert som utviklingen går videre, må utviklere sørge for at enhetsmodeller forblir synkronisert på en funksjonell måte med alle endringer i definisjonen av IIoT-enhetsnettverket og -applikasjonen. For IIoT-applikasjoner på bedriftsnivå, kan utviklere oppleve skalering av disse simuleringene som utfordrende, og til og med dra til seg ressurser som er satt av til utvikling av applikasjonen.

De største leverandørene av IoT-skyplattformer forsøker å løse disse utfordringene med løsninger for IoT-enhetssimulering som er utviklet til å skalere like enkelt som andre skyressurser på deres respektive plattformer. AWS IoT-enhetssimulatoren tilbyr for eksempel en AWS-mal for sin CloudFormation-konfigurasjonstjeneste, som distribuerer et virtuelt privat nettverk som forbinder mikrotjenester implementert i containere som kjører på den serverløs motoren AWS Fargate (figur 5).

Figur 5: AWS IoT-enhetssimulatoren kombinerer flere AWS-tjenester for å kunne levere en skalerbar strøm av enhetsdata til samme AWS IoT Core som brukes av fysiske enheter. (Bildekilde: Amazon Web Services)

Utviklere får interaktiv tilgang til simuleringen gjennom en grafisk brukergrensesnittkonsoll (GUI – Graphical User Interface) som kjører i Amazon S3-tjenesten, eller programmatisk gjennom API-en til IoT-enhetssimulatoren som er generert av CloudFormation-malen i Amazon API Gateway-tjenesten. Under kjøring av en simulering, trekker mikrotjenesten for IoT-enhetssimulatoren til seg enhetskonfigurasjoner fra Amazon DynamoDB NoSQL-databasen i henhold til en generell simuleringsplan som er beskrevet i sitt eget konfigurasjonselement.

Enhetskonfigurasjonene er JSON-oppføringer som definerer enhetens egenskapsnavn (f.eks. temperatur), verdiområde (f.eks. -40 til 85) og oppdatering av enhetsintervall og simuleringsvarighet, i tillegg til annen informasjon. Utviklere kan legge til enhetstyper interaktivt gjennom konsollen eller programmatisk gjennom API-en. Ved å bruke vanlige DevOps-metoder kan enhetstypene, konfigurasjonen og infrastrukturen raskt skaleres for å oppnå den ønskede hyppigheten til dataoppdatering som når frem til AWS IoT Core og den nedstrøms applikasjonen.

I Azure-enhetssimulatoren kan utviklere videre supplere den grunnleggende listen over egenskaper med en atferdsgruppe som støttes av enheten under kjøringen av simuleringen, samt en metodegruppe som skyapplikasjonen kan påkalle direkte.

Digitale tvillinger

Denne typen enhetsdatasimulering er tett sammenknyttet med muligheter for digitale tvillinger som dukker opp i kommersielle IoT-skyplattformer. I motsetning til enhetsskygger som vanligvis kun gir en statisk representasjon av enhetstilstanden, utvider digitale tvillinger en virtuell enhetsmodell for å matche den fysiske enhetstilstanden, så vel som oppførselen til denne.

I Microsofts Azure, gjør Azure Digital Twins-tjenesten det mulig for utviklere å inkludere brukerdefinerte funksjoner som definerer atferd under en enhetssimulering, samtidig som resultatene mates til Azure IoT Hub som før. Uavhengig av om det er simulert eller ekte, avsendes innkommende data så til en tjeneste for hendelsesruting for videre distribusjon i applikasjonen. Microsoft bruker også data om de digitale tvillingene til å opprette romlige grafer (spatial graph) som viser interaksjonene og tilstandene blant elementer i komplekse hierarkiske miljøer, for eksempel et industrielt automatiseringssystem som omfatter flere nettverk (figur 6).

Figur 6: Med Microsoft Azure Digital Twins-tjenesten kan utviklere bygge virtuelle enheter som samsvarer med deres fysiske motparter i funksjoner og muligheter, og som legger grunnlaget for sofistikerte tjenester som romlige grafer over komplekse IIoT-hierarkier. (Bildekilde: Microsoft)

For IIoT-applikasjoner, tilbyr digitale tvillinger en kraftig mekanisme som er i stand til å støtte hele livssyklusen til applikasjoner som er bygget rundt disse mulighetene. I tidlige stadier av utviklingen kan digitale tvillinger drives i skala av plattformens tjenester for enhetssimulering. Når fysiske IIoT-nettverk kommer på nett, kan de simulerte datastrømmene til den digitale tvillingen erstattes av enhetsdatastrømmer. Senere, i en fullstendig distribuert IIoT-applikasjon, kan utviklere bruke forskjellene som finnes mellom en fysisk enhet og dens digitale tvilling som ekstra inputdata til f.eks. prediktive vedlikeholdsalgoritmer eller sikkerhetsrelaterte inntrengningsdetektorer. Gjennom hele livssyklusen kan digitale tvillinger beskytte applikasjonen mot nettverksavbrudd eller betydelige endringer i nettverkskonfigurasjonen til IIoT-enheten.

Fremveksten av digitale tvillinger i IoT-plattformer bidrar også til en sekundær fordel ved å gi en standardisert måte å beskrive egenskaper og atferd for enhetsmodellen på. Microsoft Azure Digital Twins-tjenesten bruker JSON-LD (JavaScript Object Notation for Linked Data) for sitt beskrivelsesspråk. JSON-LD, som er støttet av World Wide Web Consortium (W3C), gir et standardformat for omkoding av sammenkoblede data, basert på bransjestandardformatet JSON, som allerede er i bruk i en rekke andre applikasjonssegmenter.

Standardiserte beskrivelser av digitale tvillinger kan ytterligere fremskynde utviklingen, takket være fremveksten av programvarelager med forhåndsbygde beskrivelser av digitale tvillinger for sensorer og aktuatorer. Bosch tilbyr for eksempel allerede åpen kildekode for beskrivelser av digital tvillinger for flere av sensorene sine som er skrevet i Eclipse Vorto-språket og publisert i Eclipse Vorto-programvarelageret. Ved å bruke grammatikk som allerede er godt kjent for de fleste programmerere, tilbyr Eclipse Vorto-språket en enkel måte å beskrive modeller og grensesnitt for digitale tvillinger. Utviklere kan på et senere tidspunkt konvertere Vorto-språkbeskrivelsene sine til JSON-LD eller andre formater etter behov.

Bygge ut IIoT-applikasjonen

Simulering av enhetsdata, enten det er bygget med diskrete simulatorer eller mikrotjenesteorienterte plattformer, tilbyr en effektiv programvarebasert løsning for å fremskynde applikasjonsutviklingen. For IIoT-applikasjoner som bruker flere enhetsnettverk, kan migrering av enhetssimuleringer til kanten (edge) bidra til å ytterligere forenkle overgangen til distribusjon, uten å ofre behovet for representative data tidlig i applikasjonsutviklingen.

Kantberegningssystemer (edge computing systems) spiller en stadig viktigere rolle innen IoT-applikasjoner i storskala. Disse systemene tilveiebringer de lokale ressursene som er nødvendige for nye krav. Disse kravene kan være grunnleggende dataforbehandling, redusering av datamengden som når frem til skyen eller avanserte klassifiseringsfunksjoner som inferensmodeller for maskinlæring. Kantberegningsystemer spiller også en mer grunnleggende rolle som kommunikasjonsgatewayer mellom enhetsnettverk i feltområdet og høyhastighets backhaul-nettverk.

Gatewayer, som den programmerbare MultiConnect Conduit-familien fra Multi-Tech Systems, leverer plattformer som kombinerer kommunikasjonsstøtte med kantberegningsmuligheter. Multi-Tech MTCAP-915-001A for 915 megahertz (MHz)-regioner og MTCAP-868-001A for 868 MHz-regioner gir LoRaWAN-tilkoblingsmuligheter for aggregering av enhetsdata for feltområde-nettverk, samt Ethernet- eller 4G-LTE-konnektivitet i skyen. Disse plattformene, som er basert på Multi-Tech Linux (mLinux)-operativsystemet med åpen kildekode, tilbyr også et kjent utviklingsmiljø for å kjøre enhetssimuleringer. Når separate feltnettverk kommer på nett med fysiske sensorer og andre enheter, kan hver enkelt enhet gå tilbake til sin rolle som kommunikasjonsgateway og omdirigere behandlingsinnsatsen til krav som forbehandling av data.

Konklusjon

IIoT-applikasjoner byr på signifikante utfordringer for distribusjon av sensornettverk i felten og utvikling av skybasert applikasjonsprogramvare som kan transformere sensordata til nyttige resultater. Den gjensidige avhengigheten av sensornettverk og applikasjonsprogramvare kan føre til at utviklingen roter seg til, mens sensordistribusjon og programvareimplementering venter på hverandre for å nå et tilstrekkelig nivå av kritisk masse.

Som vist, kan utviklere bryte denne blokkeringen og akselerere distribusjon av IIoT-applikasjoner ved å simulere datastrømmer med realistiske nivåer av volum, hastighet og variasjon.