Versnel de ontwikkeling van industriële ivd-toepassingen - Deel 1: Simulatie van ivd-apparaatgegevens

Notitie van de redacteur: Embedded applicatieontwikkelingsprojecten worden vaak vertraagd als ontwikkelaars wachten op de beschikbaarheid van hardware-implementaties van nieuwe apparaten. De ontwikkeling van industriële Internet of Things (IIoT)-applicaties wordt geconfronteerd met een soortgelijk knelpunt, in afwachting van de sensorgegevens die nodig zijn voor toepassingen zoals industriële voorspellende onderhoudssystemen of systemen voor de automatisering van faciliteiten op basis van machine learning-methoden. Deze tweedelige serie onderzoekt alternatieven voor het leveren van vroege datastromen die nodig zijn om de ontwikkeling van IIoT-toepassingen te versnellen. Hier beschrijft deel 1 het gebruik van simulatiemethoden voor het genereren van die datastromen. Deel 2 bespreekt de mogelijkheden voor het snel maken van prototypes van sensorsystemen voor het genereren van data.

Grootschalige industriële Internet of Things (IIoT)-toepassingen brengen meerdere uitdagingen met zich mee die de inzet ervan kunnen afremmen en waardoor bedrijven zich afvragen wat het rendement is van de investeringen in de vele middelen die nodig zijn voor de implementatie. Om dergelijke situaties te voorkomen en ontwikkelaars te helpen sneller de voordelen van de inzet van het IIoT te achterhalen, is het noodzakelijk dat er klaarblijkelijk toegang is tot de gegevens voor de simulatie van de inzet.

Met behulp van simulatiemethoden om realistische datastromen te genereren, kunnen ontwikkelaars ruim voor de uitrol van het IoT-netwerk beginnen met de ontwikkeling van IIoT-toepassingen en zelfs de definitie van het IIoT-sensornetwerk zelf verfijnen.

Dit artikel laat zien hoe de verschillende IoT-cloudplatformen zorgen voor datasimulatie en introduceert voorbeeldgateways van Multi-Tech Systems Inc. die de implementatie verder kunnen versnellen.

Het geval voor het simuleren van IIoT-data

Het gebruik van gesimuleerde data voor het aansturen van applicaties en systeemontwikkeling is natuurlijk niet nieuw. Ontwikkelaars gebruiken al decennia lang simulatiemethoden op systeemniveau om computerinfrastructuren en connectiviteitsdiensten te testen. Deze tests dienen een belangrijke functie bij het controleren van de robuustheid van statische configuraties. In cloudserviceplatforms bieden deze tests een relatief eenvoudige methode om het automatisch opschalen van virtuele machines en andere cloudbronnen te verifiëren.

IIoT-toepassingen hebben dezelfde eisen en meer. Naast hulp bij het testen van de belasting en het automatisch opschalen, biedt datasimulatie een belangrijk hulpmiddel voor het verifiëren van de integratie van de vele uiteenlopende diensten en middelen die nodig zijn om software te implementeren die zo complex is als een IIoT-toepassing op bedrijfsniveau. Afgezien van die meer fundamentele praktijken, kan datasimulatie de ontwikkeling van complexe IIoT-applicaties versnellen die zijn gebouwd op de geavanceerde serviceplatforms die beschikbaar zijn bij toonaangevende cloudproviders.

Softwarematig perspectief

IIoT-toepassingen werken op complexe architecturen die er aanzienlijk anders uitzien voor ontwikkelaars van toepassingssoftware dan voor ontwikkelaars van sensoren en actuators. Voor de laatste is een grootschalige IIoT-architectuur een enorme verzameling sensors en actuators die communiceren met de fysieke processen die het onderwerp zijn van de algehele toepassing. Voor ontwikkelaars van applicatiesoftware omvat een IIoT-architectuur op bedrijfsniveau een aantal diensten waarvan de gecoördineerde activiteit uiteindelijk de functionaliteit van de applicatie levert.

