Verificaciones y validaciones personalizadas

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.

El marco de extensibilidad de comportamiento de Altium le permite escribir lógica de validación personalizada en Python y conectarla a puntos de control de la plataforma a lo largo del ciclo de vida del diseño: ERC y DRC en Altium Designer, validación de BOM y componentes, compuertas de liberación, etapas de revisión de diseño y pasos de flujo de trabajo en el servidor. Las comprobaciones personalizadas aparecen y se comportan de forma idéntica a las comprobaciones integradas de la plataforma: misma interfaz de usuario, mismo panel de errores, misma referencia cruzada al componente o red afectados.

Las comprobaciones no están limitadas a los datos de Altium. Una comprobación puede llamar a su base de datos interna de piezas, su lista de proveedores aprobados, su sistema ERP o cualquier fuente de datos externa de la que dependa su canal de validación. El resultado se devuelve y se muestra en Altium Designer exactamente igual que el resultado de una comprobación nativa.

Para Qué Sirven Realmente las Comprobaciones Personalizadas

La mayoría de las organizaciones descubren que necesitan comprobaciones personalizadas cuando se encuentran con una clase de problema que sigue repitiéndose a pesar de que el DRC existente se apruebe. Ejemplos comunes:

• Voltage derating rules – específicos de su familia de productos o segmento de la industria. Condensadores en líneas de baja tensión, condensadores electrolíticos cerca de fuentes de calor

• Component qualification gates – piezas de fabricantes no aprobados, componentes controlados por ITAR, piezas al final de su vida útil que compras ha marcado

• BOM completeness rules – parámetros obligatorios no completados, alternativas aprobadas faltantes, datos incompletos del fabricante

• Release documentation requirements – archivos de salida específicos que deben existir y estar actualizados para que una liberación sea válida

• Organizational standards – que existen solo en el conocimiento informal del equipo, aplicados de forma inconsistente por quien revise el diseño

Las comprobaciones personalizadas trasladan esto de una actividad de revisión —dependiente de que la persona adecuada esté disponible y recuerde revisarlo— a una compuerta automatizada que se ejecuta cada vez.

El Valor de Codificar el Conocimiento en Comprobaciones

Cuando un ingeniero sénior escribe una comprobación personalizada, ocurren dos cosas. La comprobación se ejecuta automáticamente en cada diseño a partir de ese momento, sin importar quién lo haya creado. Y cuando ese ingeniero se va, el conocimiento permanece. Esta es la propiedad que más importa a escala: el conocimiento institucional deja de estar rehén del número de personas.

Los nuevos ingenieros de su equipo obtienen automáticamente el beneficio de las comprobaciones escritas por ingenieros con años de experiencia en el dominio. La regla no requiere explicación ni revisión: simplemente se ejecuta.

Qué Comprobar y Qué No Comprobar

Las comprobaciones personalizadas funcionan bien para una validación determinista y basada en reglas: condiciones que siempre son verdaderas o siempre son falsas dado un estado de diseño específico. No sustituyen la revisión experta del diseño, la simulación ni la evaluación basada en el juicio.

Un buen candidato para una comprobación personalizada es cualquier regla que pudiera expresarse como: "marque este componente / red / parámetro si la condición X es verdadera". Un mal candidato es cualquier cosa que requiera comprensión contextual, interpretación de la intención del diseño o evaluación de compromisos. Eso sigue requiriendo revisión humana. Las comprobaciones personalizadas son la base automatizada que detecta todo lo que una máquina puede detectar, para que el tiempo de revisión humana se dedique a las cosas que solo los humanos pueden detectar.

Enfoques que No Escalan

• Manual pre-release checklists – funcionan para equipos pequeños con liberaciones poco frecuentes. Fallan cuando el tamaño del equipo crece, la cadencia de liberación aumenta o la persona que mantiene la lista de comprobación no está disponible. Las listas de comprobación también son invisibles para el ingeniero durante el diseño: la retroalimentación llega demasiado tarde como para que corregirla resulte barato.

• Review-only enforcement – confiar en que los revisores de diseño detecten infracciones estándar significa que los mismos errores son detectados repetidamente por las mismas personas. Consume tiempo experto en problemas deterministas, deja desprotegidas las etapas tempranas del diseño y crea una aplicación inconsistente entre revisores.