EUR | USD

Velocizzare la configurazione degli impianti di automazione industriale mediante i debugger remoti dei microcontroller remoti

Di Bill Giovino

Contributo di Editori nordamericani di Digi-Key

Gli impianti di automazione industriale stanno aumentando l'uso di computer monoscheda (SBC) basati sui microcontroller per controllare le operazioni dell'impianto al fine di aumentare l'efficienza e migliorare la produttività. Spesso gli SBC utilizzati sono una combinazione di SBC di serie con firmware configurabile e SBC personalizzati con firmware personalizzato. Tuttavia, per i nuovi impianti industriali, o per gli impianti esistenti che hanno appena subito una riconfigurazione, il firmware SBC può avere bisogno di essere modificato per migliorare le operazioni o correggere i bug del codice.

Questo articolo discuterà il ruolo degli SBC e perché il debug remoto sta diventando sempre più importante negli ambienti industriali. Introdurrà quindi i debugger remoti e il software associato di MikroElektronika e spiegherà come possono essere collegati a una rete Wi-Fi per eseguire il debug remoto dei microcontroller Arm® nella maggior parte degli SBC.

SBC nei computer industriali

I moderni impianti di automazione industriale sono sotto pressione per aumentare la produttività con una migliore gestione dei processi attraverso una maggiore precisione. Questo può includere l'uso di sensori ad alta risoluzione per fornire dati più accurati al firmware di controllo. Inoltre, gli attuatori come i motori e i solenoidi possono essere aggiornati con attuatori capaci di muoversi in incrementi molto più piccoli.

Una volta installati questi sensori e attuatori di maggiore precisione e risoluzione, il firmware di controllo negli SBC che gestiscono questi dispositivi deve essere modificato per trarre vantaggio dalla maggiore risoluzione. Se l'aggiornamento del firmware non può essere gestito dall'attuale SBC, deve essere installato un nuovo SBC. In entrambi i casi, il nuovo firmware sarà tipicamente testato e sul banco di prova prima di essere installato nell'impianto industriale. Dopo i test iniziali, il nuovo sistema viene messo in funzione.

Tuttavia, per i processi più complessi il debug e la programmazione possono non finire qui. Il funzionamento nel sistema può rivelare problemi non scoperti durante questi test di pre-produzione e in molti casi l'unico modo per ottimizzare il firmware è quello di eseguire il debug mentre l'SBC è in uso.

I nuovi impianti di automazione industriale possono trovarsi di fronte agli stessi problemi. Questo è vero soprattutto per i sistemi ad alte prestazioni in cui gli anelli di controllo del firmware devono essere messi a punto per soddisfare i requisiti di efficienza. Indipendentemente dal fatto che l'impianto industriale sia nuovo o aggiornato, i tempi morti sono costosi e devono essere ridotti al minimo. Ciò significa che gli SBC devono essere verificati e programmati in-system.

Debug di sistemi industriali embedded a distanza

Il debug degli SBC usati nei sistemi industriali non è diverso da quello di qualsiasi sistema basato su microcontroller. Un debugger deve essere fisicamente collegato via cavo dalla porta di debug del microcontroller a un PC che esegue un software di debug. Un tecnico al PC esamina ed esegue il debug del firmware mentre è in funzione. Questo può essere dispendioso in termini di tempo se molti SBC devono essere sottoposti a debug in loco, poiché i tecnici devono recarsi presso la sede fisica di ogni SBC. Ciò può essere complicato se alcuni SBC sono in ambienti difficili, o in luoghi fisicamente remoti o inaccessibili. Inoltre, spesso solo un numero limitato di tecnici ha familiarità con il firmware personalizzato, e questi tecnici devono eseguire il debug di molti sistemi in poco tempo, complicando la procedura e ritardando il processo.

La soluzione è quella di utilizzare debugger remoti che sono fisicamente collegati agli SBC ma hanno capacità di debug fornite da un PC in rete situato altrove. I debugger remoti possono essere collegati alla porta di debug del microcontroller dell'SBC mentre sono collegati alla rete di una struttura tramite Wi-Fi. Un PC sulla stessa rete in una posizione comoda può essere usato per accedere a qualsiasi debugger remoto. Il tecnico ha quindi una capacità di debug completa sul PC remoto.

