Un MUST come Punto di Partenza - Modello Unificato Sistema di Test

Author(s):
F. Ricciato - SELEX COMMUNICATION
M. Sperati - SELEX COMMUNICATION
M. Pizzotti - SELEX COMMUNICATION
S. Murciano - SELEX COMMUNICATION
M. Monti - SELEX COMMUNICATION
A. Levrieri - SELEX COMMUNICATION
E. Sbaraglia - SELEX COMMUNICATION

Industry:
Government/Defense, Aerospace/Avionics

Products:
Data Acquisition, GPIB, LabVIEW, High-Speed Digital I/O, NI TestStand

The Challenge:
Realizzare una stazione di collaudo (Automatic Test Equipment - ATE) per l’interrogatore IFF EFA che definisca e impieghi un modello standard ed incrementale di collaudo. L’obiettivo primario è quello di estendere il modello in questione alle linee di produzione Selex Communications.

The Solution:
Sviluppo di un ATE basato su un modello concettuale standardizzato. Tale modello permette, attraverso un database (DB), sia la gestione delle informazioni relative alle procedure di collaudo sia la gestione dell’insieme dei dati prodotti. L’architettura di DB proposta permette, inoltre, l’impiego e la gestione delle differenti piattaforme di sviluppo presenti sulla linea di produzione. Sono, quindi, realizzate e garantite: -scalabilità della stazione di collaudo in relazione a numero e tipologia di collaudi eseguibili e/o eseguiti; -tracciabilità dei test effettuati per le varie unità nel ciclo di vita della stazione; -portabilità su differenti piattaforme di sviluppo; -possibilità di disporre dei risultati di test per poter eseguire controlli statistici e/o di correlazione; -necessità di generare report di collaudo conformi ai form contrattuali per i test di Acceptance Test Procedure (ATP); -modularità della configurazione in catene master/slave di più stazioni di collaudo (es. environmental stress screening di differenti tipologie di collaudo in unico ambiente) Si prevede, inoltre, l’uso di standard di riferimento consolidati quali DBMS MS SQL Server, NI TestStand, NI LabVIEW nell’ottica di garantire: portabilità, scalabilità e riusabilità di quanto sviluppato.

Breve riassunto
Viene analizzata l'architettura di una stazione di collaudo che possa essere utilizzata come modello per lo sviluppo di stazioni di collaudo incrementali caratterizzate da un numero ed una tipologia di collaudo variabili. Ciascuno step di collaudo può essere, infatti, ripetuto per cicli più o meno lunghi a seconda della fase di produzione - funzionale, troubleshooting o environmental stress screening – ed, eventualmente, su più unità in parallelo.
Particolare attenzione viene posta nella gestione e archiviazione dei dati caratteristici della stazione di collaudo, in modo da garantire sia la tracciabilità dei test effettuati sia la riproducibilità del set-up della stazione.
Viene, infine, analizzato come l'uso di un DBMS permetta di associare ad unità (o gruppi di unità correlate) i risultati delle misure di stazioni di vario tipo, in modo da rendere le unità stesse automaticamente tracciabili all'interno di una vasta area di test.

Who wants to have a model? (Unified??)
La realizzazione di una stazione di collaudo automatico non è una cosa semplice:
Occorre:
 mettere a punto una serie di sequenze di misura che richiedono l'utilizzo contemporaneo di strumentazioni complesse;
 prevedere la parametrizzazione delle misure stesse;
 realizzare un'interfaccia operatore efficiente ed una reportistica chiara ed univoca;
 garantire la manutenzione ed il corretto aggiornamento dei dati di collaudo e dei risultati relativi anche per diversi anni;
 garantire l’operatività della stazione di collaudo adottando tecniche di self-calibration o self-test ed auto-diagnostica.
Infatti, le misure da implementare su una singola stazione sono, talvolta, dell'ordine delle centinaia e presentano, per loro natura, caratteristiche differenti tra loro.

Utilizzare una stazione di test in uno stabilimento non è una cosa semplice:
Occorre:
 addestrare il personale;
 manutenere l'HW ed il SW della stazione;
 raccogliere e tracciare i risultati dei test ottenuti sulla varie unità.