De Microsoft Azure IoT referentie-architectuur biedt een representatief beeld van typische IIoT-toepassingen (en IoT-toepassingen in het algemeen) vanuit het perspectief van de applicatiesoftware. Deze zienswijze vat de meerdere functionele diensten samen die een typische applicatie in de cloud aan elkaar breidt om inzichten en acties te leveren op basis van gegevens van het eindpunt en de randapparatuur in de periferie (Afbeelding 1).

Afbeelding 1: De Microsoft Azure IoT referentie-architectuur illustreert de verschillende soorten cloud-diensten en -bronnen die een IIoT-toepassing gewoonlijk nodig heeft om nuttige inzichten en actie te leveren op basis van gegevens die worden gegenereerd door de netwerken van apparaten in de periferie. (Bron afbeelding: Microsoft Corp.)

Specifieke applicatieoplossingen zetten deze cloud-resources in passende combinaties in, zijn functioneel met elkaar verbonden via gestandaardiseerde uitwisselingsmechanismen en worden gecoördineerd door applicatielogica. In de connected vehicle-oplossing suggereert Amazon Web Services (AWS) bijvoorbeeld hoe cloudservices kunnen worden gecombineerd en gematcht in modules die verantwoordelijk zijn voor het bieden van verschillende functies en mogelijkheden van de applicatie (Afbeelding 2).

Afbeelding 2: De met AWS verbonden voertuigoplossing biedt een representatief beeld van de orkestratie van de clouddiensten van een typische grootschalige IoT-toepassing om de benodigde functionele mogelijkheden te leveren. (Bron afbeelding: Amazon Web Services)

Zoals deze architecturale representaties suggereren, is de softwareontwikkeling die nodig is om een IIoT-toepassing te creëren net zo uitdagend en uitgebreid als het implementeren van perifere netwerken van sensor- en actuatorsystemen. Weinig organisaties kunnen het zich veroorloven om de ontwikkeling van deze complexe software uit te stellen totdat het apparaatnetwerk in staat is om voldoende gegevens te genereren. Het kan zelfs zijn dat de uitrol van het apparaatnetwerk moet wachten op verdere definitie en verfijning die kan ontstaan wanneer analysespecialisten en machine learning-experts beginnen te werken met applicatieresultaten. In het ergste geval zitten de inzet van het apparaatnetwerk en de softwareontwikkeling in een impasse: ze zijn elk afhankelijk van de resultaten van de andere.

Gelukkig ligt de oplossing voor dit dilemma in de aard van de IoT-architectuur. Naast enige brede gelijkenis, verschillen cloudservice-architecturen zoals hierboven geïllustreerd van Microsoft en AWS natuurlijk in detail. Desalniettemin tonen ze allemaal een soortgelijk architectonisch kenmerk dat typisch is voor de IoT-cloudplatformen: Een goed gedefinieerde interface-dienstmodule of laagfunctionaliteit die het perifere netwerk van IoT-apparaten scheidt van de cloud-gebaseerde softwaretoepassing. Naast het bieden van een uniforme connectiviteit, zijn deze interface diensten van vitaal belang voor het beheer en de beveiliging van apparaten en andere belangrijke mogelijkheden die nodig zijn in grootschalige IIoT-toepassingen.

In de Microsoft Azure cloud heet deze interface dienst Azure IoT Hub (zie Afbeelding 1); in de AWS cloud is het AWS IoT Core (zie Afbeelding 2). In het Google Cloud Platform is deze interface de Cloud IoT Core, en in de IBM Cloud is het de IBM Watson IoT Platform Service. Andere platforms zoals ThingWorx IoT Platform maken op dezelfde manier verbinding via connectiviteitsservices zoals ThingWorx Edge Microserver, ThingWorx Kepware Server of protocoladapter toolkits. Kortom, elk cloudplatform moet een consistente interfacedienst bieden die gegevens van de periferie naar cloudservices leidt of een verwarde wirwar van verbindingen van randapparatuur rechtstreeks naar individuele bronnen diep in de cloud riskeert.

