Accelerare lo sviluppo di applicazioni IoT - Parte 1: Simulazione dei dati di dispositivi IoT

Nota del redattore: i progetti di sviluppo di applicazioni embedded spesso subiscono ritardi perché gli sviluppatori attendono che si rendano disponibili le implementazioni hardware dei nuovi dispositivi. Lo sviluppo di applicazioni per Internet delle cose industriale (IIoT) si trova in un collo di bottiglia simile, in quanto deve attendere i necessari dati dei sensori per applicazioni come i sistemi di manutenzione predittiva industriale o i sistemi di automazione degli impianti basati su metodi di apprendimento automatico. Questa serie in due parti esplora le alternative per fornire i primi flussi di dati necessari per accelerare lo sviluppo di applicazioni IIoT. La Parte 1 descrive l'uso di metodi di simulazione per generare questi flussi di dati. La Parte 2 presenta le opzioni per prototipare rapidamente i sistemi di sensori per la generazione di dati.

Le applicazioni per Internet delle cose industriale (IIoT) su larga scala hanno insite svariate sfide che possono bloccare le implementazioni e indurre le aziende a interrogarsi sul ROI delle ingenti risorse necessarie per l'implementazione. Per evitare tali situazioni e aiutare gli sviluppatori ad accertare più rapidamente i vantaggi portati dall'implementazione di IIoT, occorre poter accedere subito ai dati di simulazione di un'implementazione.

Utilizzando metodi di simulazione per generare flussi di dati realistici, gli sviluppatori possono iniziare lo sviluppo di applicazioni IIoT molto prima che venga implementata la rete IoT e persino mettere a punto la definizione della rete stessa di sensori IIoT.

Questo articolo mostrerà come le varie piattaforme cloud IoT forniscono la simulazione dei dati e presenterà esempi di gateway di Multi-Tech Systems Inc. che possono accelerare ulteriormente l'implementazione.

Simulazione di dati IIoT

L'uso di dati simulati per guidare lo sviluppo delle applicazioni e dei sistemi non è certo una novità. Gli sviluppatori si servono da decenni di metodi di simulazione a livello di sistema per testare le infrastrutture di calcolo e i servizi di connettività. Questi test assolvono una funzione importante, verificando la robustezza delle configurazioni statiche. Nelle piattaforme di servizi cloud, i test forniscono un metodo relativamente semplice per verificare l'autoscalatura delle macchine virtuali e di altre risorse cloud.

Le applicazioni IIoT condividono questi stessi requisiti e molto altro. Oltre ad agevolare i test di carico e l'autoscalatura, la simulazione dei dati offre uno strumento importante per verificare l'integrazione dei numerosi servizi e delle varie risorse necessarie per implementare un software complesso come un'applicazione IIoT di livello aziendale. Al di là di queste pratiche più di base, la simulazione dei dati può accelerare lo sviluppo di applicazioni IIoT complesse basate sulle sofisticate piattaforme di servizi disponibili dai principali fornitori di cloud.

La prospettiva software

Le applicazioni IIoT operano su architetture complesse che vengono però percepite in modo molto diverso a seconda dell'osservatore: gli sviluppatori di software applicativo o gli sviluppatori di sistemi di sensori e attuatori. Per questi ultimi, un'architettura IIoT su larga scala è un vasto insieme di sensori e attuatori che si interfacciano con i processi fisici che interessano l'intera applicazione. Per gli sviluppatori di software applicativo, invece, un'architettura IIoT di livello aziendale comprende una serie di servizi la cui attività coordinata assicura, in ultima analisi, la funzionalità dell'applicazione.

L'architettura di riferimento IIoT di Microsoft Azure offre una vista rappresentativa delle tipiche applicazioni IIoT (e di quelle IoT in generale) dal punto di vista del software applicativo. Questa prospettiva riassume i molteplici servizi funzionali che una tipica applicazione ricongiunge nel cloud per fornire indicazioni e azioni basate su dati provenienti dai dispositivi endpoint e da quelli periferici (Figura 1).

Figura 1: L'architettura di riferimento IoT di Microsoft Azure illustra i numerosi tipi di servizi cloud e di risorse di cui un'applicazione IIoT ha in genere bisogno per fornire indicazioni e azioni basate sui dati generati dalle reti dei dispositivi alla periferia. (Immagine per gentile concessione di Microsoft Corp.)