Infatti, le stazioni all'interno di uno stabilimento sono nell'ordine delle centinaia e presentano, per loro natura, caratteristiche differenti tra loro. Nello stabilimento Selex Communications di Cisterna di Latina sono presenti, infatti, circa 300 ATE attive.

Che cosa è allora desiderabile che sia presente in una stazione di test?

1. Per chi progetta (e mantiene) un ATE è necessario definire uno standard di sviluppo che garantisca che tutte le stazioni siano costruite con gli stessi componenti e nello stesso ambiente di sviluppo, in modo che non ci si debba trovare di fronte alla necessità di acquisire competenze impreviste e indesiderate.
2. Per chi utilizza l’ATE per le attività di produzione è fondamentale: standardizzare e documentare le interfacce al fine di agevolarne l’usabilità da parte del personale addetto; che i report prodotti siano il più possibile uniformi, ma anche facilmente configurabili dovendosi uniformare a modulistiche differenti.

Il MUST (Modello Unificato di Sistema di Test) è il modello di stazione che si prevede possa diventare lo standard di stabilimento.
Nel seguito ne saranno presentate le caratteristiche salienti, ma in quest’introduzione si vogliono sottolineare le seguenti considerazioni.
La stazione come 'sensore intelligente’. Con questo termine si indica un dispositivo più complesso di un trasduttore, in grado ad esempio di elaborare algoritmi, ovvero fornire informazioni sulla grandezza misurata, sul tempo di misura, sulle precisioni e sensibilità ottenibili e così via. Allo stesso modo il MUST è in grado di fornire informazioni sul tipo di misure e test realizzabili, sui set e sulle calibrazioni della strumentazione presente, sui cicli di attività e sulle unità trattate.
Approccio bottom-up. Nell'automazione del ciclo produttivo dello stabilimento la realizzazione di questo tipo di stazione di test rappresenta il tipico approccio bottom-up. Riteniamo infatti che, in questo modo, si possa ottenere sia un ritorno a breve termine degli investimenti sullo sviluppo sia un rapido feed-back circa l'efficacia e l’usabilità del MUST.
Uso di tecnologie consolidate. Il MUST per IFF EFA si appoggia su NI TestStand e NI LabVIEW per quanto riguarda l'ambiente di sviluppo del software di misura e di test e sul DBMS MS SQL Server per quanto riguarda la gestione dei dati acquisiti dalle UUT. Come vedremo il MUST descrive stazioni pensate per la manutenzione evolutiva che possano adeguarsi e sfruttare le possibilità di misura del SW di base al momento della disponibilità di nuove versioni del SW o di re-ingegnerizzazioni delle UUT.
Everybody MUST get a DB
Ciascuna stazione dispone di una propria istanza del MUST_DB sul quale verranno conservate tutte le informazioni relative all’unità trattate, ai tipi di test effettuati o effettuabili dalla stazione stessa, alle impostazioni della strumentazione presente nella stazione ecc. In particolare le informazioni gestite dal MUST_DB permettono di:
1. Definire il tipo di misure in linea di principio eseguibili su ciascuna stazione.
2. Tenere traccia delle unità (eventualmente di vari modelli) passate per la stazione durante il loro ciclo di vita.
3. Definire i modelli di report prodotti dalla stazione in conseguenza dei test effettuati.
4. Conservare i risultati delle misure effettuate sulle varie unità.
5. Fornire un’interfaccia comune verso livelli più alti del sistema informativo aziendale, (DB di reparto, di stabilimento ecc.).

