La gestione di una libreria ECAD è il controllo del dato componente usato per trasformare un requisito elettrico in una parte acquistabile, posizionabile, assemblabile e tracciabile. Una voce affidabile collega simbolo, pin mapping, footprint, modelli meccanici, part number interno, MPN approvati, stato lifecycle, regole di sourcing e prove di rilascio.
La libreria non deve per forza risiedere in un solo software. ECAD può essere autorevole per geometria e mapping, PLM per revisioni e approvazioni, ERP per stock/costo e procurement per fonti approvate. “Single source of truth” significa che ogni campo ha un owner e una sincronizzazione definita, non che tutti possano modificare tutto nello stesso database.
Per progettisti e NPI, l'obiettivo è riutilizzare dati verificati senza nascondere le eccezioni. Per procurement, è distinguere funzione ingegneristica, MPN equivalente e supplier approvato. Per qualità, ogni modifica deve avere motivazione, evidenza, impatto sui design rilasciati e possibilità di rollback.
Punti decisionali
- Separare il part number interno dai singoli MPN e dalle fonti di acquisto; sono oggetti con responsabilità differenti.
- Definire autorità per pinout, footprint, 3D, parametri, lifecycle, compliance, costo e supplier status.
- Rilasciare un footprint con package drawing revision, land-pattern rationale, pin-1/polarity evidence, process assumptions e review indipendente.
- Usare stati chiari: draft, in review, released, restricted/deprecated e blocked; “presente in libreria” non significa approved for production.
- Trattare PCN, NRND ed EOL come eventi con owner, scadenza, affected designs, stock decision e validation plan.
- Approvare alternative con form/fit/function più impatto di processo, firmware, qualità e supply chain; stesso valore/package non basta.
- Non aggiornare silenziosamente un design rilasciato quando cambia la libreria. La relazione deve essere versionata e l'adozione deve passare change control.
- Riportare DFM, defect Pareto, rework e failure analysis nel record sorgente, non soltanto nelle note del singolo progetto.
- Misurare qualità e servizio della libreria con errori evitati, tempi di approvazione per classe di rischio, duplicati, stale parts e closure delle azioni, non con il numero grezzo di componenti.
Contenuti
- Qual è il modello dati minimo?
- Quale sistema è autorevole per ogni campo?
- Come separare part number, MPN, AVL e supplier?
- Quali prove servono per simbolo e pin mapping?
- Come rilasciare un footprint producibile?
- Come controllare 3D, varianti e processi?
- Quale workflow usare per approvare una parte?
- Come gestire lifecycle, PCN ed EOL?
- Come approvare un componente alternativo?
- Cosa succede ai design già rilasciati?
- Come chiudere il feedback dalla fabbrica?
- Come migrare e auditare una libreria?
- Quali metriche sono davvero utili?
- Come esportare una baseline per la quotazione?
- Dove termina il supporto del produttore?
- Risposte per il team
Qual è il modello dati minimo?
Una voce production-ready deve descrivere identità, geometria, comportamento e stato commerciale senza confondere questi livelli. Il minimo dipende dal prodotto, ma il modello dovrebbe prevedere:
| Oggetto | Campi essenziali | Evidence/source |
|---|---|---|
| Engineering part | internal ID, description, class, lifecycle/use state | PLM/company rule |
| Symbol | pins, names/types, units, hidden pins e revision | datasheet + independent review |
| Footprint | pad map, land pattern, mask/paste, courtyard, height zones | package drawing + policy + process input |
| Mechanical model | body, origin, orientation, height and keep-out | supplier drawing/model + alignment check |
| Manufacturer part | manufacturer, exact MPN, package, ratings and datasheet revision | manufacturer evidence |
| Approved source | supplier/site, status, traceability and restrictions | procurement/quality approval |
| Lifecycle/compliance | dated status, source, risk and required action | manufacturer/approved data owner |
| Release record | state, revision, reviewers, evidence, exceptions and change history | controlled workflow |
Il record può includere simulation models, thermal pad rules, test notes o firmware driver quando necessari. Evitare campi senza owner o fonte: diventano presto dati decorativi.
Quale sistema è autorevole per ogni campo?
| Dato | Owner tipico | Sistema autorevole possibile | Consumer |
|---|---|---|---|
| Symbol/footprint revision | ECAD/library engineering | ECAD managed library o repository | schematic/layout, DFM |
| Internal part/release state | component engineering/PLM | PLM | ECAD, ERP, quality |
| MPN/AML | component engineering | PLM/component database | ECAD, BOM, procurement |
| Supplier/site approval | procurement + supplier quality | ERP/QMS | purchasing, traceability |
| Stock, price, MOQ/lead basis | procurement | ERP/sourcing system | planner, costed BOM |
| PCN/EOL action | component engineering + product owner | PLM/QMS workflow | affected products/projects |
| Manufacturing feedback | NPI/quality | QMS/issue system linked to library | librarian, design teams |
Ogni sincronizzazione deve definire direction, frequency/event, conflict handling, timestamp e failure alert. Copiare manualmente un valore in cinque sistemi senza ownership non crea ridondanza sicura: crea divergenza.
Come separare part number, MPN, AVL e supplier?
L'equivalenza ingegneristica e l'approvazione commerciale sono decisioni diverse.
- l'engineering part descrive la funzione e i vincoli che il design intende usare;
- l'AML/approved manufacturer list collega uno o più MPN valutati come possibili implementazioni;
- l'AVL o source list identifica supplier/site approvati per gli MPN, se il sistema aziendale usa questa distinzione;
- ERP conserva condizioni operative come stock, MOQ, prezzo, lead-time basis e ordini;
- una BOM rilasciata specifica se l'alternativa è libera, restricted, project-specific o vietata.
Non trasformare automaticamente un suggerimento del distributore in parte equivalente. Procurement può proporre un candidato, ma engineering/quality devono approvare gli impatti richiesti.
Quali prove servono per simbolo e pin mapping?
Il simbolo deve rappresentare il componente reale senza nascondere connessioni critiche. Verificare:
- exact MPN/package e datasheet revision usati;
- pin number, pin name, electrical type e no-connect;
- multi-unit/shared-power behavior e swapped gates/channels;
- exposed pad, thermal pad, center pad e sua funzione elettrica;
- pin 1, polarity, orientation e naming dei differential pairs/buses;
- power pins non invisibili quando nascondere la connessione crea rischio;
- mapping symbol-to-footprint con controllo indipendente;
- ERC exceptions documentate, non disabilitate globalmente.
La pagina schematic symbols tratta la costruzione grafica. Qui il focus è l'evidenza necessaria per dichiarare il simbolo rilasciato.
Come rilasciare un footprint producibile?
Un footprint è una decisione di assemblaggio basata su package, processo e obiettivo di saldatura. Conservare un land-pattern decision record.
| Controllo | Domanda | Evidence |
|---|---|---|
| Package source | Quale drawing/revision e quali tolleranze? | manufacturer drawing snapshot/reference |
| Pad geometry | Quale policy/standard e quale density/process goal? | calculation/generator record + exception |
| Mask/paste | Serve expansion, reduction, segmentation o via treatment? | stencil/assembly review |
| Courtyard/spacing | Include body, leads, pick/place, inspection e rework? | company rule + 3D/assembly check |
| Origin/orientation | Coincidono ECAD, centroid e assembly convention? | exported sample + polarity review |
| Thermal/exposed pad | Come si gestiscono paste, void goal, vias e solder wicking? | process-specific plan |
| Mechanical fit | Altezza, connector mating, keep-out e enclosure sono corretti? | 3D alignment + first article |
Non dichiarare “IPC compliant” senza identificare la policy applicabile, revision, density/process assumptions ed eccezioni. Il manufacturer recommendation può essere un input, non sempre l'unica risposta per ogni processo.
Come controllare 3D, varianti e processi?
Un singolo MPN può richiedere più representation soltanto quando cambia un vincolo reale. Esempi: hand-solder versus reflow footprint, connector con mating envelope, alternate body height, thermal option o different assembly side.
Non duplicare l'intero componente per ogni colore o supplier se symbol/footprint sono identici; usare relazioni e varianti governate. Al contrario, non forzare nello stesso footprint packages che sembrano simili ma differiscono per pad, exposed area, polarity o mechanical keying.
Il 3D model va controllato per units, origin, rotation, body height, seating plane, pin-1 e mating/keep-out. Un modello visivamente plausibile può comunque essere fuori scala o disallineato.
Quale workflow usare per approvare una parte?
| Stato | Uso consentito | Exit criteria |
|---|---|---|
| Draft | evaluation only | source package e owner presenti |
| In review | non per release senza eccezione | electrical, footprint, mechanical, sourcing review |
| Released | nuovi design secondo restrictions | evidence complete, approvals and revision frozen |
| Restricted/deprecated | existing use o approval-specific | replacement/action and affected users notified |
| Blocked/obsolete | no new release | disposition for open and released designs |
Separare creator e approver per oggetti ad alto rischio. Definire un percorso fast-track per prototipi con expiry, project scope e conversione obbligatoria a released o blocked; altrimenti le “temporary parts” diventano permanenti.
Il workflow deve restituire reason code e correzioni, non soltanto rifiutare. Un service target può variare per passivi standard, connector complessi, BGAs o safety-critical parts: evitare un unico tempo promesso per ogni classe.
Come gestire lifecycle, PCN ed EOL?
Uno status senza data, fonte e azione è insufficiente.
| Evento | Domanda immediata | Azione possibile |
|---|---|---|
| Datasheet/package update | pinout, package o ratings sono cambiati? | library review e design impact |
| PCN process/site/material | quali product/reliability/process assumptions cambiano? | qualification/FAI o documented no-impact |
| NRND | quali nuovi design devono evitarlo? | restrict new use e replacement search |
| EOL/last-time-buy | domanda, stock, lifetime e redesign window? | LTB, alternate qualification o redesign |
| Supplier availability alert | segnale temporaneo o rischio strutturale? | sourcing review, non geometry edit automatica |
| Compliance change | quali markets/products sono interessati? | quality/regulatory assessment |
Mantenere affected parts, affected BOM/designs, owner, due date, decision, evidence e closure. Il feed esterno accelera il rilevamento; non deve modificare automaticamente lo stato produttivo senza una regola approvata.
Come approvare un componente alternativo?
| Dimensione | Verifica |
|---|---|
| Form | package, pinout, height, polarity, marking and footprint |
| Fit | pad/process, assembly, enclosure, connector/mating and test access |
| Function | electrical ratings, tolerance, timing, analog/RF/power behavior |
| Process | MSL, reflow, cleaning, coating, programming and handling |
| Firmware | ID, driver, calibration, memory, boot and configuration |
| Quality/compliance | qualification evidence, traceability, change notice and market needs |
| Supply/commercial | source, MOQ/NCNR, lead basis, lifecycle and excess risk |
Definire se l'alternativa è approved globally, per product family, per revision o solo con deviation. La library relation deve conservare decision date, reviewers, evidence e revalidation triggers.
Cosa succede ai design già rilasciati?
Una libreria revisionata non deve mutare retroattivamente un prodotto senza change order.
| Tipo di modifica | Design draft | Design rilasciato |
|---|---|---|
| Metadata non funzionale | update controllato | update documentale se consentito |
| Lifecycle/source status | warning/action | product/procurement impact review |
| Symbol graphic only | optional refresh | di norma nessuna ECO elettrica |
| Pin mapping/electrical type | mandatory review | ECO, affected-net verification e re-release |
| Footprint/mask/paste | layout/DFM update | ECO + manufacturing/NPI validation |
| 3D/height/keep-out | mechanical refresh | MCAD/assembly impact and disposition |
| MPN/alternate relation | BOM review | approved change/deviation and qualification |
Conservare la library revision usata dal design o uno snapshot riproducibile. Un audit deve poter ricostruire ciò che fu realmente rilasciato, non soltanto mostrare l'oggetto corrente.
Come chiudere il feedback dalla fabbrica?
| Evidenza NPI/field | Possibile causa di libreria | Azione |
|---|---|---|
| Tombstone/open/bridge ricorrente | pad/paste/process assumption | compare design, stencil, placement e update rationale |
| Polarity/orientation escape | symbol/footprint/centroid/silkscreen ambiguity | correct mapping and inspection aids |
| Connector collision | wrong 3D, height or mating keep-out | model/footprint revision + affected-design search |
| Inaccessible test/rework | courtyard/keep-out incomplete | add process envelope or project constraint |
| Wrong purchased package | MPN/package/ERP mapping | master-data correction and containment |
| Repeated manual footprint edit | central object unusable | review exception and release reusable fix |
Collegare issue, project, component revision, lot/build evidence, root cause, containment, correction e affected-library objects. Non correggere il footprint solo perché il difetto è vicino al componente: prima separare design, process, material e handling causes.
Come migrare e auditare una libreria?
Migrare tutto in blocco senza classificazione trasferisce anche errori e duplicati. Procedere per rischio e utilizzo:
- inventory di parts, projects, duplicates, local objects e unsupported formats;
- define canonical IDs, states, field ownership e mapping rules;
- rank by usage, package complexity, product criticality e sourcing risk;
- pilot su una famiglia con import/export e design round-trip;
- validate symbol/pin, footprint, 3D, metadata e BOM output;
- compare released design outputs prima/dopo, senza auto-update silenzioso;
- quarantine uncertain parts e assegnare owner/due date;
- migrate in batches con rollback e exception log;
- audit access, synchronization failures e user adoption;
- retire old write paths soltanto dopo evidence di riproducibilità.
Il visualizzatore PCB, il visualizzatore Gerber e il visualizzatore BOM aiutano la review degli output, ma non sostituiscono source comparison e approval history.
Quali metriche sono davvero utili?
Usare un piccolo scorecard collegato al rischio:
- first-pass approval e rejection reasons per component class;
- turnaround time separato per rischio/complessità;
- duplicates, local/unreleased parts usate e stale records;
- library-caused escapes, respins, BOM corrections e factory defects;
- PCN/EOL actions aperte oltre due date;
- alternate approvals con evidence completo;
- percentuale di released designs riproducibili dalla revision registrata;
- factory feedback chiuso nella libreria oppure motivato come non-library cause.
Evitare vanity metrics come “numero totale di parti” o “automazioni eseguite” senza accuratezza, adozione e outcome.
Come esportare una baseline per la quotazione?
Il pacchetto di quotazione deve esportare una baseline, non una vista live non riproducibile. Includere:
- PCB revision, fabrication/assembly outputs e checksum/version package.
- BOM con internal part, exact MPN/AML, approved alternates, DNI/variants e procurement restrictions.
- Package/footprint notes critiche: polarity, exposed pad, paste, MSL/handling e special process.
- Centroid/orientation convention, assembly drawings e 3D/mechanical constraints.
- Sourcing responsibility, approved sources, consigned parts, traceability e substitution approval.
- DFM questions, deviation route, NPI quantity, FAI e sample requirements.
- Inspection/test scope, acceptance, raw records e failure reaction.
- PCN/EOL notification, excess/NCNR, material commitment e change-control terms.
Per i primi build, collegare prototipazione PCB e assemblaggio SMT allo stesso issue/feedback flow. Una correzione NPI approvata deve aggiornare il progetto e, se riutilizzabile, il master component.
Dove termina il supporto del produttore?
HILPCB può rivedere un pacchetto rilasciato per fabbricazione e assemblaggio, segnalare DFM/assembly questions e restituire evidence concordata dal prototipo o dalla produzione. Sourcing, alternate review, FAI, test e traceability entrano nello scope solo se descritti nella quotazione; il turnkey assembly non autorizza sostituzioni automatiche.
Il customer team resta owner di part numbering, library/PLM/ERP governance, electrical intent, lifecycle decisions, alternate qualification e propagazione delle modifiche ai prodotti. Per avviare una review si può usare il percorso RFQ con una baseline esportata e controllata.
Risposte per il team
Una libreria ECAD è solo un insieme di simboli e footprint?
No. Per uso produttivo deve collegare geometria e pin mapping a identità componente, MPN approvati, lifecycle, sourcing, stato di rilascio, revisioni ed evidenze.
Cosa significa davvero single source of truth?
Che ogni campo ha un owner e un sistema autorevole, con sincronizzazione e conflitti definiti. ECAD, PLM, ERP e QMS possono possedere dati diversi senza creare copie incontrollate.
Part number interno e MPN sono la stessa cosa?
Non necessariamente. Il part interno rappresenta una funzione/decisione aziendale; uno o più exact manufacturer part numbers possono essere collegati come implementazioni approvate con restrictions.
Un footprint del produttore può essere approvato senza review?
No come regola generale. È un input utile, ma vanno controllati package revision, process assumptions, pin-1, mask/paste, courtyard, orientation, 3D e compatibilità con il processo reale.
Basta dichiarare IPC compliance per un footprint?
No. Occorre indicare policy/revision applicabile, density o process assumptions, calcolo/generator evidence ed eccezioni. Questa pagina non prescrive dimensioni universali.
Chi dovrebbe approvare un nuovo componente?
Dipende dal rischio: almeno una review indipendente di pin/geometry, con component/procurement e mechanical/process review quando necessarie. Creator e approver separati sono utili per parti complesse.
Come si gestisce una parte urgente per un prototipo?
Con uno stato temporaneo project-specific, owner, evidence minima, expiry e divieto di riuso produttivo finché non passa il workflow completo o viene bloccata.
Un alert EOL deve rimuovere subito la parte?
No. Deve avviare affected-design search, demand/stock review, last-time-buy o alternate/redesign decision. Lo stato per nuovi design può cambiare, ma i prodotti esistenti richiedono disposition.
Quando due MPN possono essere alternative?
Dopo verifica di form, fit, function, process, firmware, quality/compliance e supply risk per lo scope definito. Stesso valore e stesso package name non dimostrano equivalenza.
Una modifica della libreria aggiorna automaticamente i PCB rilasciati?
Non dovrebbe. Il design deve conservare la revision usata; una modifica funzionale o geometrica passa ECO/change control e validation prima di entrare in una nuova release.
Come distinguere un difetto di footprint da un difetto di processo?
Confrontando package/pad/paste, stencil, placement, reflow, material, lot e first-fail evidence. La posizione del difetto non identifica da sola la root cause.
Quali parti auditare per prime?
Quelle più usate, complesse, modificate, collegate a difetti, con lifecycle risk o presenti in prodotti critici. Il risk-based sampling è più utile di una verifica superficiale di tutto.
Quali dati devono arrivare al fornitore PCBA?
Baseline PCB, BOM con exact MPN/alternates, centroid/orientation, assembly notes, variants, sourcing restrictions, DFM/deviation route, inspection/test e change terms. Una vista live non versionata non basta.