Accelerare lo sviluppo di applicazioni IoT - Parte 2: Implementazione veloce di sensori IIoT

Di Stephen Evanczuk

Contributo di Editori nordamericani di DigiKey

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. Qui, nella Parte 2 sono presentate le opzioni per prototipare rapidamente i sistemi di sensori per la generazione di dati.

Le applicazioni su larga scala di Internet delle cose industriale (IIoT) dipendono fondamentalmente dall'analisi e dalla risposta ai flussi di dati generati dalle reti di sensori installati nell'ambiente interessato. Senza una pronta disponibilità di questi flussi di dati nelle prime fasi di sviluppo, le applicazioni IIoT possono subire ritardi rispetto alla programmazione o non essere all'altezza delle aspettative dell'azienda.

Sebbene i metodi di simulazione possano soddisfare le esigenze di dati per molte applicazioni, per altre potrebbero essere richiesti dati che corrispondono realmente all'ambiente interessato. In questo caso, l'impegno richiesto per fornire risultati di simulazione efficaci può essere proibitivo. Invece, l'uso di unità a sensori e gateway facilmente reperibili offre un percorso potenzialmente più semplice per un rapido invio dei dati. Progettate specificamente per ambienti industriali, queste unità supportano un'ampia gamma di tipi di sensori e di opzioni di connettività con il minimo sforzo da parte dell'utente.

Nel secondo articolo di questa serie in due parti sull'accelerazione dello sviluppo di applicazioni IIoT, vengono descritti i diversi tipi di sensori e gateway IIoT preconfigurati idonei per generare i dati necessari per accelerare lo sviluppo di applicazioni IIoT.

I limiti delle simulazioni di dati IIoT

I dati dei sensori sono fondamentali per le applicazioni IIoT, la cui piena diffusione dipende dalla pronta disponibilità sia dei sistemi di sensori destinati a fornire quei dati, sia dei sistemi software necessari per trasformare tali dati in informazioni utili. Per alcune applicazioni IIoT, la simulazione potrebbe non fornire dati sufficientemente utili. Senza una meticolosa attenzione ai parametri della simulazione, i flussi di dati simulati potrebbero mostrare proprietà che condizionano l'applicazione verso un particolare inviluppo operativo.

Ad esempio, una simulazione dei dati configurata per fornire una temperatura casuale con una distribuzione uniforme nell'intervallo da -40 °C a +125 °C potrebbe condizionare l'applicazione verso temperature estreme al di fuori dell'effettivo intervallo dell'ambiente interessato. Inoltre, è facile che una simulazione semplicistica di questo tipo fornisca dati di temperatura con salti di decine di gradi da un periodo di misurazione all'altro. In un'applicazione IIoT tipica, cambiamenti di temperatura così radicali e irrealistici potrebbero indurre confusione nei cicli di controllo del processo e in altri risultati dell'applicazione.

La qualità dei dati e la loro efficacia nella rappresentazione di condizioni realistiche sono particolarmente importanti se è previsto che l'applicazione includa modelli di inferenza di apprendimento automatico. Gli analisti dei dati si rendono conto che i modelli di inferenza addestrati su dati scadenti daranno risultati altrettanto scadenti. Di conseguenza, il livello di impegno necessario per creare simulazioni efficaci dei dati richiesti per questi modelli può crescere rapidamente.

Per la maggior parte dei progetti IIoT, è semplicemente impensabile ritardare lo sviluppo delle applicazioni fino all'implementazione dei sistemi di sensori. E potrebbe non essere nemmeno fattibile anche quando si prevede che l'esecuzione dell'applicazione software riveli le informazioni necessarie o addirittura fornisca la giustificazione per l'implementazione completa. Ad esempio, gli analisti dei dati potrebbero aver bisogno dei risultati di algoritmi complessi per determinare se sono necessari dati a risoluzione e velocità di aggiornamento più elevate o anche tipi di dati diversi per risolvere le ambiguità nei risultati o per ottimizzare in altro modo l'applicazione.