Il modello dei dati
Ciascun MUST_DB gestisce i dati provenienti dall'attività di una stazione di test complessa, quindi il DB deve essere adattabile a tipi diversi di stazione destinati al test di tipi diversi di dispositivii e deve gestire i risultati delle misure effettuate dalla strumentazione che costituisce la stazione nella maniera più uniforme possibile, trattandosi, in definitiva, comunque di misure.
Vi sono quindi due classi d’informazioni che concorrono a definire MUST_DB: i metadati, che descrivono le tipologie di UUT trattate, la natura delle misure effettuate e tutta la varietà di caratteristiche che intercorre tra stazioni di tipo diverso; i dati, che riportano i valori specifici delle grandezze di volta in volta misurate
Queste due classi sono destinate, ovviamente, ad utilizzatori diversi che hanno scopi diversi, pertanto si può affermare che:
• i metadati sono d’interesse dal punto di vista della stazione e sono letti dal software della stazione stessa per costruire l'interfaccia operatore sulla quale si seleziona l'elenco dei test con i relativi parametri, si segue lo svolgimento del test e si decide il tipo di report da generare al termine della prova;
• i dati sono d’interesse dal punto di vista della UUT e verranno letti dai tecnologi che seguono il ciclo di vita delle unità e dai vari SW di benchmark. In questo caso la stazione è vista il più possibile come un dispositivo unico e chiuso che fornisce informazioni sulla UUT.

L'unico tipo dati gestito nel MUST_DB è il Tag che contiene, oltre al valore della grandezza misurata (dato), un descrittore (metadato) che fornisce informazione sul tipo e sulla natura di tale grandezza. Volendo un termine di paragone si può pensare al Tag come ad un’evoluzione del tipo variant usato da Microsoft nella tecnologia OLE (e non solo).
Le classi di dati riconosciute dalla MUST IFF EFA, ad esempio, riguardano:
• UUT - Anagrafica, revisione e info sulle UUT trattate dalla stazione durante il suo funzionamento;
• SW di misura - Identificativo, revisione e descrizione del SW di test presente nella stazione, come ad esempio procedure TestStand, file eseguibili, DLL, file di inizializzazione e configurazione, modelli di report in formato XML ecc;
• Input - Valori di set e configurazione della strumentazione presente nella stazione durante l'esecuzione dei diversi test;
• Output - Risultati delle misure ottenute durante l'esecuzione dei test sulle varie UUT;
• HW di misura - Descrizione dell’HW strumentale presente sia standard che custom, delle singole opzioni disponibili, delle release fw, dei dati di calibrazione.

Oltre alle classi di dati i tag specificano anche il tipo di dato contenuto; sempre nel caso MUST IFF EFA sono previsti i tipi scalare, vettore, matrice e stringa.
L’inserimento di nuove caratteristiche sul DB richiede l’aggiunta di nuovi tag o d’ulteriori tipi dati sulle tabelle già esistenti piuttosto che l’inserimento di nuove colonne, permettendo una maggiore scalabilità della stazione MUST: non è necessario, quindi, che la struttura del DB preveda a priori il tipo d’informazioni da trattare con il rischio d’incompatibilità nei confronti di sviluppi successivi.
Oltre alla descrizione vi è, ovviamente, l'insieme dei dati gestiti nel MUST DB. La descrizione in forma entità – relazione del DB è mostrata nella Figura 1.

Le entità di partenza sono le UUT ed il SW (il software è lo strumento); del resto sono queste le entità d’interesse dal punto di vista della gestione del prodotto e della gestione del processo di produzione.
L'entità TEST tiene traccia dell'esecuzione di un certo numero di procedure SW su una specifica UUT in una determinata data. Ovviamente, sono possibili esecuzioni di procedure diverse sulla stessa UUT, nel corso del suo ciclo di vita: il MUST DB terrà traccia di tutti i test effettuati nel tempo.
Le entità PRESET e RESULTS, infine, contengono i valori di input e di output prodotto per ciascun test dalle procedure SW applicate.
Volendo condensare in una sola frase la struttura dati mostrata nella Figura 1 si potrebbe dire:
“Ciascuna UUT, nel suo ciclo di vita, subisce diversi TEST, costituiti da varie procedure SW che richiedono gli opportuni PRESET e che produrranno i relativi RESULTS”.
E' davvero la descrizione essenziale del processo di testing di qualunque dispositivo in tutto il suo ciclo di vita.

Waiting for MUST IFF EFA

