Gli ambienti di Test Manager sono costituiti da un insieme di tool progettati per gestire in modo coerente tutte le componenti che vengono a comporre una applicazione di test. In ultima analisi i Test Manager gestiscono processi di eccitazione segnali ed acquisizione dati dalle UUT specifiche che gestiscono. Le misure acquisite sono analizzate alla luce di parametri di accettazione o di confronto con stimoli noti e contribuiscono a compilare report che descrivono l’integrità o meno della UUT stessa.

L’elemento rilevante di un sistema strutturato di Test Manager è il fatto che tutte le operazioni sopra descritte vengono ad essere svolte da moduli organizzati in una struttura gerarchica che si pone l’obiettivo di ottimizzarne le prestazioni ed il riutilizzo. Il livello più immediato fra i moduli presenti consiste di “moduli codice” scritti nell’ ADE (application development environment) prescelto per il progetto in esame (LabVIEW, LabWindows CVI, Microsoft Visual Basic).


Per accedere al livello di controllo e di acquisizione dati dagli strumenti e dalle interfacce di I/O disponibili questi “moduli codice” accedeono a servizi o driver specifici (DAQmx, IVI, NI-488). Il livello piu’ basso della architettura preved i sensori e gli attuatori che si interfacciano direttamente alla UUT.

SIDeA per i propri sistemi ATE utilizza il prodotto TestSTAND della National Instruments

L’elemento centrale nella architettura NI TestSTAND è costituito dall’ NI TestSTAND Engine, che e’ un potente engine di test con struttura multi thread che si presenta agli altri ambienti di programmazione attraverso una interfaccia ActiveX/COM API. Questa interfaccia consente di poter accedere alle sue risorse mediante un qualsivoglia linguaggio (o attraverso l’uso contemporaneo di differenti linguaggi) e utilizzando le circa 1400 funzioni interne esportate.

L’engine gestisce in modo nativo il concetto di “test limit” consentendo cosi di non dover sviluppare questa peculiarità nel codice applicativo del sistema. Inoltre grazie al fatto che il test dei limiti non risulta presente nel codice di test questo consente di riutilizzare il codice stesso in differenti ambiti. Inoltre l’engine presenta delle strutture interne di condizionamento del flusso dei test analoghe alle strutture di flusso condizionato di esecuzione di un qualsivoglia linguaggio.

L’astrazione tipica dell’NI TestSTAND Engine e’ ben descritta anche dal concetto di “process module” che svolgono la funzione di disporre di una modularità di livello superiore fra il codice di test e le funzioni di sistema che questo richiama.

L’editor di sequenza fornisce un ambiente semplice ed intuitivo (con la sua capacità di svilupparsi ed organizzarsi in sottoparagrafi di test rispondenti tipicamente all’organizzazione di un documento di collaudo) per lo sviluppo ed il debug delle procedure di test che utilizzano i moduli sopra citati. Il processo di debug comprende la gestione di breakpoint, single step, tracing, display di variabili e di espressioni durante l’esecuzione.

Fra i passi di test assume particolare rilievo lo step definito “Call Executable”, mediante cui risulta possible all’interno di una procedura di test definire un host differente da quello dove risiede l’interfaccia operatore dove far eseguire le procedure di generazione stimoli o di acquisizione dati. Tipicamente questo è il passo di test utilizzato ed alla base di sistemi di tipo distribuito su di una rete locale.