È per tutti questi motivi che le organizzazioni potrebbero decidere a malincuore che ritardare lo sviluppo di applicazioni IIoT è preferibile rispetto allo sviluppo di un'applicazione con dati simulati che non rappresentano fedelmente il processo industriale e l'ambiente di destinazione. Fortunatamente, la crescente disponibilità di sistemi di sensori IIoT già predisposti e dei dispositivi gateway associati consente di implementare rapidamente almeno il set di sensori più critico richiesto per lo sviluppo di applicazioni.

Implementazione rapida della rete di sensori

I sensori IIoT combinano sensori, processori e interfacce di connettività in un contenitore progettato per resistere alle sollecitazioni di un tipico ambiente industriale. Oltre ai singoli sensori di temperatura, vibrazione, pressione e umidità, gli sviluppatori possono trovare unità multisensore che raccolgono combinazioni di sensori necessari per funzioni di applicazioni specifiche come la manutenzione predittiva.

I metodi di manutenzione predittiva monitorano le caratteristiche che servono a segnalare potenziali guasti delle apparecchiature. Nei motori, ad esempio, variazioni specifiche della frequenza di vibrazione e della temperatura indicano in modo affidabile tipi di guasti molto specifici. Progettati per acquisire questi dati, i sensori IIoT come quello per la manutenzione predittiva PR55-20A di National Control Devices (NCD) combinano i sensori richiesti con un microcontroller a basso consumo e la connettività di rete a maglie wireless DigiMesh (Figura 1).

Schema del sensore per la manutenzione predittiva NCD PR55-20AFigura 1: Il sensore per la manutenzione predittiva PR55-20A di NCD abbina più sensori alla connettività di rete a maglie necessaria per fornire dati ai nodi wireless locali. (Immagine per gentile concessione di National Control Devices)

Per accelerare lo sviluppo di applicazioni IIoT, gli sviluppatori possono facilmente combinare sensori specializzati come quello per la manutenzione predittiva di NCD con altri come quello ambientale wireless PR49-24G della stessa azienda che integra sensori di temperatura, umidità e gas in un contenitore industriale alimentato da due batterie AA.

Oltre a numerosi tipi di sensori specifici, i produttori di sensori IIoT forniscono unità gateway di comunicazione già predisposte, progettate per semplificare l'integrazione dei sensori nelle reti collegate localmente. Sono infatti disponibili unità gateway preconfigurate per connettersi con specifici cloud commerciali o supportare protocolli di comunicazione comunemente usati per la connessione con piattaforme cloud IoT.

Per i suoi sensori wireless DigiMesh, la serie di gateway PR55-21 di NCD utilizza una connessione Wi-Fi per connettersi a specifici servizi cloud tra cui Microsoft Azure IoT (PR55-21_AZURE), Amazon Web Services IoT (PR55-21_AWS) o la piattaforma Losant IoT (PR55-21_LOSANT). Inoltre, il suo gateway PR55-21_MQTT supporta le comunicazioni con qualsiasi host che utilizza il protocollo nello standard ISO MQ Telemetry Transport (MQTT). Come per gli altri membri della serie PR55-21, il gateway PR55-21_MQTT combina un microcontroller industriale a basso consumo con sottosistemi per la connettività wireless DigiMesh locale e per una connessione criptata backhaul Wi-Fi a un server MQTT locale o remoto (Figura 2).

Schema del gateway PR55-21_MQTT di NCDFigura 2: Il gateway PR55-21_MQTT di NCD combina il supporto wireless per una rete a maglie DigiMesh locale e per lo scambio di messaggi MQTT con un server tramite connessione Wi-Fi. (Immagine per gentile concessione di National Control Devices)

Gli sviluppatori possono configurare rapidamente la rete locale DigiMesh e la connessione Wi-Fi MQTT utilizzando uno strumento basato su menu fornito grazie al server Web embedded nel gateway. Ad esempio, una schermata del dispositivo mostra i dispositivi collegati a DigiMesh, la potenza del loro segnale e la loro attività e fornisce un punto centrale per la gestione della loro configurazione (Figura 3).