La stazione MUST che realizza il caso d’implementazione in esame deve collaudare l'unità IFF (Identification Friend or Foe) SIT 435/5 progettata e prodotta dalla Selex-comms. Una visione d'insieme della stazione è mostrata in Figura 3. Come si vede si tratta di un oggetto piuttosto standard: un PC dotato d’interfaccia AIM-1553 e NI-GPIB attraverso le quali comunicano sia con la UUT che con la strumentazione di misura ed alimentazione della quale è riportato l'elenco.

Figura 3

 AGILENT 6812B AC POWER SOURCE
 AGILENT E4438C RF GENERATOR
 LECROY WR 6050 DIGITAL SCOPE
 AGILENT 53131A COUNTER
 AGILENT E4418B POWER METER

Il PC industriale utilizzato è un Pentium IV con SO Windows XP, con 1 GB di Ram, su chassis19’’, equipaggiato con le seguenti schede:
- NATIONAL INSTRUMENTS IEEE-488 NI PCI-GPIB
- AIM 1553 API-1553-1M
- SEALEVEL HI SPEED SERIAL BOARD 5101
- NATIONAL INSTRUMENTS DIGITAL INPUT OUTPUT NI PCI-DIO-96
- NATIONAL INSTRUMENTS HI SPEED IO NI PCI-6534
- NATIONAL INSTRUMENTS PCI COUNTER NI PCI-6602
Come si vede si tratta di strumentazione adatta a misure relativamente standard. L'implementazione dei test, come si è detto, verrà realizzata in LabVIEW e la loro esecuzione verrà gestita attraverso TestStand. In questo paragrafo vogliamo mostrare come un sistema informativo di stabilimento potrebbe interrogare la stazione in merito alle informazioni presenti in essa. Ciascuna interrogazione che segue è una normale query SQL che sfrutta i metadati presenti nei tags. Al di là dei dettagli, vogliamo sottolineare come le informazioni siano disponibili e facilmente accessibili nel MUST.
Ovviamente esistono diversi livelli di accesso alle informazioni, in tal modo avremo dei set di query preimpostate per degli utenti generici, e la possibilità di editare delle procedure per i diversi profili.

Informazioni sul SW presenti nella MUST IFF
Nella Figura 3 è mostrata l’interfaccia per l’interrogazione del MUST_DB della IFF. Come si vede il pannello permette l’uso di comandi SQL. Nella Figura3 si riporta il pannello utilizzato dall’amministratore della stazione: ovviamente il pannello per l’operatore prevede una serie di interrogazioni predefinite richiamabili con opportuni pulsanti.

select distinct tagname from MUST_Tags where tagio>=40 and tagio<50
tagname
--------------------------------------------------
Description
Own
Owner
Path
Revision
Type

Come risultato della query si ottiene l'elenco dei nomi dei tag relativi ai componenti SW della stazione. Una seconda query fornirà allora l'elenco del nome dei moduli SW presenti:

select distinct Modname from ATE_SW order by ModName
Modname
--------------------------------------------------
HTML_ATPReport
HTML_BurnInReport
HTML_FullReport
MUST_ATP
MUST_BurnIn
MUST_Report

Volendo si potrebbe interrogare la stazione per capire di che moduli si tratta. Scopriremmo che i primi tre sono dei template HTML per i report, il quarto ed il quinto sono procedure TestStand per il Burn In e l'ATP delle UUT SIT 435/5 mentre il sesto è un applicativo per la generazione dei report a partire dai template HTML e dal contenuto della tabella RESULTS.

Un'ultima query infine:

select swrev,strValue from ATE_SW where modname='ATE_Report' and (tagname='Revision' or tagname='description') order by swrev
swrev strValue
1 1.0.0
1 Genera i report partendo da diversi modelli HTML
2 1.1.0
2 Genera i report partendo da diversi modelli HTML o XML

mostra come vi siano due revisioni diverse di ATE_Report, la seconda delle quali in grado di utilizzare modelli di report a partire da file XML.

Si noti come il processo di manutenzione e aggiornamento delle MUST risulti facilmente pianificabile e gestibile in maniera automatica a livello di stabilimento anche in presenza di centinaia di stazioni di vari modelli e release.

Informazioni sulle unità SIT 435/5 collaudate dalla MUST IFF
Non può mancare un esempio di interrogazione riferito alle informazioni sulle unità: del resto le stazioni esistono come ausilio alla progettazione e produzione e non viceversa.