Soluzioni applicative specifiche distribuiscono queste risorse cloud in combinazioni appropriate, collegate funzionalmente attraverso meccanismi di interscambio standardizzati e coordinate dalla logica dell'applicazione. Nella sua soluzione per veicoli connessi, ad esempio, Amazon Web Services (AWS) suggerisce come utilizzare congiuntamente più servizi cloud e abbinarli in moduli preposti a fornire diverse funzionalità e capacità dell'applicazione (Figura 2).

Figura 2: La soluzione di AWS per veicoli connessi offre una vista rappresentativa di una tipica orchestrazione di applicazioni IoT su larga scala dei servizi cloud per fornire le capacità funzionali richieste. (Immagine per gentile concessione di Amazon Web Services)

Come suggeriscono queste rappresentazioni architetturali, lo sforzo di sviluppo software necessario per creare un'applicazione IIoT presenta le stesse difficoltà e la stessa ampiezza dell'implementazione di reti periferiche di sistemi di sensori e attuatori. Poche organizzazioni possono permettersi di ritardare lo sviluppo di questo software complesso in attesa che la rete di dispositivi sia in grado di generare dati sufficienti. Di fatto, per l'implementazione della rete di dispositivi si potrebbe dover attendere ulteriori definizioni e messe a punto che possono venire alla luce quando gli specialisti di analisi e gli esperti di apprendimento automatico iniziano a lavorare con i risultati delle applicazioni. Nel peggiore dei casi, l'implementazione della rete di dispositivi e lo sviluppo del software si trovano in una situazione di stallo, in quanto ognuno dipende dai risultati dell'altro.

Fortunatamente, la soluzione a questo dilemma sta nella natura stessa delle architetture IoT. Al di là di alcune somiglianze generiche, le architetture di servizi cloud come quelle illustrate sopra da Microsoft e AWS si differenziano per i dettagli. Ciononostante, presentano tutte una caratteristica architettonica simile che contraddistingue in genere le piattaforme cloud IoT: un modulo di servizio di interfaccia ben definito o una funzionalità di livello che separa la rete periferica dei dispositivi IoT dall'applicazione software basata su cloud. Oltre a fornire una connettività uniforme, questi servizi di interfaccia sono vitali per la gestione dei dispositivi e per la sicurezza, nonché per altre capacità cruciali richieste nelle applicazioni IIoT su larga scala.

Nel cloud Microsoft Azure, questo servizio di interfaccia si chiama Hub IoT di Azure (fare riferimento anche in questo caso alla Figura 1); nel cloud AWS è AWS IoT Core (fare riferimento di nuovo alla Figura 2). In Google Cloud Platform, questa interfaccia è Cloud IoT Core, mentre in IBM Cloud è IBM Watson IoT Platform Service. Altre piattaforme come ThingWorx IoT Platform si collegano in modo simile attraverso servizi di connettività come ThingWorx Edge Microserver, ThingWorx Kepware Server o toolkit di adattatori di protocollo. In breve, qualsiasi piattaforma cloud deve fornire un servizio di interfaccia coerente che incanali i dati dalla periferia ai servizi cloud. Diversamente, si correrebbe il rischio di un groviglio confuso di connessioni da dispositivi periferici direttamente alle singole risorse presenti in profondità nel cloud.

Iniezione di dati simulati

Utilizzando il kit di sviluppo software (SDK) di ogni piattaforma IoT, gli sviluppatori possono iniettare i dati simulati dei sensori direttamente nel servizio di interfaccia della piattaforma ai livelli di volume, velocità e varietà richiesti per verificare la funzionalità e le prestazioni dell'applicazione. I dati simulati generati alla velocità e risoluzione desiderate raggiungono il servizio di interfaccia usando protocolli standard come MQ Telemetry Transport (MQTT), Constrained Application Protocol (CoAP) e altri. Per il servizio di interfaccia (e il software applicativo a valle), i flussi di dati simulati sono indistinguibili dai dati acquisiti da un sistema di sensori hardware. Quando le reti dei dispositivi sono pronte per essere messe online, i flussi di dati dei loro sensori sostituiscono semplicemente i flussi di dati simulati che arrivano al servizio di interfaccia.

