Vérifications et validations personnalisées

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.

Le framework Behavior Extensibility d’Altium vous permet d’écrire une logique de validation personnalisée en Python et de la connecter aux points de contrôle de la plateforme tout au long du cycle de vie de la conception : ERC et DRC dans Altium Designer, validation de la nomenclature (BOM) et des composants, portes de validation de mise en production, étapes de revue de conception et étapes de workflow sur le serveur. Les vérifications personnalisées apparaissent et se comportent exactement comme les vérifications intégrées à la plateforme : même interface utilisateur, même panneau d’erreurs, même cross-probe vers le composant ou le net concerné.

Les vérifications ne sont pas limitées aux données Altium. Une vérification peut interroger votre base de données interne de composants, votre liste de fournisseurs approuvés, votre système ERP ou toute autre source de données externe dont dépend votre pipeline de validation. Le résultat est renvoyé et affiché dans Altium Designer exactement comme le résultat d’une vérification native.

À quoi servent réellement les vérifications personnalisées

La plupart des organisations découvrent qu’elles ont besoin de vérifications personnalisées lorsqu’elles rencontrent une catégorie de problèmes qui revient sans cesse malgré la réussite des DRC existants. Exemples courants :

• Voltage derating rules – spécifiques à votre famille de produits ou à votre segment industriel. Condensateurs sur des rails basse tension, condensateurs électrolytiques à proximité de sources de chaleur

• Component qualification gates – composants provenant de fabricants non approuvés, composants soumis à l’ITAR, composants en fin de vie signalés par les achats

• BOM completeness rules – paramètres obligatoires non renseignés, alternatives approuvées manquantes, données fabricant incomplètes

• Release documentation requirements – fichiers de sortie spécifiques qui doivent exister et être à jour pour qu’une mise en production soit valide

• Organizational standards – des règles qui n’existent que dans la connaissance informelle de l’équipe, appliquées de façon incohérente selon la personne qui révise la conception

Les vérifications personnalisées permettent de transformer ces points, qui relevaient d’une activité de revue — dépendante de la disponibilité de la bonne personne et du fait qu’elle pense à vérifier — en une porte automatisée qui s’exécute à chaque fois.

La valeur de l’encodage des connaissances dans les vérifications

Lorsqu’un ingénieur senior écrit une vérification personnalisée, deux choses se produisent. La vérification s’exécute automatiquement sur toutes les conceptions à venir, quel que soit leur auteur. Et quand cet ingénieur quitte l’entreprise, la connaissance reste. C’est la propriété la plus importante à grande échelle : la connaissance institutionnelle cesse d’être otage des effectifs.

Les nouveaux ingénieurs de votre équipe bénéficient automatiquement des vérifications écrites par des ingénieurs ayant des années d’expérience métier. La règle n’a pas besoin d’être expliquée ni revue : elle s’exécute simplement.

Ce qu’il faut vérifier — et ce qu’il ne faut pas vérifier

Les vérifications personnalisées fonctionnent bien pour une validation déterministe, fondée sur des règles : des conditions qui sont toujours vraies ou toujours fausses pour un état de conception donné. Elles ne remplacent pas une revue de conception experte, une simulation ou une évaluation fondée sur le jugement.

Un bon candidat pour une vérification personnalisée est toute règle qui peut s’exprimer ainsi : « signaler ce composant / net / paramètre si la condition X est vraie ». Un mauvais candidat est tout ce qui exige une compréhension contextuelle, une interprétation de l’intention de conception ou une évaluation de compromis. Ces aspects nécessitent toujours une revue humaine. Les vérifications personnalisées constituent le socle automatisé qui détecte tout ce qu’une machine peut détecter, afin que le temps de revue humaine soit consacré à ce que seuls les humains peuvent détecter.

Les approches qui ne passent pas à l’échelle

• Manual pre-release checklists – fonctionnent pour de petites équipes avec des mises en production peu fréquentes. Elles échouent lorsque la taille de l’équipe augmente, que la cadence des mises en production s’accélère ou que la personne qui maintient la checklist n’est pas disponible. Les checklists sont également invisibles pour l’ingénieur pendant la conception — le retour arrive trop tard pour que la correction soit peu coûteuse.

• Review-only enforcement – compter sur les réviseurs de conception pour détecter les violations standard signifie que les mêmes erreurs sont détectées à répétition par les mêmes personnes. Cela consomme du temps d’experts sur des problèmes déterministes, laisse les premières étapes de conception sans protection et crée une application incohérente selon les réviseurs.