Accelerer Industriel IoT-appudvikling – del 1: simulering af IoT-enhedsdata

Red.: Projekter til udvikling af integrerede applikationer forsinkes ofte, mens udviklere venter på, at hardwareimplementeringer af nye enheder bliver klar. I applikationsudvikling til Industrial Internet of Things (IIoT) opleves en lignende flaskehals: Når der ventes på de nødvendige sensordata til applikationer som f.eks. industrielle prædiktive vedligeholdelsessystemer eller anlægsautomatiseringssystemer baseret på maskinlæringsmetoder. Denne serie i to dele udforsker alternativer til at levere tidlige datastrømme, der er nødvendige for at accelerere IIoT-applikationsudvikling. Denne del 1 beskriver brugen af simuleringsmetoder til generering af disse datastrømme. Del 2 beskriver mulighederne for hurtig prototyping af sensorsystemer til generering af data.

Omfattende applikationer til Industrial Internet of Things (IIoT) giver flere udfordringer, der kan forsinke udrulninger og efterlade virksomheder med usikkerheder om investeringsafkastet af de mange ressourcer, der kræves til implementeringen. For at forhindre sådanne situationer og hjælpe udviklere med hurtigere at fastslå fordelene ved IIoT-udrulning er der behov for let adgang til data om simuleret implementering.

Ved hjælp af simuleringsmetoder til generering af realistiske datastrømme kan udviklere påbegynde IIoT-applikationsudvikling i god tid inden IoT-netværksudrulningen og endda finjustere definitionen af selve IIoT-sensornetværket.

Denne artikel viser, hvordan de forskellige IoT-skyplatforme leverer datasimulering, og vil introducere eksempler på gateways fra Multi-Tech Systems, Inc., der kan fremskynde udrulningen yderligere.

Argumenterne for simulering af IIoT-data

Brugen af simulerede data til at drive applikationer og systemudvikling er naturligvis ikke noget nyt. Udviklere har i årtier brugt simuleringsmetoder på systemniveau til at stressteste computer-infrastrukturer og forbindelsestjenester. Disse test fungerer som en vigtig funktion til at verificere robustheden af statiske konfigurationer. På skytjenesteplatforme er disse test en relativt enkel metode til at verificere automatisk skalering af virtuelle maskiner og andre skybaserede ressourcer.

IIoT-applikationer deler disse samme krav med mere. Ud over at hjælpe med belastningstest og automatisk skalering er datasimulering et vigtigt værktøj til at kontrollere integrationen af de mange forskellige tjenester og ressourcer, der er nødvendige for at implementere kompleks software som en professionel IIoT-applikation. Ud over disse mere grundlæggende praksisser kan datasimulering accelerere udviklingen af komplekse IIoT-applikationer, der er bygget på de avancerede serviceplatforme fra førende cloud-udbydere.

Softwareperspektiv

IIoT-applikationer fungerer på komplekse arkitekturer, der ser meget forskellige ud for hhv. udviklere af softwareapplikationer og udviklere af sensor- og aktuatorsystemer. For sidstnævnte er en omfattende IIoT-arkitektur en kæmpemæssig samling af sensorer og aktuatorer, der kommunikerer med de fysiske processer, der er genstand for det samlede anvendelsesformål. For applikationssoftwareudviklere består en professionel IIoT-arkitektur af en række tjenester, hvis koordinerede aktivitet i sidste ende leverer funktionaliteten i applikationen.

Microsoft Azure IoT-referencearkitekturen giver en repræsentativ visning af typiske IIoT-applikationer (og IoT-applikationer generelt) fra applikationssoftwarens perspektiv. Denne visning opsummerer de mange funktionelle tjenester, som en typisk applikation samler i skyen for at levere indsigt og handlinger baseret på data fra slutpunktet og edge-enhederne i periferien (figur 1).

Figur 1: Microsoft Azure IoT-referencearkitekturen illustrerer de forskellige typer skytjenester og ressourcer, som en IIoT-applikation typisk kræver for at levere nyttig indsigt og handling fra data, der genereres af enhedsnetværk i periferien. (Billedkilde: Microsoft Corp.)

