Accelerera applikationsutveckling för industriellt IoT – del 1: simulera enhetsdata för IoT

Redaktörens anmärkning: Projekt inom inbäddad applikationsutveckling blir ofta fördröjda eftersom utvecklare får vänta på tillfälle att implementera hårdvara för nya enheter. Inom applikationsutveckling för det industriella sakernas internet (IIoT) finns liknande flaskhalsar, där man får vänta på nödvändig sensordata för applikationer, som exempelvis industrisystem för förebyggande underhåll eller automatiseringssystem för anläggningar baserade på maskininlärningsmetoder. I denna tvådelade serie tar vi en närmare titt på de olika alternativen att tillhandahålla de tidiga dataströmmar som behövs för att kunna accelerera applikationsutveckling inom IIoT. Här i del 1 går vi igenom simuleringsmetoder för generering av dessa dataströmmar. I del 2 tittar vi på alternativ för snabb prototypkonstruktion av sensorsystem för generering av data.

Vid storskaliga tillämpningar inom det industriella sakernas internet (IIoT) finns det många utmaningar som kan påverka distributionen negativt, vilket gör att företag blir osäkra på eventuell avkastning på sin investering för alla de resurser som krävs för implementering. För att förhindra sådana situationer och hjälpa utvecklare att snabbare kunna fastställa fördelarna med en IIoT-installation krävs det åtkomst till data för användningssimulering.

Genom att använda simuleringsmetoder för generering av realistiska dataströmmar kan utvecklare börja applikationsutveckling för IIoT långt innan IoT-nätverket distribuerats och även förfina definitionen för själva IIoT-sensornätverket.

I denna artikel kommer vi att visa hur de olika IoT-molnplattformarna kan tillhandahålla datasimulering, och vi kommer att presentera gateways från Multi-Tech Systems Inc. som ytterligare kan snabba på distributionen.

Fördelar med att simulera IIoT-data

Användning av simulerad data för att driva utveckling av applikationer och system är allt annat än en ny företeelse. Utvecklare har använt simuleringsmetoder på systemnivå i årtionden för att stresstesta databeräkningsinfrastrukturer och konnektivitetstjänster. Dessa tester fyller en viktig funktion när det gäller att säkerställa robusthet för statiska konfigurationer. I molntjänstplattformar är dessa tester en ganska enkel metod för att verifiera autoskalning för virtuella maskiner och andra molnresurser.

Vid IIoT-tillämpningar finns både dessa och andra behov. Förutom att fungera som hjälp vid belastningstest och autoskalning är datasimulering ett viktigt verktyg för att kunna verifiera integrering av de många olika tjänster och resurser som behövs för att implementera programvara med komplexiteten hos en IIoT-applikation för företag. Förutom dessa fundamentala användningar kan datasimulering snabba på utveckling av komplexa IIoT-applikationer byggda på sofistikerade tjänsteplattformar från ledande molnleverantörer.

Ur ett programvaruperspektiv

IIoT-applikationer körs på komplexa arkitekturer som ser ut på ett helt annat sätt för utvecklare av applikationsmjukvara än för systemutvecklare av sensorer och styrdon. För den senare gruppen innebär en storskalig IIoT-arkitektur många sensorer och styrdon som är uppkopplade på fysiska processer som ingår i den övergripande applikationen. För utvecklare av applikationsmjukvara innehåller en IIoT-arkitektur för företag ett antal tjänster vilkas koordinerade aktivitet tillsammans utgör applikationens funktion.

Microsoft Azures referensarkitektur för IoT ger en representativ bild över typiska IIoT-applikationer (och IoT-applikationer i allmänhet) inom applikationsmjukvara. Detta sammanfattar de många olika funktionella tjänster som en typisk applikation knyter samman i molnet för att leverera insikter och åtgärder baserat på data från slutpunkter och enheter i molnkanten (figur 1).

Figur 1: Microsoft Azures referensarkitektur för IoT illustrerar de många olika typer av molntjänster och resurser som en IIoT-applikation typiskt kräver för att leverera användbara insikter och åtgärder från data genererad av perifera enhetsnätverk. (Bildkälla: Microsoft Corp.)