I fornitori di piattaforme cloud in genere supportano questo approccio di simulazione dei dati a diversi livelli di capacità. Ad esempio, Google dimostra una semplice applicazione guidata dalla simulazione con un'architettura di riferimento e un codice campione che implementa un semplice anello di controllo di un ventilatore termoregolato. Come le architetture illustrate in precedenza, anche questa sfrutta i servizi di Google Cloud Platform alimentati dall'interfaccia del servizio Google Cloud IoT Core (Figura 3).

Figura 3: In qualsiasi piattaforma cloud IoT, i simulatori di dispositivi utilizzano gli stessi protocolli di comunicazione utilizzati dai dispositivi fisici per alimentare i dati a un servizio di interfaccia come Google Cloud IoT Core per l'architettura dell'applicazione Google Cloud Platform mostrata qui. (Immagine per gentile concessione di Google)

In questa applicazione di esempio, i simulatori di dispositivi con sensori della temperatura generano i dati alla frequenza di aggiornamento selezionata e li trasmettono al servizio di interfaccia Google Cloud IoT Core utilizzando il protocollo di messaggistica MQTT. A sua volta, questo servizio di interfaccia utilizza i protocolli standard publish-subscribe (pub/sub) della piattaforma per trasmettere i dati a un server simulato, che risponde con un comando per accendere o spegnere il ventilatore in base alle necessità (Figura 4).

Figura 4: Un'applicazione di esempio di Google dimostra un anello di controllo di base che comprende un dispositivo simulato che invia i dati attraverso Google Cloud IoT Core a un server simulato utilizzando metodi di comunicazione standard. (Immagine per gentile concessione di Google)

Google fornisce il codice Python di esempio che implementa questa applicazione di base. In questo codice, un'istanza di classe Device include un metodo che aggiorna la temperatura simulata sulla base dello stato del ventilatore simulato. La routine principale richiama quel metodo alla frequenza specificata e invia i dati utilizzando un servizio di connessione MQTT fornito dal modulo client MQTT paho-mqtt Python di Eclipse (Listato 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!')

Listato 1: Questo frammento dell'applicazione di esempio di Google illustra come la routine main aggiorna periodicamente un'istanza della classe Device che memorizza il valore corrente del sensore di temperatura simulato e fornisce un metodo che aggiorna quel valore in base allo stato del ventilatore simulato. (Codice per gentile concessione di Google)