Specifikke applikationsløsninger udruller disse skyressourcer i relevante kombinationer, der er funktionelt forbundet via standardiserede udvekslingsmekanismer og koordineres af applikationslogikken. I sin Connected Vehicle-løsning foreslår Amazon Web Services (AWS) f.eks., hvordan skytjenester kan blandes i moduler, der er ansvarlige for at yde forskellige funktioner og muligheder i applikationen (figur 2).

Figur 2: AWS Connected Vehicle-løsningen giver et repræsentativt billede af en typisk omfattende IoT-applikations orkestrering af skytjenester for at levere de nødvendige funktionelle muligheder. (Billedkilde: Amazon Web Services)

Som disse arkitektoniske repræsentationer antyder, er den softwareudviklingsmæssige indsats, der kræves for at skabe en IIoT-applikation, lige så udfordrende og ekspansiv som implementeringen af perifere netværk af sensor- og aktuatorsystemer. Få organisationer har råd til at forsinke udviklingen af denne komplekse software, indtil enhedsnetværket kan generere tilstrækkelige data. Faktisk er udrulning af enhedsnetværket muligvis nødt til at vente på yderligere definition og finjustering, der kan opstå, når analysespecialister og maskinlæringseksperter begynder at arbejde med applikationsresultater. I værste fald går enhedsnetværksudrulningen og softwareudviklingen i hårdknude: De er hver især afhængig af resultaterne fra hinanden.

Heldigvis findes løsningen på dette dilemma i IoT-arkitekturernes iboende natur. Ud over en række ligheder er skytjenestearkitekturer som dem fra Microsoft og AWS, der er vist ovenfor, naturligvis forskellige på detaljeniveau. Alligevel udviser de alle en lignende arkitektonisk funktion, der typisk findes i IoT-skyplatforme: et veldefineret grænsefladetjenestemodul eller en lagfunktionalitet, der adskiller det perifere netværk af IoT-enheder fra den skybaserede softwareapplikation. Ud over at levere ensartede forbindelser er disse grænsefladetjenester afgørende for administration af enheder og sikkerhed samt andre vigtige funktioner, der kræves i omfattende IIoT-applikationer.

I Microsoft Azure-skyen kaldes denne grænsefladetjeneste Azure IoT Hub (se figur 1 igen); i AWS Cloud er det AWS IoT Core (se figur 2 igen). På Google Cloud Platform er denne grænseflade Cloud IoT Core, og i IBM Cloud er det IBM Watson IoT Platform Service. Andre platforme, såsom ThingWorx IoT Platform, opretter også forbindelse via tjenester som ThingWorx Edge Microserver, ThingWorx Kepware Server eller protokoladapter-værktøjssæt. Kort sagt skal enhver skyplatform levere en konsistent grænsefladetjeneste, der kanaliserer data fra periferien til skytjenester – ellers risikeres et virvar af forbindelser fra eksterne enheder direkte til individuelle ressourcer dybt inde i skyen.

Injektion af simulerede data

Ved hjælp af hver IoT-platforms Software Development Kit (SDK) kan udviklere injicere simulerede sensordata direkte i platformens grænsefladetjeneste på de niveauer af volumen, hastighed og variation, der kræves for at kontrollere applikationens funktionalitet og ydeevne. Simulerede data, der genereres ved den ønskede frekvens og opløsning, når frem til grænsefladetjenesten ved hjælp af standardprotokoller som f.eks. MQ Telemetry Transport (MQTT), Constrained Application Protocol (CoAP) og andre. Grænsefladetjenesten (og downstream-applikationssoftwaren) kan ikke skelne de simulerede datastrømme fra data, der er erhvervet af et hardwarebaseret sensorsystem. Når enhedsnetværk er klar til at komme online, erstatter deres sensordatastrømme simpelthen de simulerede datastrømme, der når frem til grænsefladetjenesten.

Skyplatformsudbydere understøtter typisk denne datasimuleringsmetode på forskellige kapacitetsniveauer. Google demonstrerer f.eks. en simpel simuleringsdrevet applikation med en referencearkitektur og en eksempelkode, der implementerer en enkel kontrolløkke for en temperaturstyret ventilator. Ligesom de arkitekturer, der er illustreret tidligere, udnytter denne arkitektur Google Cloud Platform-tjenester, der er leveret af Google Cloud IoT Core-tjenestegrænsefladen (figur 3).