Per eseguire questo debug remoto, gli ingegneri possono utilizzare CodeGrip di Mikroe, una famiglia di debugger remoti che possono connettersi via Wi-Fi a un PC remoto per supportare la programmazione e il debug di molti microcontroller Arm. Il debugger MIKROE-3460 CodeGrip Wi-Fi può essere utilizzato sulla maggior parte dei microcontroller Arm con una porta JTAG (Figura 1). Supporta anche la porta di debug monofilare Arm Serial Wire Output (SWO) presente sulla maggior parte dei microcontroller Arm Cortex-M3, Cortex-M4 e Cortex-M7.

Immagine del debugger remoto MIKROE-3460 CodeGrip di MikroElektronikaFigura 1: Il debugger remoto MIKROE-3460 CodeGrip è fisicamente collegato alla porta di debug JTAG o SWO di un SBC. Vi si può accedere a distanza via Wi-Fi per programmare o eseguire il debug del firmware di un microcontroller Arm. (Immagine per gentile concessione di Mikroe)

MIKROE-3460 CodeGrip di Mikroe è collocato nella posizione fisica dell'SBC basato su Arm. Ha una porta da collegare alla porta JTAG o SWO disponibile sul connettore della scheda. Viene poi collegato temporaneamente a un laptop USB per configurare inizialmente l'unità CodeGrip per il microcontroller in fase di debug. Per i sistemi ad alte prestazioni, l'unità CodeGrip ha un connettore USB-C. Questo è particolarmente utile in situazioni anguste e consente di risparmiare tempo, poiché a differenza dei precedenti connettori USB, i connettori USB-C non hanno orientamento.

Il laptop collegato all'unità CodeGrip deve eseguire la CodeGrip Suite di Mikroe per configurare inizialmente l'unità CodeGrip. L'unità CodeGrip indica il suo stato tramite cinque LED (Figura 2). Ciò fornisce informazioni di stato critiche a un tecnico in loco che l'unità sta funzionando correttamente senza dover collegare un laptop. Quando è correttamente alimentato, il LED verde di alimentazione si accende. Durante il normale funzionamento dell'unità CodeGrip si accende anche il LED rosso. Se il LED verde è acceso e il LED rosso è spento, può indicare una connessione scarsa o assente alla porta JTAG/SWO; un'informazione importante per un tecnico locale poiché il cavo di debug potrebbe aver bisogno di essere reinserito o sostituito.

Schema dell'unità CodeGrip di MikroElektronika (fare clic per ingrandire)Figura 2: L'unità CodeGrip fornisce informazioni critiche sullo stato utilizzando cinque LED che forniscono un rapido riscontro visivo sul campo senza dover collegare un laptop. (Immagine per gentile concessione di Mikroe)

Una volta collegato via USB a un laptop, l'unità CodeGrip indicherà l'esito positivo della connessione accendendo il LED giallo USB-LINK sull'unità. L'utente esegue quindi CodeGrip Suite per configurare l'unità CodeGrip tramite la connessione USB.

Configurazione di CodeGrip

Spesso CodeGrip Suite può rilevare automaticamente il microcontroller Arm sull'SBC, ma può anche essere configurato manualmente con il tipo di core, la dimensione della memoria flash e la configurazione della RAM. Tuttavia, non tutte le famiglie di prodotti Arm possono essere facilmente configurate utilizzando lo stesso debugger. Per la famiglia Arm STM32 di STMicroelectronics, Mikroe fornisce l'unità MIKROE-3461 CodeGrip. La famiglia Kinetis di NXP Semiconductors è supportata da MIKROE-3462CodeGrip. Per tutti questi, il funzionamento dell'unità CodeGrip e di CodeGrip Suite sono identici.

Una volta collegata e configurata, CodeGrip Suite può eseguire operazioni di programmazione e debug in loco. Durante qualsiasi trasferimento di dati all'unità CodeGrip, il LED blu dei dati lampeggia, indicando che i dati vengono trasferiti tra l'unità CodeGrip e CodeGrip Suite. Ciò indica che l'unità CodeGrip sta funzionando correttamente e sta programmando o verificando l'SBC.

Per il debug remoto, l'unità CodeGrip può essere configurata per connettersi via Wi-Fi a un PC remoto che esegue anche CodeGrip Suite. Per motivi di sicurezza e prestazioni, la rete Wi-Fi utilizzata per connettersi alle unità CodeGrip dovrebbe essere separata dalle altre reti Wi-Fi utilizzate nell'impianto industriale. L'invio di un file .bin o .hex di grandi dimensioni all'unità CodeGrip tramite Wi-Fi è l'equivalente del download di un file di grandi dimensioni su un PC, quindi può rallentare l'intera rete. Se un PC remoto si connette all'unità CodeGrip, il LED arancione NET-LINK sull'unità CodeGrip si accende, a indicare il buon esito della connessione. Una volta che l'unità CodeGrip è configurata, il laptop collegato via USB può essere disconnesso.