Specifika applikationslösningar använder dessa molnresurser i lämpliga kombinationer, funktionellt anslutna genom standardiserade utbytesmekanismer och koordinerade av applikationslogik. I sin uppkopplade fordonslösning visar till exempel Amazon Web Services (AWS) hur molntjänster kan blandas och matchas i moduler som tillhandahåller applikationens olika funktioner (figur 2).

Figur 2: Den AWS-anslutna fordonslösningen ger en representativ bild över en typisk storskalig IoT-applikations arrangemang av molntjänster för att leverera nödvändig funktionsförmåga. (Bildkälla: Amazon Web Services)

Precis som dessa arkitekturrepresentationer visar är all den programvaruutveckling som krävs för att skapa en IIoT-applikation lika utmanande och dyr som implementering av perifera nätverk med sensorer och styrdon. Få organisationer har råd att fördröja utveckling av denna komplexa programvara tills enhetsnätverket kan generera tillräcklig datamängd. Det är faktiskt så att distribution av enhetsnätverk kan behöva vänta på ytterligare definition och förbättring som kan komma i samband med att analysspecialister och maskininlärningsexperter börjar arbeta med applikationsresultaten. I värsta fall blockeras både distribution av nätverk av fysiska enheter och programvaruutvecklingen, då var och en är beroende av resultat från den andra parten.

Det positiva är att lösningen på detta dilemma ligger i IoT-arkitekturen. Förutom en viss övergripande likhet, skiljer sig förstås ovanstående molntjänstarkitekturer från Microsoft och AWS på detaljnivå. Hur som helst visar alla en liknande arkitekturfunktion som typiskt sett förekommer i IoT-molnplattformar – en väldefinierad gränssnittstjänstmodul eller -lagerfunktion som separerar IoT-enhetens perifera nätverk från den molnbaserade programvaran. Förutom att tillhandahålla enhetlig konnektivitet är dessa gränssnittstjänster vitala för enhetshantering och säkerhet, liksom för andra funktioner som krävs i storskaliga IIoT-tillämpningar.

I Microsoft Azure-molnet kallas denna gränssnittstjänst Azure IoT Hub (se figur 1). I AWS-molnet kallas det AWS IoT Core (se figur 2). I Google Cloud Platform kallas detta gränssnitt Cloud IoT Core och i IBM Cloud kallas det IBM Watson IoT Platform. Andra plattformar som ThingWorx IoT Platform ansluter på samma sätt med hjälp av konnektivitetstjänster som ThingWorx Edge Microserver, ThingWorx Kepware Server eller verktygssatser för protokolladapter. Sammanfattningsvis kan sägas att alla molnplattformar måste tillhandahålla en konsekvent gränssnittstjänst som överför perifer data till molntjänster, annars riskeras att man får en härva av anslutningar från perifera enheter direkt till enskilda resurser djupt inne i molnet.

Inmatning av simulerad data

Genom att använda varje IoT-plattforms programvaruutvecklingssats (SDK) kan utvecklare mata in simulerad sensordata direkt i plattformens gränssnittstjänst på den nivå för volym, hastighet och variation som krävs för att verifiera applikationens funktion och prestanda. Simulerad data genererad vid önskad frekvens och upplösning når gränssnittstjänsten med standardprotokoll, som exempelvis MQ Telemetry Transport (MQTT) och Constrained Application Protocol (CoAP). För gränssnittstjänsten (och applikationsmjukvara nedströms) går simulerade dataströmmar inte att skilja från data som hämtats av hårdvarans sensorsystem. När enhetsnätverk är redo att aktiveras ersätter dessas sensordataströmmar helt enkelt de simulerade dataströmmar som når gränssnittstjänsten.

Molnplattformsleverantörer tillhandahåller vanligtvis support för denna typ av datasimulering med olika kapacitetsnivåer. Exempelvis har Google en enkel simuleringsdriven applikation med referensarkitektur och exempelkod som implementerar en enkel styrkrets för en temperaturreglerad fläkt. Precis som den arkitektur som illustrerades tidigare, använder denna arkitektur Google Cloud Platform-tjänster från Google Cloud IoT Core-tjänstens gränssnitt (figur 3).