Figur 3: I enhver IoT-skyplatform bruger enhedssimulatorer de samme kommunikationsprotokoller, der bruges af fysiske enheder, til at levere data til en grænsefladetjeneste, f.eks. Google Cloud IoT Core til applikationsarkitekturen for Google Cloud Platform, som er vist her. (Billedkilde: Google)

I denne eksempelapplikation genererer temperatursensorenhedssimulatorer data med en valgt opdateringsfrekvens og videregiver dataene til Google Cloud IoT Core-grænsefladetjenesten ved hjælp af MQTT-meddelelsesprotokollen. Denne grænsefladetjeneste bruger til gengæld platformens standard publish-subscribe protokoller (pub/sub) til at overføre dataene til en simuleret server, der svarer med en kommando om at slå ventilatoren til eller fra efter behov (figur 4).

Figur 4: Et eksempel på en Google-applikation demonstrerer en grundlæggende kontrolløkke, der omfatter en simuleret enhed, der sender data via Google Cloud IoT Core til en simuleret server ved hjælp af kommunikationsmetoder. (Billedkilde: Google)

Google leverer Python-eksempelkode, der implementerer denne grundlæggende applikation. I denne kode omfatter en Device-klasseforekomst en metode, der opdaterer den simulerede temperatur baseret på tilstanden for den simulerede ventilator. Hovedrutinen kalder metoden med en bestemt frekvens og sender dataene ved hjælp af en MQTT-forbindelsestjeneste, der leveres af Eclipse paho-mqtt Python MQTT-klientmodulet (post 1).

Copy
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!')

Post 1: Dette uddrag fra Google-eksempelapplikationen illustrerer, hvordan main-rutinen med jævne mellemrum opdaterer en Device-klasseforekomst, der gemmer den aktuelle værdi af den simulerede temperaturføler og stiller en metode til rådighed, der opdaterer værdien afhængigt af den simulerede ventilators tilstand. (Kodekilde: Google)

Til gengæld leverer en Server-klasseforekomst et modul, der opdaterer ventilatorens tilstand, afhængigt af hvilke temperaturdata der modtages fra Device-klasseforekomsten (post 2).

Copy
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

Post 2: I dette uddrag fra Google-applikationseksemplet leverer _update_device_config ()-metoden, der er defineret i Server -klassen, virksomhedslogikken til applikationen, og indstiller ventilatortilstanden til "on", når temperaturen stiger til over en defineret værdi, og "off", når temperaturen falder. (Kodekilde: Google)

Ud over Googles eksempelkode kan udviklere finde massevis af open-source simulatorer til IoT-enheder, systemer og netværk i lagre som f.eks. GitHub. F.eks. omfatter Microsofts open-source Raspberry Pi-systemsimulatorkode forhåndsindbygget integration til Azure IoT Hub med henblik på hurtig udvikling af skybaserede applikationer, der kommunikerer med Raspberry Pi-kort. Desuden understøtter programmeringsværktøjer med lavt behov for kode som forudkonstruerede Node-RED-moduler (noder) til at levere simulerede sensordata til de førende skyplatformbaserede IoT-tjenestegrænseflader. Ved hjælp af disse tilgange kan udviklere nemt generere en strøm af sensordata.

Kørsel af simuleringer i stor skala

Vanskelighederne ved at bruge enhedsniveausimulatorer og relaterede værktøjer er, at håndtering af datasimuleringen kan blive et projekt i sig selv. Hvis du vil køre simulatorer, skal udviklerne klargøre og vedligeholde ressourcer som i alle applikationer. Hvad der er endnu vigtigere: De enhedsmodeller, der bruges til at generere realistiske data, bliver et separat projekt uden for IIoT-applikationsudviklingsprocessen. Efterhånden som udviklingen skrider frem, skal udviklerne sikre, at enhedsmodellerne fortsat er synkroniseret funktionelt med eventuelle ændringer i definitionen af IIoT-enhedsnetværket og applikationen. For professionelle IIoT-applikationer vil udviklere muligvis finde ud af, at skaleringen af disse simuleringer i bedste tilfælde kan være vanskelig – og sågar begynde at trække på de ressourcer, der er nødvendige for at udvikle applikationen.

