Un sensore continua a inviare un valore plausibile, ma non segue più il movimento. Il controllore principale smette di rispondere. Due misure scompaiono mentre l'attuatore sta raggiungendo la posizione richiesta. Sono condizioni che un sistema di controllo deve gestire, e che durante una prova ordinaria possono essere difficili da riprodurre.
SLX ResilienceLab è il nuovo dimostratore desktop di Silicon LogiX per esplorare questi casi con un banco prova interamente software. Una valvola motorizzata virtuale, tre sensori di posizione e due controllori C++ permettono di osservare cosa accade, introdurre guasti e conservare i risultati. Il progetto mostra come costruire un ambiente di test dedicato al controllo di un prodotto.
Per chi sviluppa schede, firmware o macchine, l'utilità è concreta: ripetere una condizione critica, confrontare due versioni del controllo e discutere il comportamento sulla base di misure, tempi ed eventi registrati. Contattami per valutare un banco prova per il tuo prodotto.
Una valvola virtuale, con decisioni calcolate dal software
L'operatore imposta l'apertura, per esempio l'80%, e segue il movimento della valvola nelle viste 3D normale e sezionata. La schermata mantiene distinti apertura richiesta, posizione reale del modello, tre letture dei sensori e misura utilizzata dal controllo. Questa separazione permette di vedere quando una lettura smette di rappresentare il movimento.
I controllori principale e di riserva eseguono realmente codice C++. Ricevono misure e messaggi attraverso una comunicazione virtuale e calcolano il comando del motore. Non accedono direttamente alla posizione reale della pianta o ai guasti impostati dall'operatore: devono reagire usando le informazioni ricevute. Heartbeat, comandi e misure attraversano il trasporto, sul quale si possono introdurre ritardi e perdite.
La ridondanza confronta le letture con soglie, tempi di conferma e limiti di validità configurabili. Con due misure attendibili può escludere un sensore discordante; quando le informazioni non bastano, richiede l'arresto. Un arbitraggio autorizza un solo controllore alla volta a comandare il motore, anche durante il passaggio alla riserva.
Tre prove, tre risposte osservabili
La versione dimostrativa include tre scenari pronti. Il grafico seguente deriva dai tracciati prodotti dall'esecuzione della versione 0.4.0, con apertura richiesta dell'80%, durata di 12 secondi simulati, passo di 20 ms e seed 2407. Rappresenta risultati del modello software nelle condizioni indicate.
- Sensore bloccato. S1 si congela a 1,60 s. La prima segnalazione di isolamento arriva a 2,12 s, dopo 0,52 s; il principale isola S1 a 2,14 s. Il controllo continua con S2 e S3 e termina con un errore di posizione di circa 0,14 punti percentuali.
- Perdita del principale. Il controllore si ferma a 2,00 s. Il watchdog arresta il motore a 2,24 s e l'arbitraggio autorizza la riserva a 2,58 s: il subentro avviene dopo 0,58 s. La valvola riprende il movimento e termina con un errore di circa 0,16 punti percentuali.
- Perdita delle misure. S1 e S2 vengono scollegati a 2,00 s. Le letture scadono a 2,40 s e l'arresto del motore viene applicato a 2,42 s. La posizione finale è il 51,48%: l'esito atteso è fermarsi per mancanza di informazioni sufficienti.
Il report conserva errori di posizione, rilevamenti, passaggi alla riserva e arresti. Gli export HTML, JSON e CSV permettono di consultare le evidenze e utilizzarle in altri strumenti. Configurazione, sequenza dei guasti e seed consentono di rieseguire lo scenario e confrontare due versioni del controllo nelle stesse condizioni simulate.
Perché questo approccio è utile nello sviluppo embedded
Il principio è quello del software-in-the-loop: eseguire codice compilato sul computer e sottoporlo a ingressi di prova ripetibili. La documentazione MathWorks su SIL e PIL descrive come questi ambienti aiutino a verificare il comportamento del codice durante lo sviluppo. ResilienceLab applica questo principio con una propria architettura C++ e Qt Quick.
La fault injection rende esplicita la condizione da verificare. Oltre agli scenari pronti, il laboratorio consente deriva progressiva dei sensori, disconnessioni, comunicazione intermittente e blocco dell'attuatore. In un banco fisico, i guasti elettrici richiedono interfacce dedicate: la descrizione NI delle unità di inserzione guasti illustra questo livello di prova. Nel dimostratore, i guasti agiscono sul modello e sui messaggi.
Il vantaggio per un progetto è poter fissare prima i criteri di verifica: quante misure servono per continuare, entro quanto rilevare una perdita, chi è autorizzato a comandare e quali eventi devono essere conservati. La stessa prova può poi diventare un controllo di regressione quando cambia il firmware.
Dal controllo sul PC alla connessione con una scheda
Il laboratorio si usa anche in modalità live: si modifica l'apertura e si bloccano, scollegano o ripristinano i sensori durante il movimento. Le azioni vengono registrate per poter ricostruire la prova. La modalità 1× segue il tempo del PC; il sistema operativo desktop non garantisce scadenze temporali rigide.
Per integrare codice del cliente è disponibile un'interfaccia DLL con API C che può sostituire il calcolo del comando motore sul PC. Il banco mantiene la gestione delle misure, degli heartbeat e dell'arbitraggio. Un'API locale con messaggi JSON permette di leggere misure e diagnostica, cambiare il setpoint e richiedere guasti; sono previste connessioni TCP locale e USB/seriale. L'integrazione con una specifica scheda richiede l'implementazione e la verifica del relativo protocollo nel firmware.
Un passo successivo è il hardware-in-the-loop: il controllore fisico viene collegato a un ambiente simulato. Come spiega NI nella panoramica HIL, servono anche gestione temporale e interfacce di ingresso e uscita adeguate. Il pilotaggio della pianta da parte del firmware su scheda è un'integrazione da sviluppare; ResilienceLab offre oggi il dimostratore software e i punti di collegamento.
Tre sensori bloccati sullo stesso valore possono continuare a concordare. Il voto di maggioranza, da solo, non dimostra che la valvola si stia muovendo: nel laboratorio una richiesta di movimento attiva anche il controllo dell'avanzamento misurato. È un esempio del motivo per cui un banco va progettato intorno ai guasti e ai requisiti del prodotto. SLX ResilienceLab è un dimostratore software senza certificazioni di sicurezza; non costituisce una validazione di una valvola fisica o del firmware di un cliente.
Un banco prova progettato per il tuo prodotto
Silicon LogiX può realizzare un ambiente dedicato a una scheda o a un sistema di controllo: modello della pianta, adattatore per le interfacce del prodotto, scenari di guasto, criteri di accettazione e report. Il punto di partenza può essere una funzione concreta, come verificare la reazione a un sensore fermo o a una comunicazione interrotta.
Descrivimi il prodotto, le interfacce disponibili e il comportamento che vuoi verificare. Se hai già una scheda, indica anche protocollo, segnali e tempi richiesti. Possiamo definire una prima prova rappresentativa e il percorso di integrazione. Parliamo del tuo banco di test.
Per esplorare il progetto sono disponibili la release portatile Windows v0.4.0 e la documentazione su GitHub. Il core proprietario è distribuito come librerie compilate con licenza di valutazione Silicon LogiX; interfaccia ed esempi di integrazione sono separati.