SELECT ModName,acqDate,strValue FROM MUST_UUT where tagname='SN' order by modname
ModName acqDate strValue
-------------------------------------------------- --------------------------- ----------
SIT 435/5 2007-02-10 00:00:00.000 ABC123
SIT 435/5 2007-02-12 00:00:00.000 ABC123
SIT 435/5 2007-02-10 00:00:00.000 ABC124
SIT 435/5 2007-02-10 00:00:00.000 ABC125
SIT 435/5 2007-02-18 00:00:00.000 XYZ100
SIT 435/6 2007-02-15 00:00:00.000 XYZ100
SIT 435/6 2007-02-15 00:00:00.000 XYZ101
SIT 435/6 2007-02-15 00:00:00.000 XYZ102
SIT 435/6 2007-02-15 00:00:00.000 XYZ102
SIT 435/6 2007-02-15 00:00:00.000 XYZ103

Come si vede una SIT di tipo 5, quella con SN ABC123, e due SIT di tipo 6, con SN XYZ100 e XYZ102 sono state sottoposte due volte a Burn In a distanza di pochi giorni. Una seconda query fornisce:

SELECT Tagname,strvalue FROM MUST_UUT where UUTId=1
Tagname strvalue
-------------------------------------------------- ---------------------------
Notes BurnIn fail at 22th cycle
Rev Rev 12.3.7
SN ABC123
Rev Rev 12.3.8
SN ABC123

Come si vede l'unità SIT con SN ABC123 ha fallito il 22° ciclo del Burn In. Si deduce una riparazione della unità, con cambio di revisione che passa da 12.3.7 a 12.3.8. Non vi sono note sul secondo Burn In che si deduce superato con successo. Volendo avere una conferma è possibile interrogare la tabella MUST_Test, che contiene gli esisti dei vari test effettuati su tutte le stazioni. E’ possibile, in alternativa, consultare la tabella MUST_Results che contiene i valori delle singole misure effettuate su una UUT specifica.
Si noti ancora come sia possibile tracciare la storia di ciascuna UUT e delle varie attività di manutenzione e aggiornamento e/o modifiche effettuate nel loro ciclo di vita.

Never ending story
Si è analizzata la struttura di un modello di stazione di test che possa diventare lo standard di stabilimento della Selex-Comms di Cisterna di Latina e sono stati mostrati degli esempi d’interrogazione in merito allo stato delle UUT collaudate ed al contenuto SW della stazione stessa. Si vuole rilevare come queste informazioni acquistano tanto più valore quanto più si riferiscono a realtà di produzione caratterizzate da grandi numeri, sia per quanto riguarda la quantità d’unità prodotte sia per quanto riguarda la complessità delle attività di produzione.
Si vuole concludere citando tre circostanze nelle quali le stazioni di collaudo implementate secondo la strategia MUST possono rivelarsi particolarmente efficaci:
 Analisi statistica per il controllo qualità e di processo: ad esempio il controllo incrociato tra i risultati dei test realizzati da ciascuna stazione e la componentistica montata sulle varie unità. Il monitoring dei cosiddetti parametri spia, individuati nel set dei valori misurati durante alcuni dei test da eseguire, consente di fornire dei feedback sull’andamento dei processi produttivi.
 Controllo dello stato di calibrazione della strumentazione in uso nelle varie stazioni MUST: in ultima analisi anche le stazioni di calibrazione possono essere MUST. Non solo si avrebbe a disposizione la tracciatura degli interventi di calibrazione ma si potrebbe controllare lo stato di calibrazione run-time controllando la presenza di eventuali derive nelle misure sulle UUT effettuate durante l'attività delle varie stazioni.
Allocazione delle risorse e pianificazione: in ogni momento è possibile tracciare il tempo d’occupazione per ciascuna stazione in relazione alle unità trattate. Dal momento che non è infrequente che una stessa stazione possa trattare unità di tipo diverso, le informazioni relative alle durate dei test possono essere usate per ottimizzare i piani di attività produttiva a livello di stabilimento.

Browse All Case Studies »