Immagine del server Web embedded del gateway PR55-21_MQTT di NCD (fare clic per ingrandire)Figura 3: Il server Web embedded del gateway PR55-21_MQTT di NCD consente agli utenti di modificare le impostazioni ed esaminare l'attività dei sensori collegati alla rete locale. (Immagine per gentile concessione di National Control Devices)

La rete a maglie DigiMesh offre un approccio efficace per estendere il campo effettivo di transceiver a basso consumo richiesti nei sistemi di sensori alimentati a batteria. Ovviamente si tratta solo di una delle varie opzioni di connettività che si possono incontrare negli ambienti industriali, per molti dei quali i produttori offrono combinazioni simili di sensori e gateway. Ad esempio, Laird offre la serie Sentrius RS1xx che comprende sensori industriali progettati per supportare la connettività Bluetooth e LoRaWAN. La serie Sentrius RG1xx comprende gateway complementari progettati per supportare i requisiti regionali di frequenza per l'implementazione di LoRaWAN. Inoltre, questi gateway supportano la connettività Bluetooth locale e quella Internet Wi-Fi backhaul.

In alcune applicazioni, forti sorgenti di interferenze elettromagnetiche (EMI) possono peggiorare l'integrità del segnale nelle comunicazioni wireless. Per queste situazioni, la capacità di separare le funzionalità dei sensori e delle comunicazioni può essere un importante vantaggio. Oltre ai sensori industriali wireless proprietari, Banner Engineering ne offre altri progettati per il collegamento tramite un'interfaccia seriale RS-485 o a 1 filo ad un nodo wireless separato. Grazie a questa soluzione, gli operatori possono posizionare il nodo di comunicazione wireless a una certa distanza da un sensore collegato a una forte sorgente EMI come un motore ad alta velocità (Figura 4).

Immagine del sensore di vibrazione di Banner Engineering montato sul motoreFigura 4: Per situazioni con notevoli interferenze elettromagnetiche come nella misurazione della vibrazione del motore, gli sviluppatori possono collegare un sensore di vibrazioni Banner Engineering montato sul motore con un nodo wireless posizionato a una certa distanza dalla sorgente dei disturbi. (Immagine per gentile concessione di Banner Engineering)

Il nodo wireless DX80N9Q45VTP di Banner Engineering è in grado di supportare questo tipo di configurazione. È progettato per connettersi con il sensore di vibrazioni e temperatura con un filo QM30VT1 della stessa azienda, mentre il nodo wireless DX80N9Q45TH si connette con il sensore di temperatura e umidità M12FTH4Q sempre con un filo. In presenza di maggiori requisiti di interfaccia, il sensore DX80N9Q45U funziona da nodo wireless universale a un filo e la serie DX80G9M6S di nodi wireless supporta connessioni di sensori RS-485 a reti multihop.

Elaborazione locale

Anche con una rapida implementazione delle reti di sensori IIoT, gli sviluppatori potrebbero dover prevedere un certo livello di elaborazione in locale per ridurre il volume dei dati o alleggerire il carico di elaborazione sulle risorse a valle. I sensori industriali avanzati come quello di vibrazioni e temperatura QM30VT2 di Banner Engineering consentono agli utenti di suddividere la frequenza di vibrazione misurata in ben 20 bande. Questa capacità è particolarmente importante nelle applicazioni di manutenzione predittiva, dove è risaputo che i cambiamenti all'interno di bande di frequenza separate segnalano specifici tipi di guasti.

Oltre alla pre-elaborazione da parte dei sensori, l'implementazione precoce delle reti di sensori potrebbe imporre una serie di requisiti per l'elaborazione locale. Banner Engineer fornisce questa capacità con il suo controller e gateway DXM700. In soli 70x86x55 mm, DXM700 assicura una connettività wireless e cablata locale multipla e backhaul Ethernet ai server host (Figura 5).

Immagine del controller e gateway DXM700 di Banner EngineeringFigura 5: Il controller e gateway DXM700 di Banner Engineering offre diverse opzioni di connettività sia locale che Internet, oltre a supportare l'elaborazione locale in ScriptBasic. (Immagine per gentile concessione di Banner Engineering)

