Se si effettua una ricerca su "Hardware-in-the-Loop" (HIL) testing, si trovano frequentemente esempi di sistemi complessi in tempo reale. Questo articolo di National Instruments, ad esempio, fornisce una buona spiegazione e contesto su cosa sia l'hardware-in-the-loop (HIL) e offre un esempio di test delle unità di controllo elettronico all'interno di un'automobile. In questo articolo, ci concentreremo su una versione più piccola e più facilmente gestibile dei concetti di test HIL.
Ai fini di questo articolo, definiremo il test hardware-in-the-loop in modo un po' diverso rispetto al modo in cui viene presentato convenzionalmente (ad esempio, nelle applicazioni automobilistiche). Osserviamo tre diversi livelli di complessità quando si tratta di testare un prodotto.
In questa forma di test, un ingegnere testerà manualmente il dispositivo. Questo può consistere nel sondare punti di test su una scheda con un multimetro digitale, osservare le forme d'onda su un oscilloscopio o analizzare manualmente un readout di telemetria su uno schermo di computer. L'ingegnere testerà il prodotto tramite test di verifica del design manuale.
Questa configurazione di test esegue le stesse misurazioni e verifiche normalmente effettuate da un ingegnere, ma viene eseguita da un computer in modo automatizzato. Il computer host comunica direttamente con gli strumenti (ad esempio, multimetri, oscilloscopi, ecc.), analizza la telemetria dal dispositivo e poi verifica il set di test basato sui criteri stabiliti dall'ingegnere.
Il testing Hardware-in-the-Loop porta il testing automatizzato a un nuovo livello aggiungendo stimoli extra per simulare un'applicazione nel mondo reale. Ad esempio, il dispositivo sotto test (DUT) potrebbe avere una serie di sensori che richiedono eccitazione. L'attrezzatura di test simulerebbe l'altro capo di quei sensori per eccitare il lato sensore del DUT. Un altro esempio potrebbe essere qualcosa di semplice come inviare traffico RS-422 in un ricevitore RS-422 sul DUT. L'idea è che siamo in grado di introdurre nuovi stimoli nel DUT, leggere la telemetria dal computer host e aggiustare i nostri test in modo appropriato se necessario (ad esempio, inviare traffico RS-422 più veloce e maggiore dopo aver superato un test iniziale).
In base all'applicazione, può essere chiaro il motivo per cui si sceglierebbe di adottare il testing hardware-in-the-loop rispetto al testing automatizzato (e certamente al testing manuale). Se si sta cercando di integrare un sistema complesso o (sistemi di sistemi), con molta stimolazione esterna richiesta, un semplice test di verifica automatizzato non sarà sufficiente. Prendiamo in considerazione un semplice caricabatterie. Anche se si potrebbe simulare una fonte di alimentazione, un carico e una batteria per testare il circuito di controllo (fisicamente o tramite software), sarebbe più realistico utilizzare un'alimentazione reale, una batteria e un carico per testare il progetto. Inoltre, se si può automatizzare questo processo, i vostri ingegneri possono ora dedicare il loro tempo allo sviluppo piuttosto che al testing.
Quando si decide se adottare il testing hardware-in-the-loop si dovrebbero considerare i seguenti fattori:
Una volta considerati questi ed altri fattori, potete iniziare a prendere una decisione su se continuare con i test manuali o investire nei test automatizzati/hardware-in-the-loop.
Basandomi sulla mia esperienza, ho trovato che, senza dubbio, il modo più semplice per entrare nei test hardware-in-the-loop sarebbe utilizzare un framework di test tutto incluso come quello fornito da National Instruments (NI). NI ha una piattaforma hardware/software tutto incluso che è plug and play. Ecco alcuni pro e contro da considerare quando si valuta un framework tutto incluso:
Durante il tempo che ho trascorso lavorando su sistemi complessi, LabVIEW è stato il mio punto di riferimento per i test automatizzati, inclusa la costruzione di un'intera pipeline di Integrazione Continua e Distribuzione Continua per i progetti e i VI di LabVIEW. Man mano che sono passato a sistemi più piccoli che richiedevano un supporto più semplice hard-in-the-loop, ho iniziato a migrare verso hardware personalizzato o commerciale off the shelf (COTS) e script Python (utilizzando il pytest framework). Ancora una volta, tutto dipende dall'applicazione e, come detto prima, il tempo di test, la ricorrenza del test e le attrezzature di test sono i fattori principali che guidano questa decisione.
In questo articolo, abbiamo esaminato il concetto di test hardware-in-the-loop e come si differenzia sia dal test manuale che da quello automatizzato. Abbiamo anche esaminato i vantaggi dell'adozione del test hardware-in-the-loop e come valutare se è davvero ciò di cui l'utente ha bisogno. Infine, abbiamo discusso alcuni modi per iniziare. Sebbene il test hardware-in-the-loop possa non essere adatto a tutti, è chiaro che per l'applicazione giusta l'investimento ripagherà molto rapidamente.
Vorresti scoprire come Altium può aiutarti con il tuo prossimo design di PCB? Parla con un esperto di Altium o scopri di più sui principali problemi di DFM e le loro soluzioni.