A sua volta, un'istanza di classe Server fornisce un modulo che aggiorna lo stato del ventilatore in base ai dati della temperatura ricevuti dall'istanza della classe Device (Listato 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

Listato 2: In questo frammento tratto dall'applicazione di esempio di Google, il metodo _update_device_config() definito nella classe Server fornisce la logica aziendale per l'applicazione, impostando lo stato su ON quando la temperatura supera il valore specificato e su OFF quando scende al di sotto. (Codice per gentile concessione di Google)

Oltre al codice di esempio di Google, gli sviluppatori possono trovare decine di dispositivi IoT open-source, simulatori di rete e sistemi in repository come GitHub. Ad esempio, il codice del simulatore del sistema open-source Raspberry Pi di Microsoft include l'integrazione precostruita in Hub IoT di Azure per consentire il rapido sviluppo di applicazioni basate su cloud che si interfacciano con le schede Raspberry Pi. Inoltre, tool di programmazione di basso livello come Node-RED supportano moduli preconfezionati (nodi) per alimentare i dati dei sensori simulati alle interfacce del servizio IoT della piattaforma cloud principale. Utilizzando questi approcci, gli sviluppatori possono facilmente generare un flusso di dati dei sensori.

Esecuzione di simulazioni in scala

Quando si usano simulatori a livello di dispositivo e i relativi strumenti, la difficoltà è data dal fatto che la gestione della simulazione dei dati può diventare un progetto a se stante. Per eseguire i simulatori, gli sviluppatori devono fornire e gestire le risorse come avviene per qualsiasi applicazione. A preoccupare maggiormente è il fatto che i modelli di dispositivi utilizzati per generare dati realistici diventano un progetto separato al di fuori del processo di sviluppo dell'applicazione IIoT. Nel corso dello sviluppo, gli sviluppatori devono garantire che i modelli dei dispositivi rimangano funzionalmente sincronizzati con eventuali cambiamenti nella definizione della rete dei dispositivi IIoT e dell'applicazione. Per applicazioni IIoT a livello aziendale, potrebbero trovare quanto meno difficile scalare queste simulazioni e persino iniziare ad attingere alle risorse richieste per sviluppare l'applicazione.

I principali fornitori di piattaforme cloud IoT affrontano queste problematiche con soluzioni di simulazione dei dispositivi IoT progettate per mettere in scala con la stessa facilità di altre risorse cloud nelle rispettive piattaforme. Ad esempio, AWS IoT Device Simulator fornisce un modello AWS per il suo servizio di configurazione CloudFormation, che implementa una rete privata virtuale che collega microservizi implementati in container in esecuzione sul motore AWS Fargate senza doverne gestire i server (Figura 5).

Figura 5: AWS IoT Device Simulator combina più servizi AWS per fornire un flusso scalabile di dati dei dispositivi allo stesso AWS IoT Core utilizzato dai dispositivi fisici. (Immagine per gentile concessione di Amazon Web Services)

Gli sviluppatori accedono alla simulazione in modo interattivo attraverso una console di interfaccia grafica utente (GUI) in esecuzione nel servizio Amazon S3, o a livello di programmazione tramite l'interfaccia di programmazione di applicazioni (API) IoT Device Simulator generata dal modello CloudFormation nel servizio Amazon API Gateway. Durante una simulazione, il microservizio IoT Device Simulator estrae le configurazioni dei dispositivi dal database NoSQL Amazon DynamoDB secondo un piano di simulazione globale descritto nella propria voce di configurazione.

Le configurazioni dei dispositivi sono record JSON che, tra le varie informazioni, definiscono i nomi degli attributi dei dispositivi (temperatura, ad esempio), l'intervallo di valori (da -40 a 85, ad esempio), l'intervallo di aggiornamento del dispositivo e la durata della simulazione. Gli sviluppatori possono aggiungere tipi di dispositivi in modo interattivo tramite la console oppure a livello di programma attraverso le API. Utilizzando i normali metodi DevOps, è possibile scalare rapidamente tipi di dispositivi, configurazione e infrastruttura per ottenere le frequenze di aggiornamento desiderate raggiungendo AWS IoT Core e l'applicazione a valle.

Nel simulatore di dispositivi Azure, gli sviluppatori possono ampliare ulteriormente l'elenco di base degli attributi con una serie di comportamenti supportati dal dispositivo durante l'esecuzione della simulazione, nonché una serie di metodi che l'applicazione cloud può richiamare direttamente.

Gemelli digitali

Dal punto di vista concettuale, questo tipo di simulazione dei dati dei dispositivi è strettamente legato alle capacità dei gemelli digitali che stanno emergendo nelle piattaforme cloud IoT commerciali. Diversamente dalle copie shadow che di solito forniscono solo una rappresentazione statica dello stato del dispositivo, i gemelli digitali estendono un modello di dispositivo virtuale per farne corrispondere lo stato fisico e il comportamento.

In Azure di Microsoft, il servizio Gemelli digitali di Azure permette agli sviluppatori di includere funzioni definite dall'utente per specificare il comportamento durante la simulazione di un dispositivo, continuando ad alimentare risultati all'Hub IoT di Azure come prima. A prescindere dal fatto che i dati siano simulati o reali, quelli in entrata vengono in seguito inviati a un servizio di routing degli eventi per essere ulteriormente distribuiti nell'applicazione. Microsoft utilizza i dati dei gemelli digitali anche per creare grafici spaziali che descrivono le interazioni e gli stati tra gli elementi in ambienti gerarchici complessi come un sistema di automazione industriale che comprende più reti (Figura 6).

Figura 6: Il servizio Gemelli digitali di Azure di Microsoft permette agli sviluppatori di realizzare dispositivi virtuali identici ai corrispettivi fisici per funzionalità e capacità, sulle cui basi costruire servizi sofisticati come i grafici spaziali di gerarchie IIoT complesse. (Immagine per gentile concessione di Microsoft)

Per le applicazioni IIoT, i gemelli digitali possono fornire un potente meccanismo in grado di supportare l'intero ciclo di vita delle applicazioni costruite intorno a queste capacità. Nelle prime fasi di sviluppo, i gemelli digitali possono essere portati in scala dai servizi di simulazione dei dispositivi della piattaforma. Man mano che le reti fisiche IIoT entrano in linea, i feed di dati simulati indirizzati al gemello digitale possono essere sostituiti dai feed di dati del dispositivo. In seguito, in un'applicazione IIoT completamente implementata, gli sviluppatori possono utilizzare qualsiasi differenza riscontrata tra un dispositivo fisico e il suo gemello digitale come input aggiuntivo per gli algoritmi di manutenzione predittiva o i rilevatori di intrusioni di sicurezza, ad esempio. Durante l'intero ciclo di vita, i gemelli digitali possono proteggere l'applicazione da interruzioni di rete o cambiamenti significativi nella configurazione delle reti di dispositivi IIoT.

La comparsa dei gemelli digitali nelle piattaforme IoT porta anche un vantaggio secondario: un approccio standardizzato per la descrizione degli attributi e dei comportamenti dei modelli di dispositivi. Per il suo linguaggio descrittivo, il servizio Gemelli digitali di Azure di Microsoft utilizza JSON-LD (JavaScript Object Notation for Linked Data). Sostenuto dal World Wide Web Consortium (W3C), JSON-LD fornisce un formato standard per la serializzazione dei dati collegati basato sul formato JSON standard del settore, già utilizzato in numerosi altri segmenti applicativi.

Le descrizioni di gemelli digitali standardizzate possono accelerare ulteriormente lo sviluppo con l'emergere di repository di descrizioni di gemelli digitali pre-costruite per sensori e attuatori. Ad esempio, Bosch fornisce già oggi descrizioni di gemelli digitali open-source di diversi suoi sensori scritte nel linguaggio Eclipse Vorto e pubblicate nel repository Eclipse Vorto. Grazie all'uso di una grammatica familiare alla maggior parte dei programmatori, il linguaggio Eclipse Vorto fornisce un metodo semplice per descrivere modelli e interfacce per gemelli digitali. In seguito, gli sviluppatori possono convertire le loro descrizioni in linguaggio Vorto in JSON-LD o in altri formati a seconda delle necessità.

Realizzazione dell'applicazione IIoT

La simulazione dei dati dei dispositivi, realizzata con simulatori discreti o con piattaforme orientate ai microservizi, fornisce una soluzione efficace basata su software per accelerare lo sviluppo delle applicazioni. Per applicazioni IIoT che utilizzano più reti di dispositivi, la migrazione delle simulazioni dei dispositivi verso la periferia può facilitare ulteriormente la transizione alla distribuzione senza sacrificare la necessità di dati rappresentativi nelle prime fasi di sviluppo di un'applicazione.

I sistemi di edge computing svolgono un ruolo sempre più fondamentale nelle applicazioni IoT su larga scala. Forniscono le risorse locali necessarie per requisiti emergenti quali la preelaborazione dei dati di base per ridurre la quantità di dati che arrivano al cloud e capacità di classificazione avanzate come i modelli di inferenza di apprendimento automatico. Svolgono anche un ruolo più cruciale come gateway di comunicazione tra le reti di dispositivi FAN e quelle di accesso ad alta velocità.

Gateway come la famiglia programmabile MultiConnect Conduit di Multi-Tech Systems offrono piattaforme che combinano il supporto delle comunicazioni con capacità di elaborazione edge. MTCAP-915-001A di Multi-Tech per regioni di 915 MHz e MTCAP-868-001A per quelle di 868 MHz assicurano la connettività LoRaWAN per aggregare i dati dei dispositivi FAN (Field Area Network) e la connettività Ethernet o 4G-LTE lato cloud. Basate sul sistema operativo open-source Multi-Tech Linux (mLinux), queste piattaforme mettono a disposizione anche un ambiente di sviluppo familiare per eseguire le simulazioni dei dispositivi. Poiché le reti di campo separate sono dotate di sensori fisici e di altri dispositivi, ogni unità può tornare al suo ruolo di gateway di comunicazione, reindirizzando gli sforzi di elaborazione a requisiti come la preelaborazione dei dati.

Conclusione

Le applicazioni IIoT presentano sfide significative per l'implementazione di reti di sensori sul campo e lo sviluppo di software applicativo basato su cloud in grado di trasformare i dati dei sensori in risultati utili. La dipendenza reciproca delle reti di sensori e del software applicativo può mettere in difficoltà lo sviluppo mentre l'implementazione dei sensori e la distribuzione del software attendono a vicenda che l'altro raggiunga un sufficiente livello di massa critica.

Come è stato dimostrato, gli sviluppatori possono uscire da questa situazione di stallo e accelerare lo sviluppo di applicazioni IIoT simulando flussi di dati a livelli realistici di volume, velocità e varietà.