Injecteren van gesimuleerde gegevens

Met behulp van de softwareontwikkelingskit (SDK) van elk IoT-platform kunnen ontwikkelaars gesimuleerde sensorgegevens rechtstreeks in de interface van het platform injecteren op de niveaus van volume, snelheid en variëteit die nodig zijn om de functionaliteit en prestaties van de toepassing te controleren. Gesimuleerde gegevens die met de gewenste snelheid en resolutie worden gegenereerd, bereiken de interfacedienst met behulp van standaardprotocollen zoals MQ Telemetry Transport (MQTT), Constrained Application Protocol (CoAP) en andere. Voor de interfacedienst (en downstream applicatiesoftware) zijn de gesimuleerde gegevensstromen niet te onderscheiden van gegevens die door een hardware-sensorsysteem worden verkregen. Wanneer de netwerken van apparaten klaar zijn om online te komen, vervangen hun sensor-datastromen eenvoudigweg de gesimuleerde datastromen die de interfacedienst bereiken.

Aanbieders van cloud-platforms ondersteunen deze benadering van datasimulatie doorgaans op verschillende niveaus van capaciteit. Google demonstreert bijvoorbeeld een eenvoudige simulatie-gestuurde applicatie met een referentie-architectuur en voorbeeldcode die een eenvoudige regelkring van een temperatuurgestuurde ventilator implementeert. Net als de eerder geïllustreerde architecturen maakt deze architectuur gebruik van de diensten van het Google Cloud Platform die worden gevoed door de Google Cloud IoT Core service interface (Afbeelding 3).

Afbeelding 3: In elk IoT-cloudplatform gebruiken apparaatsimulatoren dezelfde communicatieprotocollen die door fysieke apparaten worden gebruikt om gegevens aan een interfacedienst zoals de Google Cloud IoT Core voor de hier getoonde applicatiearchitectuur van het Google Cloud-platform toe te voegen. (Bron afbeelding: Google)

In deze voorbeeldtoepassing genereren gematigde sensorapparaatsimulators gegevens met een geselecteerde updatefrequentie en geven ze de gegevens door aan de Google Cloud IoT Core interface service met behulp van het MQTT-berichtenprotocol. Die interface-dienst gebruikt op zijn beurt de standaard publish-subscribe (pub/sub)-protocollen van het platform om de gegevens door te geven aan een gesimuleerde server, die reageert met een commando om de ventilator aan of uit te zetten als dat nodig is (Afbeelding 4).

Afbeelding 4: Een voorbeeld van een Google-applicatie toont een basisregelkring die bestaat uit een gesimuleerd apparaat dat gegevens via de Google Cloud IoT Core naar een gesimuleerde server stuurt met behulp van standaard communicatiemethoden. (Bron afbeelding: Google)