Poiché riceve i dati da reti di sensori locali, il controller può eseguire programmi scritti in ScriptBasic per esaminare i dati in entrata, sulla base dei quali può attivare uscite; può anche eseguire semplici trasformazioni dei dati. La documentazione di Banner Engineering include campioni di ScriptBasic che illustrano alcune azioni tipiche come la risposta alle variazioni dei dati dei sensori (Listato 1).

Copy
 
.
.
.
'Function tos read the T/H sensor
FUNCTION GetTempHumidityData
   LastValueTempC = TempC
   LastValueHumidity = Humidity
   Humidity =GETREG(SensorHumidity_reg, TH_SID, MBtype) 
   TempC = GETREG(SensorTempC_reg, TH_SID, MBtype)
   IF Humidity > 65535 or TempC > 65535 THEN 
         PRINT "Read Error - humidity / temp reading...", Humidity,"  ",TempC,"\n\r"
   END IF
   WrErr = SETREG (Humidity_reg, Humidity, LocalRegSID, MBtype)
   WrErr = SETREG (TempC_reg, TempC, LocalRegSID , MBtype)
 
FUNCTION StateMachine
'State machine definitions for the periodic reading of temp/humidity
' TH_State = 0  current state of the state machine
' TH_Idle= 0  initial state
' TH_Wait= 1  wait time between samples
' TH_Sample= 2  get samples from remote sensor
' TH_Error= 3 error state - unknown condition

   LOCAL StartState
   StartState = TH_State
   WrErr = SETREG (SM_reg, TH_State, LocalRegSID, MBtype)
   
   IF TH_State = TH_Idle THEN
          StartTime = NOW
          TH_State = TH_Wait
   ELSEIF TH_State = TH_Wait THEN
      IF NOW >= (StartTime + WaitTime) THEN 
         TH_State = TH_Sample
      ELSE 
         TH_State = TH_Wait
      END IF 
   ELSEIF TH_State = TH_Sample THEN
      GetTempHumidityData
      TH_State = TH_Idle
   ELSE 
      TH_State = TH_Error
   END IF 
   IF StartState <> TH_State THEN
      PRINT "\r\n Time ",NOW,"  SM Started-> ",THState[StartState],"  End->",THState[TH_State]," \r\n"
   END IF

END FUNCTION 

FUNCTION LED_driver  
IF LastValueTempC < TempC THEN    WrErr = SETREG (TempGoingUp_LED2_reg,1,DisplaySID, MBtype) 
   ELSE
      WrErr = SETREG (TempGoingUp_LED2_reg,0,DisplaySID, MBtype) 
   END IF
   
   IF LastValueTempC > TempC THEN    WrErr = SETREG (TempGoingDown_LED3_reg,1,DisplaySID, MBtype) 
   ELSE
      WrErr = SETREG (TempGoingDown_LED3_reg,0,DisplaySID, MBtype) 
   END IF
   
   IF (Humidity > 65535 ) OR (TempC > 65535) THEN    WrErr = SETREG (CommsError_LED4_reg,1,DisplaySID, MBtype) 
   ELSE
      WrErr = SETREG (CommsError_LED4_reg,0,DisplaySID, MBtype) 
   END IF 
   
   IF GETREG(ScriptRunnning_LED1_reg, DisplaySID, MBtype) THEN
      WrErr = SETREG (ScriptRunnning_LED1_reg,0,DisplaySID, MBtype) 
   ELSE 
      WrErr = SETREG (ScriptRunnning_LED1_reg,1,DisplaySID, MBtype) 
   END IF
   
END FUNCTION 

‘Main program loop
BEGIN:
   PRINT "Script Starting\r\n"
   ITERATE:
      'PRINT "\r\n Time = ",NOW," \r\n"
      StateMachine
      LED_driver
      Sleep(1)
   GOTO ITERATE
END

Listato 1: Questo frammento di ScriptBasic offerto da Banner Engineering mostra come gli sviluppatori possono programmare DXM700 per rispondere localmente ai dati dei sensori, in questo caso accendendo e spegnendo i LED in risposta alle variazioni dei dati relativi a temperatura e umidità. (Codice per gentile concessione di Banner Engineering)