De største udbydere af IoT-skyplatforme løser disse problemer med IoT-enhedssimuleringsløsninger, der er designet til at skalere lige så nemt som andre skyressourcer på deres respektive platforme. AWS IoT Device Simulator har f.eks. en AWS-skabelon til sin CloudFormation-konfigurationstjeneste, som implementerer et virtuelt privat netværk, der forbinder mikrotjenester implementeret i beholdere, der kører på den serverfri AWS Fargate-platform (figur 5).

Figur 5: AWS IOT Device Simulator kombinerer flere AWS-tjenester for at levere en skalerbar strøm af enhedsdata til den samme AWS IoT Core, der bruges af fysiske enheder. (Billedkilde: Amazon Web Services)

Udviklere får adgang til simuleringen interaktivt via en grafisk brugergrænsefladekonsol (GUI-konsol), der kører i Amazon S3-tjenesten, eller programmatisk via IoT Device Simulators API'en (Application Programming Interface), der genereres af CloudFormation-skabelonen i Amazon API Gateway-tjenesten. Under en simuleringskørsel trækker IoT Device Simulator-mikrotjenesten enhedskonfigurationer fra Amazon DynamoDB NoSQL-databasen i overensstemmelse med en samlet simuleringsplan, der er beskrevet i sit eget konfigurationselement.

Enhedskonfigurationerne er JSON-poster, der definerer enhedsattributnavne (f.eks. temperatur), værdiintervaller (-40 til 85 f.eks.) og opdaterer bl.a. enhedsinterval og simuleringens varighed. Udviklere kan tilføje enhedstyper interaktivt via konsollen eller programmatisk via API'en. Ved hjælp af normale DevOps-metoder kan enhedstyperne, konfigurationen og infrastrukturen hurtigt skaleres for at opnå de ønskede dataopdateringsfrekvenser for AWS IoT Core og downstream-applikationen.

I Azure Device Simulator kan udviklere yderligere supplere den grundlæggende liste over attributter med et sæt funktionsmåder, der understøttes af enheden under simuleringskørslen, samt et sæt metoder, som skyapplikationen kan kalde direkte.

Digitale tvillinger

Denne form for simulering af enhedsdata er konceptuelt tæt knyttet med digital tvilling-funktioner, der dukker op i kommercielle IoT-skyplatforme. I modsætning til enhedsskygger, der typisk kun giver en statisk gengivelse af enhedstilstanden, bruger digitale tvillinger en virtuel enhedsmodel, der matcher både den fysiske enhedstilstand og dens adfærd.

I Microsoft Azure gør Azure Digital Twins-tjenesten det muligt for udviklere at inkludere brugerdefinerede funktioner for at definere adfærd under en enhedssimulering, mens der stadig sendes resultater til Azure IoT Hub som tidligere. Uanset om de er simulerede eller ægte, sendes de indgående data derefter til en hændelsesroutingtjeneste med henblik på yderligere distribution i applikationen. Microsoft bruger også de digitale tvillingedata til at oprette rumlige grafer, der skildrer samspillet og tilstanden blandt elementer i komplekse hierarkiske miljøer, som f.eks. et industriautomatiseringssystem, der omfatter flere netværk (figur 6).

Figur 6: Tjenesten Microsoft Azure Digital Twins giver udviklere mulighed for at bygge virtuelle enheder, der matcher deres fysiske modstykker mht. funktioner og egenskaber og udgør fundamentet for sofistikerede tjenester som rumlige grafer over komplekse IIoT-hierarkier. (Billedkilde: Microsoft)

For IIoT-applikationer kan digitale tvillinger være en effektiv mekanisme til at understøtte hele livscyklussen for applikationer, der er bygget op omkring disse funktioner. På tidlige udviklingsstadier kan digitale tvillinger køres på omfattende vis af platformens enhedssimuleringstjenester. Når fysiske IIoT-netværk kommer online, kan de simulerede datakilder til den digitale tvilling udskiftes med enhedsdata-tilførsler. Senere kan udviklere i en fuldt udrullet IIoT-applikation bruge evt. forskelle, der findes mellem en fysisk enhed og dens digitale tvilling, som yderligere input til proaktive vedligeholdelsesalgoritmer eller registrering af brud på sikkerheden, f.eks. I hele livscyklussen kan digitale tvillinger beskytte applikationen mod netværksudfald eller betydelige ændringer i konfigurationen af IIoT-enhedsnetværk.