Google levert voorbeeld Python-code die deze basistoepassing implementeert. In deze code bevat een klasse-instantie van een apparaat een methode die de gesimuleerde temperatuur bijwerkt op basis van de status van de gesimuleerde ventilator. De hoofdroutinemethode roept die methode op tegen een bepaalde snelheid en stuurt de gegevens door met behulp van een MQTT-verbindingsservice van de Eclipse paho-mqtt Python MQTT-clientmodule (Lijst 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.         Als de ventilator aanstaat, neem dan aan dat de temperatuur één graad is gedaald,        anders neem je aan dat het één graad hoger is geworden.        """          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!') 

Lijst 1: Dit fragment uit de Google-voorbeeldtoepassing illustreert hoe de hoofdroutine periodiek een apparaat-class-instance update die de huidige waarde van de gesimuleerde temperatuursensor opslaat en een methode biedt die deze waarde bijwerkt afhankelijk van de toestand van de gesimuleerde ventilator. (Code bron: Google)

Een server-class instance biedt op zijn beurt een module die de ventilatorstatus bijwerkt afhankelijk van de temperatuurgegevens die worden ontvangen van de apparaat-class instance (Lijst 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 

Lijst 2: In dit fragment uit de Google voorbeeld applicatie, de _update_device_config()-methode gedefinieerd in de Server-klasse biedt de business logica voor de applicatie het instellen van de ventilatorstand op aan wanneer de temperatuur boven een gedefinieerde waarde stijgt, en het instellen van de ventilatorstand op uit wanneer deze daalt. (Code bron: Google)

Naast Google's voorbeeldcode kunnen ontwikkelaars tientallen open-source IoT-apparaten, systeem- en netwerksimulatoren vinden op opslagplaatsen zoals GitHub. Bijvoorbeeld, Microsoft's open-source Raspberry Pi systeem simulator code bevat een vooraf gebouwde integratie met de Azure IoT Hub voor een snelle ontwikkeling van cloud-gebaseerde applicaties die een interface hebben met Raspberry Pi borden. Daarnaast ondersteunen low-code programmeerhulpmiddelen zoals Node-RED vooraf gebouwde modules (nodes) voor het voeden van gesimuleerde sensordata aan de toonaangevende cloud platform IoT-service-interfaces. Met behulp van deze benaderingen kunnen ontwikkelaars gemakkelijk een stroom van sensordata genereren.

Simulaties op schaal uitvoeren

De moeilijkheid met het gebruik van device level simulators en gerelateerde tools is dat het beheer van de data-simulatie een project op zich kan worden. Om de simulators te laten draaien, moeten de ontwikkelaars middelen ter beschikking stellen en onderhouden, net als bij elke andere toepassing. Nog zorgwekkender is dat de apparaatmodellen die worden gebruikt om realistische gegevens te genereren, een afzonderlijk project worden buiten het ontwikkelingsproces van de IIoT-applicatie. Naarmate de ontwikkeling vordert, moeten de ontwikkelaars ervoor zorgen dat de apparaatmodellen functioneel gesynchroniseerd blijven met eventuele wijzigingen in de definitie van het IIoT-apparaatnetwerk en de -toepassing. Voor IIoT-toepassingen op bedrijfsniveau kunnen ontwikkelaars ontdekken dat het schalen van deze simulaties op zijn best moeilijk kan zijn, en zelfs beginnen te putten uit bronnen die nodig zijn voor het ontwikkelen van de toepassing.

De belangrijkste aanbieders van IoT-cloudplatformen pakken deze problemen aan met IoT-apparaatsimulatie-oplossingen die zijn ontworpen om net zo gemakkelijk te schalen als andere cloudbronnen in hun respectieve platformen. De AWS IoT Device Simulator biedt bijvoorbeeld een AWS-sjabloon voor de CloudFormation-configuratiedienst, die een virtueel privé-netwerk gebruikt om microservices te verbinden die in containers op de AWS Fargate-engine zonder server zijn geïmplementeerd (Afbeelding 5).

Afbeelding 5: De AWS IoT Device Simulator combineert meerdere AWS-services om een schaalbare stroom van apparaatgegevens te leveren aan dezelfde AWS IoT Core die door fysieke apparaten wordt gebruikt. (Bron afbeelding: Amazon Web Services)

Ontwikkelaars hebben interactief toegang tot de simulatie via een grafische gebruikersinterface (GUI) die draait in de Amazon S3 service, of programmatisch via de IoT Device Simulator application programming interface (API) die wordt gegenereerd door de CloudFormation template in de Amazon API Gateway service. Tijdens een simulatierun haalt de IoT Device Simulator microservice apparaatconfiguraties uit de Amazon DynamoDB NoSQL-database in overeenstemming met een globaal simulatieplan dat in zijn eigen configuratie-item wordt beschreven.

De apparaatconfiguraties zijn JSON-records die de apparaatkenmerknamen (bijvoorbeeld temperatuur), waardenbereik (zeg maar -40 tot 85) definiëren, en apparaatinterval en simulatieduur updaten, naast andere informatie. Ontwikkelaars kunnen interactief apparaattypes toevoegen via de console of programmatisch via de API. Met behulp van normale DevOps-methoden kunnen de apparaattypes, de configuratie en de infrastructuur snel worden geschaald om de gewenste data-updatesnelheid te bereiken die de AWS IoT Core en de downstream-toepassing bereikt.

In de Azure-apparaatsimulator kunnen ontwikkelaars de basislijst van attributen verder aanvullen met een set van gedragingen die door het apparaat tijdens de simulatierun worden ondersteund, evenals een set van methoden die de cloudapplicatie direct kan oproepen.

Digitale tweeling

Dit soort datasimulatie van apparaten is conceptueel nauw verbonden met de digitale tweeledige mogelijkheden die in commerciële IoT-cloudplatforms ontstaan. In tegenstelling tot de schaduwen van apparaten die meestal slechts een statische weergave van de apparaatstatus geven, breiden digitale tweelingen een virtueel apparaatmodel uit om zowel de fysieke apparaatstatus als het gedrag ervan aan te passen.

In Microsoft's Azure, de Azure Digital Twins-dienst stelt ontwikkelaars in staat om gebruikers-gedefinieerde functies op te nemen om gedrag te definiëren tijdens een apparaatsimulatie, waarbij de resultaten nog steeds naar de Azure IoT Hub worden gevoerd zoals voorheen. Ongeacht of het gesimuleerde of echte gegevens zijn, de inkomende gegevens worden vervolgens verzonden naar een eventrouteringsdienst voor verdere distributie in de toepassing. Microsoft gebruikt de digitale tweelinggegevens ook om ruimtelijke grafieken te maken die de interacties en toestand tussen elementen in complexe hiërarchische omgevingen weergeven, zoals een industrieel automatiseringssysteem dat uit meerdere netwerken bestaat (Afbeelding 6).

Afbeelding 6: Met de Microsoft Azure Digital Twins-service kunnen ontwikkelaars virtuele apparaten bouwen die qua functies en mogelijkheden overeenkomen met hun fysieke tegenhangers en de basis vormen voor geavanceerde diensten zoals ruimtelijke grafieken van complexe IIoT-hiërarchieën. (Bron afbeelding: Microsoft)

Voor IIoT-toepassingen kan de digitale tweeling een krachtig mechanisme bieden dat in staat is om de hele levenscyclus van toepassingen die rond deze mogelijkheden zijn gebouwd, te ondersteunen. In een vroeg stadium van de ontwikkeling kan de digitale tweeling op schaal worden gedreven door de apparaatsimulatiediensten van het platform. Als fysieke IIoT-netwerken online komen, kunnen die gesimuleerde datafeeds naar de digitale tweeling worden vervangen door apparaat-datafeeds. Later, in een volledig ingezette IIoT-toepassing, kunnen ontwikkelaars eventuele verschillen tussen een fysiek apparaat en zijn digitale tweeling gebruiken als extra input voor bijvoorbeeld voorspellende onderhoudsalgoritmen of beveiligingsinbraakdetectoren. Gedurende de gehele levenscyclus kan de digitale tweeling de toepassing afschermen tegen netwerkstoringen of belangrijke wijzigingen in de configuratie van IIoT-apparaatnetwerken.

De opkomst van digitale tweelingen in IoT-platforms biedt ook een secundair voordeel door een gestandaardiseerde aanpak te bieden voor het beschrijven van de kenmerken en het gedrag van het apparaatmodel. Voor de beschrijvingstaal gebruikt Microsoft's Azure Digital Twins service de JSON-LD (JavaScript Object Notation for Linked Data). Ondersteund door het World Wide Web Consortium (W3C) biedt JSON-LD een standaardformaat voor het serialiseren van gekoppelde gegevens op basis van de industriestandaard JSON-formaat, dat al in gebruik is in een aantal andere applicatiesegmenten.

Gestandaardiseerde digitale tweelingbeschrijvingen kunnen de ontwikkeling verder versnellen met de opkomst van repositories van vooraf gebouwde digitale tweelingbeschrijvingen voor sensors en actuators. Bosch biedt bijvoorbeeld al open-source digitale tweelingbeschrijvingen van een aantal van zijn sensors aan, geschreven in de taal van het Eclipse Vorto en gepubliceerd in de Eclipse Vorto repository. Met behulp van een voor de meeste programmeurs bekende grammatica biedt de Eclipse Vorto taal een eenvoudige methode voor het beschrijven van modellen en interfaces voor digitale tweelingen. Later kunnen ontwikkelaars hun Vorto-taalbeschrijvingen naar behoefte omzetten naar JSON-LD of andere formaten.

De IIoT-toepassing uitbouwen

Of het nu met discrete simulators of microservicegerichte platforms is gebouwd, de datasimulatie van apparaten biedt een effectieve softwarematige oplossing voor het versnellen van de ontwikkeling van toepassingen. Voor IIoT-toepassingen die gebruik maken van meerdere apparaatnetwerken, kan de migratie van de apparaatsimulaties naar de rand helpen om de overgang naar de implementatie verder te vergemakkelijken zonder dat dit ten koste gaat van de behoefte aan representatieve gegevens in een vroeg stadium van de applicatieontwikkeling.

Randcomputers spelen een steeds belangrijkere rol in grootschalige IoT-toepassingen. Deze systemen bieden lokale middelen die nodig zijn voor opkomende eisen, variërend van het voorbewerken van basisgegevens om de hoeveelheid gegevens die de cloud bereiken te verminderen, tot geavanceerde classificatiemogelijkheden zoals gevolgmodellen voor machinaal leren. Randcomputers spelen ook een meer fundamentele rol als communicatiegateways tussen netwerken van veldapparatuur en snelle backhaul-netwerken.

Gateways zoals de programmeerbare MultiConnect Conduit-familie van de Multi-Tech Systems bieden platforms die communicatieondersteuning combineren met randprocessing-mogelijkheden. De Multi-Tech MTCAP-915-001A voor 915 megahertz (MHz) regio's en de MTCAP-868-001A voor 868 MHz regio's bieden LoRaWAN-connectiviteit voor het verzamelen van gegevens van veldnetwerkapparaten en Ethernet- of 4G-LTE-connectiviteit aan de cloudzijde. Gebaseerd op het open-source Multi-Tech Linux (mLinux)-besturingssysteem, bieden deze platforms ook een vertrouwde ontwikkelomgeving voor het uitvoeren van apparaatsimulaties. Aangezien afzonderlijke veldnetwerken online komen met fysieke sensoren en andere apparaten, kan elke eenheid terugkeren naar zijn rol als communicatiegateway, waarbij de verwerkingsinspanningen worden omgeleid naar vereisten zoals het voorbewerken van gegevens.

Conclusie

IIoT-toepassingen vormen belangrijke uitdagingen voor de inzet van sensornetwerken in het veld en de ontwikkeling van cloud-gebaseerde applicatiesoftware die in staat is om sensordata om te zetten in bruikbare resultaten. De wederzijdse afhankelijkheid van sensornetwerken en applicatiesoftware kan ervoor zorgen dat de ontwikkeling botst, terwijl de inzet van sensors en de implementatie van software op elkaar wachten om een voldoende niveau van kritische massa te bereiken.

Zoals aangetoond kunnen ontwikkelaars deze impasse doorbreken en de ontwikkeling van IIoT-toepassingen versnellen door datastromen te simuleren op een realistisch niveau van volume, snelheid en variëteit.