I gateway, come quelli della serie MTCAP-Lxxx di Multi-Tech Systems, offrono una flessibilità ancora maggiore per l'elaborazione locale. Progettata per soddisfare diverse esigenze di connettività, questa serie supporta la connettività LoRaWAN locale sul lato sensore, oltre a quella Ethernet e LTE a banda larga opzionale per i canali di backhaul. Come ambiente operativo, questi gateway si basano sul sistema operativo open-source Multi-Tech Linux (mLinux). Gli sviluppatori possono dunque creare routine di software di elaborazione locale in un ambiente di sviluppo familiare. Inoltre, questi gateway supportano Node-RED, il che costituisce un'opzione di sviluppo low-code (codice a basso livello) utile per applicazioni guidate dagli eventi come IIoT. Ulteriori informazioni su Node-RED più avanti in questo articolo.

Prototipazione rapida low-code

La rapida implementazione di reti di sensori fisici può aiutare ad accelerare lo sviluppo di applicazioni IIoT fornendo una fonte di dati critici ben prima della progettazione, dello sviluppo e della messa in servizio di reti di sensori in scala reale. Ma questa operazione può essere ostacolata se comporta requisiti collaterali notevoli per lo sviluppo di software. Le unità a sensori e i gateway IIoT preconfigurati descritti in precedenza in molti casi permettono di evitare questa situazione, ma requisiti di dati speciali oltre le capacità dei sensori e dei gateway drop-in possono comportare altri requisiti software specifici.

Per affrontare requisiti di dati specifici, le piattaforme di prototipazione rapida come Arduino e Raspberry Pi offrono una vasta gamma di sensori e attuatori specializzati sotto forma di schede add-on. Mescolando e abbinando queste schede add-on, gli sviluppatori possono realizzare rapidamente un prototipo per soddisfare praticamente qualsiasi esigenza di dati dei sensori.

Per le applicazioni IoT, i produttori hanno reso più facile la prototipazione delle applicazioni con il rilascio di schede multisensore progettate con il minimo ingombro e la capacità funzionale tipicamente richiesta in tali applicazioni. Schede di sviluppo come il kit di valutazione RSL10-SENSE-GEVK di ON Semiconductor o il kit di sviluppo SensorTile STEVAL-STLKT01V1 di STMicroelectronics integrano un processore ad alte prestazioni con una vasta gamma di sensori tipicamente richiesti nei dispositivi indossabili e IoT. Ad esempio, SensorTile combina un processore STM32L4 con un transceiver BLUENRG-MS, entrambi di STMicroelectronics, e una serie di sensori che include un sensore di pressione microelettromeccanico (MEMS) LPS22HBTR, un'unità di misurazione inerziale (IMU) MEMS LSM6DSMTR con accelerometro e giroscopio e una bussola elettronica MEMS LSM303AGRTR con sensori di accelerazione lineare e magnetici della stessa azienda (Figura 6).

Schema della scheda SensorTile di STMicroelectronicsFigura 6: SensorTile di STMicroelectronics, basata su un processore STM32L4 della stessa azienda, fornisce una piattaforma hardware flessibile per la realizzazione di sistemi di sensori in grado di soddisfare requisiti specifici oltre a quelli supportati nei sistemi di sensori IIoT di serie. (Immagine per gentile concessione di STMicroelectronics)

Node-RED, diffuso ambiente di sviluppo low-code, permette agli sviluppatori di programmare queste schede e altri sistemi hardware come i dispositivi NCD e i gateway Multi-Tech tracciando grafici (flussi) che collegano elementi funzionali (nodi). Questi flussi corrispondono alle interazioni tra i nodi corrispondenti a specifiche capacità funzionali, tra cui la lettura dei dati dei sensori, l'esecuzione di operazioni sui dati, il trasferimento dei dati ad altri elementi funzionali come i gateway cloud e la visualizzazione dei dati (Figura 7).

Schema dell'ambiente di sviluppo Node-REDFigura 7: L'ambiente di sviluppo Node-RED permette agli sviluppatori di creare applicazioni collegando nodi tratti da un vasto repository open-source. (Immagine per gentile concessione di National Control Devices)