Fremkomsten af digitale tvillinger i IoT-platforme giver også en sekundær fordel i form af en standardiseret metode til at beskrive enhedsmodelegenskaber og -adfærd. Som beskrivelsessprog bruger Microsoft Azure Digital Twins-tjenesten JSON-LD (JavaScript Object Notation for Linked Data). JSON-LD er understøttet af World Wide Web Consortium (W3C) og fungerer som et standardformat til serialisering af sammenkædede data baseret på JSON-formatet, der er branchestandarden og allerede i brug i en række andre applikationssegmenter.

Standardiserede digitale tvillingebeskrivelser kan yderligere accelerere udviklingen med fremkomsten af depoter af forhåndsbyggede digitale tvillingebeskrivelser til sensorer og aktuatorer. For eksempel stiller Bosch allerede open-source digital tvilling-beskrivelser for flere af deres sensorer til rådighed skrevet i Eclipse Vorto-sproget og udgivet i Eclipse Vorto-lageret. Eclipse Vorto-sproget bruger grammatik, der er velkendt for de fleste programmører, og fungerer som en enkel metode til at beskrive modeller og grænseflader til digitale tvillinger. Senere kan udviklere konvertere deres beskrivelser baseret på Vorto-sproget til JSON-LD eller andre formater efter behov.

Udbygning af IIoT-applikationen

Uanset om de er bygget med diskrete simulatorer eller mikroservice-orienterede platforme, er enhedsdatasimuleringer en effektiv softwarebaseret løsning til at accelerere applikationsudvikling. For IIoT-applikationer, der anvender flere enhedsnetværk, kan migrering af enhedssimuleringer til kanten (edge) bidrage til at lette overgangen til udrulning – uden at gå på kompromis med behovet for repræsentative data tidligt i applikationsudviklingen.

Edge computing-systemer spiller en stadig vigtigere rolle i omfattende IoT-applikationer. Disse systemer leverer lokale ressourcer, der er nødvendige for nye behov, lige fra grundlæggende dataforbehandling for at reducere mængden af data, der når ud i skyen, til avancerede klassificeringsfunktioner såsom inferensmodeller for maskinlæring. Edge computing-systemer spiller også en mere grundlæggende rolle som kommunikations-gateways mellem field area-enhedsnetværk og højhastigheds backhaul-netværk.

Gateways som f.eks. Multi-Tech Systems' programmerbare MultiConnect Conduit-familie tilvejebringer platforme, der kombinerer kommunikationsunderstøttelse med edge-behandlingsfunktioner. Multi-Tech MTCAP-915-001A til 915-MHz-regioner og MTCAP-868-001A til 868-MHz-regioner giver LoRaWAN-forbindelse til aggregering af FAN-enhedsdata (Field Area Network) og Ethernet eller 4G-LTE-forbindelse på skysiden. Disse platforme, der er baseret på open-source Multi-Tech Linux (mLinux)-operativsystemet, giver også et velkendt udviklingsmiljø til at køre enhedssimuleringer. Når separate feltnetværk kommer online med fysiske sensorer og andre enheder, kan hver enhed vende tilbage til sin rolle som kommunikations-gateway og omdirigere behandlingsarbejdet til andre krav som dataforbehandling.

Konklusion

IIoT-applikationer udgør betydelige udfordringer for udrulning af sensornetværk i felten og udvikling af skybaseret applikationssoftware, der kan omdanne sensordata til brugbare resultater. Den gensidige afhængighed af sensornetværk og applikationssoftware kan medføre, at udviklingen standser, mens sensorudrulningen og softwareimplementeringen venter på, at hverandre når et niveau, der kan betegnes som kritisk masse.

Som vist kan udviklere løse denne hårdknude og accelerere IIoT-applikationsudviklingen ved at simulere datastrømme på realistiske niveauer for volumen, hastighed og variation.