CodeGrip Suite può leggere, programmare e cancellare l'intera memoria flash sul microcontroller di destinazione. Può anche confrontare il contenuto della memoria flash del microcontroller con un file sorgente per verificare che il firmware sia autentico e non sia stato manomesso. Ciò può essere utile anche durante un audit di sicurezza per verificare la sicurezza del firmware senza doversi recare alla posizione fisica di ogni SBC.

CodeGrip Suite può anche eseguire un ripristino hardware del microcontroller di destinazione. Questo può essere utile per un SBC malfunzionante o se si sospetta una violazione della sicurezza. Normalmente un SBC ripristinato eseguirà un autotest integrato (BIST) all'avvio che include controlli di sicurezza, per verificare che il dispositivo funzioni correttamente e non sia stato manomesso.

Una grande caratteristica dell'unità Mikroe CodeGrip è che supporta la porta di debug in tempo reale Arm SWO. Il pin SWO trasmette informazioni di debug sullo stato del microcontroller Arm e può essere utilizzato per fornire, in tempo reale, informazioni di stato e di tracciamento sul funzionamento del firmware. Mikroe fornisce una libreria SWO con funzioni che possono migliorare le capacità di debug di CodeGrip Suite (Figura 3). Ciò può permettere di monitorare ed eseguire il debug a distanza del firmware del microcontroller.

Immagine di CodeGrip Suite di MikroElektronika che può fornire informazioni di debug e tracciamento in tempo realeFigura 3: CodeGrip Suite può fornire informazioni di debug e tracciamento in tempo reale per un microcontroller Arm tramite lo streaming dei dati sulla porta SWO. Le informazioni di debug sono codificate a colori per semplicità. (Immagine per gentile concessione di Mikroe)

I messaggi SWO sono suddivisi in tre categorie: Informazioni, Avviso ed Errore. CodeGrip può visualizzare una o tutte queste categorie di messaggi. I messaggi visualizzati sono codificati a colori per semplicità: blu per le informazioni, giallo per gli avvisi e rosso per gli errori. Questo permette agli utenti di decidere rapidamente cosa visualizzare e anche di attribuire la priorità ai messaggi di errore rispetto agli avvisi e alle informazioni.

Conclusione

Il debug in-system di SBC negli impianti industriali può richiedere molto tempo, specialmente se coinvolge più SBC da programmare e testare. Inoltre, non è sempre pratico visitare ogni singolo luogo. Come mostrato, il debug remoto via Wi-Fi mediante dispositivi come CodeGrip e il software associato consente di risparmiare tempo e migliorare la produttività.

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 Digi-Key Electronics o le sue politiche.

Informazioni su questo autore

Bill Giovino

Bill Giovino è un ingegnere elettronico con un BSEE ottenuto a Syracuse University, ed è uno dei pochi ad essere passati con successo da progettista, a ingegnere delle applicazioni sul campo, al marketing tecnologico.

Da oltre 25 anni, Bill promuove le nuove tecnologie per un pubblico tecnico e non tecnico a nome di molte aziende, tra cui STMicroelectronics, Intel e Maxim Integrated. In STMicroelectronics, Bill ha contribuito a guidare i primi successi dell'azienda nel settore dei microcontroller. Con Infineon, Bill ha orchestrato i primi successi di progettazione di microcontroller dell'azienda nel settore automotive statunitense. In qualità di consulente di marketing per la sua società CPU Technologies, Bill ha aiutato molte aziende a trasformare prodotti di secondo grado in storie di successo.

Bill è stato uno dei primi ad adottare l'Internet delle cose, compresa l'integrazione del primo stack TCP/IP completo su un microcontroller. Bill è fedele al motto "Le vendite guidate dall'educazione" e tiene molto alla crescente importanza di comunicazioni chiare e ben scritte nella promozione di prodotti online. È moderatore del famoso gruppo Sales & Marketing di LinkedIn Semiconductor e parla correntemente di B2E.

Informazioni su questo editore

Editori nordamericani di Digi-Key