73
- ELETTRONICA OGGI 433 - GENNAIO/FEBBRAIO 2014
EDA/SW/T&M
VERSION CONTROL
Sfortunatamente, nessuno conosce effettivamente dove
siano localizzati tutti i dati relative al progetto.
Una volta che le società si sono rese conto di questo pro-
blema, si sono impegnate a conservare competenze e cono-
scenze (knowledge) dell’azienda all’interno di un database
dedicato. I team preposti alla progettazione hardware hanno
incontrato qualche difficoltà nell’implementazione del con-
trollo della versione, poiché principi e tool sono largamente
basati su principi propri dell’ingegneria del software. In
assenza di un sistema di controllo della versione integrato
nei loro tool EDA, i progettisti hardware sono andati alla
ricerca di programmi per il controllo della versione indipen-
denti, dotati di funzionalità di check-in e check-out. Le solu-
zioni di tipo non-integrato non sono comunque efficaci in
quanto il singolo progettista e/o il responsabile non possono
effettuare un confronto visivo con lo schema circuitale e la
scheda PCB nel passaggio da una versione alla successiva.
Utilizzando un software EDA che integri il controllo della
versione, i membri del team possono vedere lo stato di
tutti i modelli, gli aggiornamenti effettuati per garantire la
conformità ai relativi standard e le modifiche apportate a
ogni progetto. Tutti i membri del team sono quindi avvertiti
automaticamente nel momento in cui viene apportata una
modifica. In campo software, un responsabile o un membro
del team può far girare un “differencing tool” (ovvero un tool
di tipo grafico in grado di rilevare le differenze) nel software
in via di sviluppo per identificare, analizzare e archiviare
(commit) le modifiche tra le versioni.
I tool EDA, in ogni caso, producono un’uscita grafica e
binaria, mentre il codice software genera un’uscita di tipo
testuale. Per questo motivo l’identificazione delle modifiche
hardware attraverso un tool non integrato di tipo testuale
è un’operazione difficile e soggetta a errori. Responsabili e
progettisti devono poter vedere le modifiche in modo grafi-
co, integrarle nel progetto e archiviarle. In sintesi, non è pos-
sibile svolgere alcuna di queste attività utilizzando sistemi di
controllo della versione non integrati.
Sfruttare le “best practice”
per la progettazione hardware
Le procedure di progettazione dell’hardware devono esse-
re cambiate a causa del costante aumento della pressione
di natura competitiva, come chiaramente evidenziato dal
rapporto “Need to Save PCB Design Time?” redatto dalla
società di ricerche Aberdeen Group. Questo report è basato
su interviste e sondaggi che hanno interessato 133 aziende
operanti nel settore elettronico. Una volta raccolti tutti i dati,
i ricercatori hanno stilato un giudizio relativo alla competiti-
vità delle società coinvolte nell’indagine. Essi hanno suddi-
viso i partecipanti in tre categorie: le migliori (best-in-class),
medie (average) e in ritardo (laggard).
Come riportato in figura 1
(1)
, ciascuna di queste tre catego-
rie nelle quali sono state catalogate le aziende evidenziano
livelli di prestazioni comuni relativamente a cinque parame-
tri chiave:
1. processo (approcci utilizzati per gestire i dati della sche-
da PCB);
2. organizzazione (a chi sono presentati i dati);
3. gestione della conoscenza (modalità di gestione della
conoscenza dei dati relativi alla scheda PCB);
4. gestione delle prestazioni (capacità di un’organizzazione
di misurare i propri risultati al fine di migliorare le procedu-
re dei gestione dei dati della scheda PCB);
5. tecnologia (utilizzo dei tool adatti per supportare la
gestione dei dati della scheda PCB).
Il controllo della versione, come evidenziato nel report di
Aberdeen Group, rientra nella categoria della “Gestione
della conoscenza”. In questa categoria, come si evince dalla
figura 1, rientrano tre voci:
1. sincronizzazione tra schema circuitale e layout della
scheda PCB;
2. sincronizzazione tra schema circuitale e BOM;
3. disponibilità del controllo della versione per ogni ele-
mento di dati sulla scheda PCB.
Qualsiasi software di controllo della versione di tipo auto-
nomo può eseguire le operazioni di check-in e check-out di
base. I team di progetto ben presto si rendono conto di non
poter bloccare (lock) in maniera automatica un file estratto
(checked-out) dal repository.
Ciò può provocare sovrascritture o perdita del lavoro fatto. I
membri del team non possono confrontare in maniera visiva
le revisioni nello schema circuitale o sulla scheda PCB. La
soluzione, inoltre, non dispone di funzionalità di gestione
dei dati integrate. L’integrazione (merging) del lavoro fatto
in collaborazione su differenti parti del progetto provoca
l’insorgere di ulteriori problemi la cui soluzione è molto
Fig.1–ConAltiumDesignerèpossibilecompletaretuttelefasi-Collabora-
Confronta-Unisci – di un progetto all’interno di un unico ambiente