Figur 3: I alla IoT-molnplattformer använder enhetssimulatorer samma kommunikationsprotokoll som används av fysiska enheter för att mata data till en gränssnittstjänst som Google Cloud IoT Core för Google Cloud Platforms applikationsarkitektur som visas här. (Bildkälla: Google)

I denna exempelapplikation genererar enhetssimulatorer för temperatursensorer data vid valt uppdateringsintervall och skickar data vidare till gränssnittstjänsten Google Cloud IoT Core med meddelandeprotokollet MQTT. Och den gränssnittstjänsten använder i sin tur plattformens standardprotokoll för publicera-prenumerera (pub/sub) för att överföra data till simulerad server, vilken svarar med ett kommando som startar eller stänger av fläkten (beroende på behov) (figur 4).

Figur 4: En exempelapplikation från Google demonstrerar en grundläggande styrkrets som består av en simulerad enhet som skickar data via Google Cloud IoT Core till en simulerad server med konventionella kommunikationsmetoder. (Bildkälla: Google)

Google erbjuder prov-Python-kod som implementerar denna grundläggande applikation. I denna kod innehåller en enhetsklassinstans en metod som uppdaterar simulerad temperatur baserat på status för simulerad fläkt. Huvudrutinen anropar den metoden vid en specificerad frekvens och skickar data med en MQTT-anslutningstjänst som tillhandahålls av Eclipse paho-mqtt Python MQTT-klientmodulen (lista 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!') 

Lista 1: Detta kodavsnitt från Googles exempelapplikation illustrerar hur huvudrutinen periodiskt uppdaterar en enhetsklassinstans som lagrar aktuellt värde för simulerad temperaturgivare och tillhandahåller en metod som uppdaterar det värdet beroende på status för simulerad fläkt. (Bildkälla: Google)

En serverklassinstans tillhandahåller i sin tur en modul som uppdaterar fläktens status baserat på temperaturdata som tas emot från enhetsklassinstansen (lista 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 

Lista 2: I detta kodavsnitt från Googles provapplikation tillhandahåller metoden _update_device_config() som definieras i klassen Server applikationens transaktionslogik, den ställer in fläktstatus till PÅ när temperaturen stiger över ett fastställt värde och den ställer in fläktstatus till AV när den faller under fastställt värde. (Bildkälla: Google)

Förutom Googles exempelkod kan utvecklare hitta dussintals IoT-enheter, system och nätverkssimulatorer med öppen källkod i databaser som GitHub. Simulatorkoden med öppen källkod för Microsofts Raspberry Pi-system har färdig integration till Azure IoT Hub för snabb utveckling av molnbaserade applikationer som interagerar med Raspberry Pi-kort. Dessutom stöder mycket kodsnåla programmeringsverktyg, som Node-RED, färdiga moduler (noder) för matning av simulerad sensordata till den ledande molnplattformens IoT-tjänstgränssnitt. Med dessa kan utvecklare enkelt generera ett flöde med sensordata.

Storskalig simulering

Svårigheten att använda simulatorer och relaterade verktyg på enhetsnivå är att hantering av datasimulering kan bli ett projekt i sig. För att köra simulatorerna måste utvecklare tillhandahålla och underhålla resurser, precis som för alla applikationer. Vad som kan orsaka större problem är att de enhetsmodeller som används för att generera realistisk data blir ett separat projekt som inte ingår i applikationsutvecklingsprocessen för IIoT. Vartefter utvecklingen fortgår, måste utvecklare säkerställa att modellerna för de fysiska enheterna förblir funktionellt synkroniserade med eventuella ändringar i definitionen för IIoT-enhetsnätverket och -applikation. Vid IIoT-applikationer på företagsnivå kan utvecklarna - i bästa fall - stöta på svårigheter med att skala upp dessa simuleringar, och det kan till och med inkräkta på resurser som behövs för att utveckla applikationen.

De större leverantörerna av IoT-molnplattformar hanterar detta med simuleringslösningar för IoT-enheter avsedda att kunna skalas upp lika enkelt som andra molnresurser i deras respektive plattformar. AWS IoT Device Simulator har till exempel en AWS-mall för sin konfigurationstjänst CloudFormation, vilken använder ett virtuellt privat nätverk för att ansluta mikrotjänster som är implementerade i behållare som körs på den serverlösa motorn AWS Fargate (figur 5).

Figur 5: AWS IoT Device Simulator kombinerar flera AWS-tjänster för att leverera ett skalbart flöde med enhetsdata till samma AWS IoT Core som används av fysiska enheter. (Bildkälla: Amazon Web Services)

Utvecklare har åtkomst till simuleringen interaktivt via ett grafiskt användargränssnitt (GUI) som körs i tjänsten Amazon S3 eller programmässigt genom programmeringsgränssnittet (API) för IoT Device Simulator som genereras av CloudFormation-mallen i tjänsten Amazon API Gateway. Under en simuleringskörning hämtar mikrotjänsten IoT Device Simulator enhetskonfigurationer från databasen Amazon DynamoDB NoSQL enligt en övergripande simuleringsplan som beskrivs i dess eget konfigurationsobjekt.

Enhetskonfigurationerna är JSON-poster som bland annat definierar enhetens attributnamn (temperatur, exempelvis), intervall för värden (exempelvis −40 till +85) samt uppdaterar enhetsintervall och simuleringens längd. Utvecklare kan lägga till enhetstyper interaktivt via konsolen eller programmässigt med API. Genom att använda normala DevOps-metoder kan enhetstyper, konfiguration och infrastruktur snabbt skalas upp för att säkerställa önskad datauppdateringshastighet som når AWS IoT Core och applikationer nedströms.

I Azure-enhetssimulatorer kan utvecklare komplettera attributgrundlistan ytterligare, med en uppsättning beteenden som stöds av enheten under simuleringskörningen samt en uppsättning metoder som molnapplikationen kan anropa direkt.

Digitala tvillingar

Denna typ av datasimulering av enhetsdata har rent konceptuellt en nära koppling till kapacitet för digitala tvillingar i kommersiella IoT-molnplattformar. Till skillnad mot enhetsavbildningar som typiskt sett endast ger en statisk representation av enhetsstatusen, utvidgar digitala tvillingar en virtuell enhetsmodell som matchar den fysiska enhetens status och beteende.

I Microsofts Azure ger tjänsten Azure Digital Twins utvecklare möjlighet att implementera användardefinierade funktioner för att fastställa beteendet under enhetssimulering, samtidigt som den levererar resultat till Azure IoT Hub precis som tidigare. Oberoende av om det sker under simulering eller vid faktisk användning, skickas inkommande data till en händelseroutningstjänst för vidare distribution i applikationen. Microsoft använder också data för digitala tvillingar för att generera rumsliga grafer som avbildar interaktioner och status bland element i miljöer med komplex hierarki, som till exempel industriella automationssystem som innehåller flera nätverk (figur 6).

Figur 6: Med Microsofts tjänst Azure Digital Twins kan utvecklare bygga virtuella enheter som matchar deras fysiska motpart vad gäller funktioner och egenskaper och tillhandahåller fundamentet för sofistikerade tjänster, som rumsliga grafer av komplexa IIoT-hierarkier. (Bildkälla: Microsoft)

För IIoT-applikationer kan digitala tvillingar vara en kraftfull mekanism under hela livscykeln för applikationer som byggs runt dessa kapaciteter. I tidiga utvecklingssteg kan digitala tvillingar köras i stor skala av plattformens enhetssimuleringstjänst. När fysiska IIoT-nätverk kommer online, kan de simulerade dataflöden till den digitala tvillingen ersättas med dataflöden tll den fysiska enheten. Senare kan utvecklare i en helt distribuerad IIoT-applikation, använda eventuella skillnader mellan en fysisk enhet och dess digitala tvilling som ytterligare indata för, exempelvis, algoritmer för förebyggande underhåll eller detektorer för säkerhetsintrång. Under livscykeln kan digitala tvillingar skydda applikationen mot nätverksbortfall eller avsevärda förändringar i konfiguration för IIoT-enhetsnätverk.

När digitala tvillingar börjar användas i IoT-plattformar uppnås en sekundär fördel, nämligen ett standardiserat förhållningssätt att beskriva enhetsmodulens attribut och beteende. Som beskrivningsspråk använder Microsofts tjänst Azure Digital Twins JSON-LD (JavaScript Object Notation for Linked Data). JSON-LD – som backas upp av W3C (World Wide Web Consortium) – tillhandahåller ett standardformat för serialisering av länkad data baserat på branschstandardformatet JSON, vilket redan används i flera olika applikationssegment.

Standardiserade beskrivningar för digitala tvillingar kan ytterligare öka utvecklingstakten för databaser som innehåller färdiga beskrivningar för digitala tvillingar för sensorer och styrdon. Exempelvis tillhandahåller Bosch redan beskrivningar för digitala tvillingar med öppen källkod för flera av sina sensorer skrivna på språket Eclipse Vorto och publicerade i Eclipse Vorto-databasen. Språket Eclipse Vorto använder grammatik som de flesta programmerare är bekanta med, vilket gör det till en enkel metod för beskrivning av modeller och gränssnitt för digitala tvillingar. I ett senare skede kan utvecklare omvandla sina Vorto-språkbeskrivningar till JSON-LD eller andra format som behövs.

Bygga ut IIoT-applikationen

Oavsett om det är uppbyggt med diskreta plattformar med simulatorer eller mikrotjänster, är datasimulering av enhetsdata en effektiv programvarubaserad lösning för snabbare applikationsutveckling. För IIoT-applikationer som använder flera enhetsnätverk kan migrering av enhetssimuleringar till kanten ytterligare underlätta övergång till distribution utan att flödet av representativ data tidigt i applikationsutvecklingen äventyras.

Edge computing-system spelar en allt viktigare roll i storskaliga IoT-applikationer. Dessa system tillhandahåller de lokala resurser som behövs för uppkommande krav, från förbearbetning av grundläggande data till att reducera den mängd data som når molnet till avancerade klassificeringsfunktioner som slutledningsmodeller för maskininlärning. Edge computing-system spelar också en viktigare roll som kommunikationsgateway mellan enhetsnätverk för fältnätverk och snabba backhaul-nätverk.

Gateways som Multi-Tech Systems programmerbara MultiConnect Conduit-familj tillhandahåller plattformar som kombinerar kommunikationssupport med kapacitet för databehandling i molnkanten. Multi-Tech MTCAP-915-001A för 915 MHz-området och MTCAP-868-001A för 868 MHz-området tillhandahåller LoRaWAN-konnektivitet för sammanställning av enhetsdata från ett fältnätverk (FAN), samt Ethernet- eller 4G-LTE-konnektivitet på molnsidan. Då dessa plattformar bygger på operativsystemet Multi-Tech Linux (mLinux) med öppen källkod, är de en bekant utvecklingsmiljö för att genomföra enhetssimuleringar. När separata fältnätverk används online med fysiska sensorer och andra enheter kan varje enhet återgå till sin roll som kommunikationsgateway och använda sina resurser för behov som databehandling.

Slutsats

IIoT-applikationer betyder avsevärda utmaningar när det gäller distribution av sensornätverk i fältet och vid utveckling av molnbaserad applikationsmjukvara som kan omvandla sensordata till användbara resultat. Det inbördes beroendet mellan sensornätverk och applikationsmjukvara kan leda till problem vid utveckling när sensordistribution och programvaruimplementering väntar på varandra för att uppnå en tillräcklig kritisk massa.

Som vi har sett kan utvecklare bryta detta dödläge och snabba upp applikationsutvecklingen inom IIoT genom att simulera dataströmmar vid realistisk volym, hastighet och variation.