Con oltre 225.000 moduli disponibili nel repository di flussi Node-RED open-source, questo ambiente offre un ricco ecosistema per lo sviluppo di applicazioni guidate dagli eventi, come l'acquisizione di dati dei sensori e il trasferimento al cloud. Sebbene Node-RED fornisca metodi per integrare i flussi risultanti nelle applicazioni di produzione, la sua dipendenza da Node.js potrebbe non essere idonea per alcune applicazioni o ambienti di produzione.

DK IoT Studio di Digi-Key offre un altro ambiente di sviluppo low-code che elimina in larga misura la necessità di sviluppare a mano il software, pur continuando a fornire codice sorgente in linguaggio C. Utilizzando DK IoT Studio, gli sviluppatori creano le capacità funzionali richieste inserendo i componenti associati a ciascuna caratteristica di SensorTile nell'area di lavoro di DK IoT Studio (Figura 8).

Immagine di DK IoT Studio di Digi-Key (fare clic per ingrandire)Figura 8: DK IoT Studio di Digi-Key genera automaticamente il codice (lato sinistro) dalle applicazioni create collegando i componenti funzionali posti come icone sullo sfondo (centro) e modificando le caratteristiche associate (lato destro) secondo necessità. (Immagine per gentile concessione di Digi-key/STMicroelectronics)

Oltre al supporto di componenti hardware specifici, questo ambiente fornisce componenti funzionali inseribili simili che rappresentano il trasferimento di dati al cloud o il funzionamento delle risorse del cloud. Dopo aver tracciato il grafico che descrive il flusso dei dati e le operazioni, gli sviluppatori possono scaricare il codice generato per caricarlo in SensorTile. Quando si realizzano prototipi tipici, questo processo richiede uno sviluppo di codice ulteriore ridotto al minimo o nullo. Per ulteriori informazioni sul flusso di sviluppo della prototipazione rapida, leggere "Implementare rapidamente un dispositivo IoT multi-sensore certificato Bluetooth 5 alimentato a batteria".

Conclusione

Lo sviluppo di applicazioni IIoT su larga scala dipende fortemente dalla disponibilità di dati che rappresentino fedelmente l'ambiente interessato. Come abbiamo visto nella Parte 1 di questa serie di articoli, i metodi di simulazione possono soddisfare le esigenze di dati per molte applicazioni, mentre altre potrebbero richiedere dati che corrispondano realmente all'ambiente interessato. In questo caso, l'impegno richiesto per fornire risultati di simulazione efficaci può essere proibitivo. Invece, l'uso di unità a sensori e gateway facilmente reperibili offre un percorso potenzialmente più semplice per fornire rapidamente i dati.

Come illustrato in questa Parte 2, queste unità supportano un'ampia gamma di tipi di sensori e di opzioni di connettività richiedendo uno sforzo minimo da parte dell'utente. Utilizzando questi prodotti, gli sviluppatori possono implementare rapidamente reti di sensori in grado di fornire i dati necessari per accelerare lo sviluppo di applicazioni IIoT.

DigiKey logo

Esonero della responsabilità: le opinioni, le convinzioni e i punti di vista espressi dai vari autori e/o dai partecipanti al forum su questo sito Web non riflettono necessariamente le opinioni, le convinzioni e i punti di vista di DigiKey o le sue politiche.

Informazioni su questo autore

Image of Stephen Evanczuk

Stephen Evanczuk

Stephen Evanczuk ha più di 20 anni di esperienza come autore sull'industria elettronica e ha scritto su una vasta gamma di argomenti tra cui hardware, software, sistemi e applicazioni, incluso l'IoT. Ha ricevuto un Ph.D. in neuroscienze sulle reti neuronali e ha lavorato nel settore aerospaziale su sistemi di sicurezza ampiamente distribuiti e sui metodi di accelerazione algoritmica. Attualmente, quando non scrive articoli su tecnologia e ingegneria, lavora su applicazioni di deep learning per i sistemi di riconoscimento e di raccomandazione.

Informazioni su questo editore

Editori nordamericani di DigiKey