Controlli e validazioni personalizzati

Standard design rules cover geometry and electrical correctness. Custom checks cover everything else – your company's standards, your industry's requirements, and your organization's institutional knowledge.

Il framework Behavior Extensibility di Altium consente di scrivere logiche di validazione personalizzate in Python e collegarle ai checkpoint della piattaforma lungo tutto il ciclo di vita della progettazione: ERC e DRC in Altium Designer, validazione di BOM e componenti, gate di rilascio, fasi di design review e passaggi del workflow sul server. I controlli personalizzati compaiono e si comportano in modo identico ai controlli integrati della piattaforma: stessa interfaccia utente, stesso pannello degli errori, stesso cross-probe verso il componente o la net interessata.

I controlli non sono isolati ai soli dati di Altium. Un controllo può interrogare il database interno dei componenti, l'elenco dei fornitori approvati, il sistema ERP o qualsiasi altra sorgente dati esterna da cui dipende la pipeline di validazione. Il risultato viene restituito e visualizzato in Altium Designer esattamente come un risultato di controllo nativo.

A cosa servono realmente i controlli personalizzati

La maggior parte delle organizzazioni scopre di aver bisogno di controlli personalizzati quando si imbatte in una categoria di problemi che continua a ripresentarsi nonostante il superamento dei normali DRC. Esempi comuni:

• Voltage derating rules – specifici della tua famiglia di prodotti o del tuo segmento industriale. Condensatori su rail a bassa tensione, condensatori elettrolitici vicino a fonti di calore

• Component qualification gates – componenti di produttori non approvati, componenti soggetti a controllo ITAR, componenti end-of-life segnalati dall'ufficio acquisti

• BOM completeness rules – parametri obbligatori non compilati, alternative approvate mancanti, dati del produttore incompleti

• Release documentation requirements – file di output specifici che devono esistere ed essere aggiornati affinché un rilascio sia valido

• Organizational standards – che esistono solo come conoscenza informale interna e vengono applicati in modo incoerente da chiunque esamini il progetto

I controlli personalizzati spostano tutto questo da un'attività di revisione – che dipende dalla disponibilità della persona giusta e dal fatto che si ricordi di controllare – a un gate automatizzato che viene eseguito ogni volta.

Il valore di codificare la conoscenza nei controlli

Quando un ingegnere senior scrive un controllo personalizzato, accadono due cose. Il controllo viene eseguito automaticamente su ogni progetto futuro, indipendentemente da chi lo abbia creato. E quando quell'ingegnere lascia l'azienda, la conoscenza resta. Questa è la proprietà che conta di più su larga scala: la conoscenza istituzionale smette di essere ostaggio dell'organico.

I nuovi ingegneri del tuo team beneficiano automaticamente dei controlli scritti da ingegneri con anni di esperienza nel dominio. La regola non richiede spiegazioni né revisione: semplicemente viene eseguita.

Cosa controllare e cosa non controllare

I controlli personalizzati funzionano bene per una validazione deterministica e basata su regole: condizioni che sono sempre vere o sempre false dato uno specifico stato del progetto. Non sostituiscono la design review esperta, la simulazione o le valutazioni basate sul giudizio.

Un buon candidato per un controllo personalizzato è qualsiasi regola che possa essere espressa così: "segnala questo componente / net / parametro se la condizione X è vera". Un cattivo candidato è tutto ciò che richiede comprensione del contesto, interpretazione dell'intento progettuale o valutazione di compromessi. Questi aspetti richiedono ancora una revisione umana. I controlli personalizzati costituiscono la base automatizzata che intercetta tutto ciò che una macchina può intercettare, così il tempo di revisione umana viene dedicato agli aspetti che solo gli esseri umani possono cogliere.

Approcci che non scalano

• Manual pre-release checklists – funzionano per team piccoli con rilasci poco frequenti. Si interrompono quando aumenta la dimensione del team, cresce la frequenza dei rilasci o la persona che mantiene la checklist non è disponibile. Inoltre, le checklist sono invisibili all'ingegnere durante la progettazione: il feedback arriva troppo tardi perché la correzione sia economica.

• Review-only enforcement – affidarsi ai revisori del progetto per individuare violazioni standard significa che gli stessi errori vengono rilevati ripetutamente dalle stesse persone. Questo consuma tempo degli esperti su problemi deterministici, lascia scoperte le fasi iniziali della progettazione e crea un'applicazione incoerente delle regole tra revisori diversi.