De un vistazo
Qué abarca esta página
- Para
- Ingenieros de electrónica de potencia que definen etiquetas, registros o conjuntos de datos antes de entrenar un modelo.
- Qué te llevarás
- Un contrato de etiquetas de cuatro partes que separa el resultado de la regla, el estado de ejecución, el requisito de revisión y la resolución final.
- Estado de las pruebas
- Nota de campo publicada respaldada por una campaña reproducible, limitada a simulación, en un único punto de funcionamiento fijado.
- Límite de uso
- La campaña utiliza un modelo equivalente simplificado en un único punto; no es una aprobación de hardware, una validación en múltiples puntos ni una prueba de equivalencia entre solucionadores.
Punto de partida, decisión y resultado reutilizable
- Decisión
- Decidir si el registro de un candidato respalda continuar, corregir, revisar o abstenerse sin confundir la ejecución del software con la evidencia eléctrica.
- Punto de partida
- No hace falta código de aprendizaje automático; resulta útil estar familiarizado con la evaluación preliminar de LLC y la revisión de ingeniería.
- Resultado reutilizable
- Una guía de inicio rápido de 20 candidatos, un archivo de evidencia versionado de 200 candidatos y un registro de candidato que se puede volver a ejecutar.
Ejecuta el laboratorio para principiantes de referencia con grupos y compara después su separación y su contrato de etiquetas con este ciclo de evidencia LLC.
Un modelo sustituto no aprende la intención de ingeniería. Aprende las relaciones codificadas en los registros que recibe. Si pass significa unas veces «se ejecutó el cálculo», otras «se superó el punto de control analítico» y otras «el diseño es aceptable», añadir más diseños solo amplía la ambigüedad. Antes de preguntar cuántos datos necesita un modelo sustituto, el procedimiento debe definir exactamente qué significa cada etiqueta y conservar la evidencia que la respalda.
Esta Nota de campo abre una serie sobre la construcción de modelos sustitutos para el diseño de electrónica de potencia. La primera parte establece esa base separando el resultado de la regla, el estado de ejecución, el requisito de revisión y la resolución final dentro de un procedimiento LLC que se puede volver a ejecutar. Una regla puede dar pass o reject. Una ejecución puede completarse o fallar. Un caso puede requerir revisión. Una decisión final puede ser continuar, corregir, abstenerse o derivar.
Para ver por qué importan estas distinciones, imagina que revisas 200 candidatos LLC en una hoja de cálculo. Para cada uno compruebas la ganancia requerida, la fase de entrada, la finalización del solucionador, los límites eléctricos y el motivo por el que avanzó o no. Ahora pide a un asistente de programación que automatice ese trabajo. Los cálculos no son la parte más difícil. Lo difícil es evitar que el software llame mal convertidor a un tiempo de espera agotado o escriba PASS sin decir qué se ha superado. Este primer paso permite interpretar todas las decisiones posteriores sobre el conjunto de datos: definir el contrato de decisión, ejecutar una demostración pequeña reproducible, inspeccionar todas las salidas y mantener el significado de ingeniería asociado a cada registro.
Con esa base establecida, la siguiente Nota de campo examinará cuánto debe diversificarse la población de diseños antes de que los registros empiecen a respaldar un modelo sustituto útil, en lugar de limitarse a describir un generador, un modelo y un punto de funcionamiento.
Por qué «evalúa preliminarmente estos diseños» no es una especificación de ingeniería
Una solicitud de evaluación preliminar de LLC deja sin definir decisiones críticas:
- ¿Qué topología, ecuaciones y condición de funcionamiento quedan dentro del alcance?
- ¿Qué necesita demostrar la aproximación del primer armónico, o FHA?
- ¿Qué magnitudes son medidas, valores calculados o indicadores indirectos del modelo?
- ¿Qué ocurre cuando un método numérico no termina?
- ¿Un resultado automático favorable significa «avanzar a la siguiente comprobación» o «aprobar hardware»?
Un asistente de programación puede rellenar esos huecos con supuestos de aspecto razonable. Ese es precisamente el riesgo. Los supuestos ocultos se convierten en decisiones repetidas en cuanto el procedimiento crece.
Para un futuro modelo sustituto, esas decisiones repetidas se convierten en la variable objetivo que intenta aprender. Un modelo puede puntuar bien frente a una tabla internamente coherente y aprender la distinción de ingeniería equivocada. Por tanto, la finalidad de esta primera Nota de campo no es entrenar el modelo sustituto. Es hacer que los futuros registros de entrenamiento tengan un significado coherente.
Referencia actual: revisión de ingeniería por etapas antes de automatizar
El método manual de referencia es una revisión por etapas. Fija la especificación y los límites de los candidatos, inspecciona la ganancia FHA y la fase de entrada, envía solo los candidatos elegibles al siguiente método y registra los rechazos eléctricos por separado de los métodos que no llegaron a completarse.
La decisión acotada es si un candidato generado:
- se rechaza en el punto de control FHA;
- avanza a una evaluación de equivalente lineal por pasos temporales;
- supera o incumple las comprobaciones eléctricas automáticas identificadas;
- queda retenido porque falló la ejecución.
La aprobación de hardware queda fuera de esa decisión.
Cómo una etiqueta ambigua puede corromper el conjunto de evidencia
Supón que el software de simulación agota el tiempo de espera. El convertidor puede ser inadecuado, la configuración numérica puede ser difícil, el modelo puede estar incompleto o el tiempo de ejecución permitido puede ser simplemente demasiado corto. Ninguna de esas posibilidades constituye un rechazo eléctrico.
Si el procedimiento guarda ese caso como reject, el análisis posterior ve una etiqueta física falsa. Si esos mismos registros se utilizan para aprendizaje automático, el modelo aprende el comportamiento de la simulación como si fuera el comportamiento del convertidor. Un conjunto de datos más grande refuerza entonces el error: el modelo sustituto mejora reproduciendo el error de etiquetado del procedimiento, no reconociendo un diseño LLC eléctricamente inaceptable.
El error opuesto es igual de serio. Si un candidato supera un modelo simplificado en un único punto y el informe solo muestra PASS, el lector puede interpretar un resultado de evaluación preliminar como un diseño validado.
Separa el resultado de la regla, el estado de ejecución, la revisión y la resolución final
El procedimiento utiliza cuatro preguntas distintas:
- ¿Se completó el método y convergió donde se exigía?
- ¿La regla identificada aceptó o rechazó el resultado disponible?
- ¿Necesita el caso una revisión de ingeniería?
- ¿Qué resolución final está autorizada: continuar, corregir, abstenerse o derivar?
Esas respuestas se guardan por separado. Una ejecución fallida no tiene resultado de regla eléctrica. Una regla puede dar pass mientras el caso sigue necesitando revisión. La revisión no sobrescribe la evidencia ya registrada y la resolución final indica únicamente la siguiente acción autorizada a partir de esa evidencia.
Esta separación es la decisión central de diseño. Mantiene la utilidad del software sin darle una autoridad que la evidencia no ha justificado.
Construye el ciclo de evidencia antes de añadir complejidad al modelo
1. Fija el alcance eléctrico
La campaña archivada utilizó una condición de funcionamiento de un LLC de medio puente con secundario de toma central:
| Magnitud | Valor fijado |
|---|---|
| Tensión de entrada | 400 V |
| Tensión de salida | 36 V |
| Potencia de salida | 230 W |
| Condición de funcionamiento | Entrada fija, plena carga |
| Búsqueda de frecuencia FHA | 50 a 180 kHz |
| Error máximo de ganancia FHA | 1% |
| Fase inductiva mínima de entrada | 2° |
La etiqueta de alcance Phase A significa evaluación eléctrica preliminar en este único punto de funcionamiento. Es una etiqueta interna, no una fase de diseño normalizada del sector.
Quedan excluidos el diseño magnético, las pérdidas en semiconductores, el comportamiento térmico, la EMI, la robustez del control, las tolerancias, los barridos de red y carga y la validación de hardware. Nombrar esas exclusiones evita que una ejecución satisfactoria implique que se han comprobado.
2. Genera candidatos de forma determinista
La campaña fijada generó 200 candidatos mediante un proceso determinista de hipercubo latino con semilla 20260820. Varió la frecuencia de resonancia, la relación de inductancias, el factor de calidad y la relación de espiras del transformador.
El determinismo importa porque un revisor puede regenerar la misma población y comparar su hash de contenido. Sin una semilla, límites, definiciones y configuración fijados, una ejecución repetida puede probar un problema distinto.
3. Usa FHA como punto de control analítico rápido
Para cada candidato, la etapa FHA buscó dentro del rango de frecuencia permitido. Un candidato avanzaba únicamente si podía alcanzar la ganancia requerida con un error dentro del 1% y mantener al menos 2° de fase inductiva de entrada.
FHA responde a una pregunta acotada de evaluación preliminar. No reproduce todos los efectos de conmutación, no lineales, magnéticos, parásitos o de control.
Los gráficos permiten inspeccionar la decisión. Un resultado favorable muestra el punto seleccionado, la ganancia requerida, la respuesta de ganancia y la fase de entrada. Un rechazo muestra por qué la región permitida no contenía un punto aceptable.
4. Evalúa los candidatos que avanzan con el método principal por pasos temporales
Los candidatos que superaron FHA entraron en switched-linear-equivalent-v1, un modelo de equivalente lineal por pasos temporales con ventanas explícitas de convergencia y medida. La campaña archivada realizó 168 de estas evaluaciones.
El modelo añade evidencia en el dominio temporal y sigue siendo una representación eléctrica simplificada. Sus signos de corriente de conmutación son indicadores indirectos dentro de ese modelo, no una prueba de conmutación a tensión cero en un convertidor físico.
5. Escribe un registro por candidato
Cada registro conserva la especificación de entrada y su hash, las variables y unidades del candidato, los métodos, los umbrales, la evidencia de convergencia, la telemetría, el motivo de la decisión y la procedencia. Los valores objetivo ausentes permanecen ausentes en lugar de recibir valores inventados.
El registro también conserva un límite humano: requires engineer review sigue siendo verdadero y reviewed by permanece vacío hasta que se produzca una revisión autorizada.
Qué puede demostrar realmente la campaña
El resultado de 200 candidatos
El verificador recuperó los 200 registros, comprobó el vocabulario controlado de estados, validó los hashes guardados y reprodujo el hash del conjunto fijado de candidatos.
| Resultado del punto de control | Recuento |
|---|---|
| Generados | 200 |
| FHA reject | 32 |
| FHA pass | 168 |
| Evaluaciones de equivalente lineal por pasos temporales | 168 |
| Ejecuciones de evaluación completadas | 168 |
| Ejecuciones de evaluación fallidas | 0 |
| Regla automática pass | 168 |
| Regla automática reject | 32 |
| Casos que requieren revisión de ingeniería | 200 |
| Resoluciones finales autorizadas por un ingeniero | 0 |
Los 32 rechazos analíticos utilizaron el motivo archivado FHA_GAIN_TARGET_NOT_REACHED. Su resultado de regla FHA fue reject, por lo que no entraron en el método principal más costoso.
Los 168 candidatos que superaron FHA completaron y alcanzaron la convergencia en el método de equivalente lineal por pasos temporales. El resultado de su regla eléctrica identificada fue pass en el único punto fijado. No significa que se aprobaran 168 diseños de hardware.
Cinco de los candidatos que avanzaron seleccionaron el límite superior de 180 kHz de la búsqueda FHA. El esquema reproducible marca esa condición de frontera para que un óptimo en el borde no se confunda con una solución situada holgadamente dentro de los límites.
La población actual tampoco contiene ninguna discrepancia entre FHA y el método principal. Esa ausencia no demuestra que ambos métodos sean equivalentes.
El cuaderno hace visible la ejecución pequeña
El cuaderno descargable ejecuta una demostración nueva de 20 candidatos. No lee los registros archivados de 200 candidatos.
Esta ejecución pequeña resulta útil porque el ingeniero puede cambiar los valores de entrada visibles, ejecutar el procedimiento e inspeccionar los registros y gráficos en una sola sesión. Demuestra el registro de información y la semántica de las decisiones sin pedir al lector que audite primero 200 casos.
Un candidato recuperable
El candidato llc-0186 fue seleccionado por la regla de clasificación fijada como registro reutilizable de la campaña archivada.
| Variable de diseño | Valor |
|---|---|
| Frecuencia de resonancia | 72.999 kHz |
| Relación de inductancias | 3.6118 |
| Factor de calidad | 0.6576 |
| Relación de espiras, de primario a secundario | 4.2289 |
| Inductancia resonante | 117.103 µH |
| Inductancia magnetizante | 422.951 µH |
| Capacidad resonante | 40.592 nF |
El punto de control FHA seleccionó 114.25 kHz. En ese punto, el error de ganancia era 0.0127% y la fase de entrada calculada era 42.68°, por lo que el candidato avanzó.
El método por pasos temporales convergió tras 90 ciclos. Su ventana de medida de ocho ciclos y 1,280 muestras produjo:
| Telemetría | Valor |
|---|---|
| Tensión de salida | 35.9767 V |
| Potencia de salida | 229.702 W |
| Relación de potencias del modelo equivalente | 95.3188% |
| Frecuencia de conmutación | 114.25 kHz |
| Pico de corriente resonante | 2.347 A |
| RMS de corriente resonante | 1.755 A |
| Pico de corriente magnetizante | 0.669 A |
| Tensión de pico del condensador resonante | 86.268 V |
El resultado de su regla automática es pass. El caso sigue necesitando revisión de ingeniería y no consta ninguna resolución final autorizada por un ingeniero. El resultado pertenece al modelo, la condición y los umbrales fijados.
Vuelve a ejecutar el registro de un candidato
La campaña volvió a ejecutar llc-0186 en una carpeta de evidencia separada con la misma configuración y el mismo método. La forma de onda conservada de 1,280 muestras y todos los valores de telemetría relevantes para la decisión coincidieron con el registro original en el entorno archivado. La diferencia numérica observada fue 0.0 para cada métrica comparada.
Los hashes exactos establecen la integridad de lo archivado. Las tolerancias numéricas identificadas permiten la reproducción entre entornos. Volver a ejecutar demuestra que el resultado puede reconstruirse, no que el modelo sea físicamente completo.
El tiempo de espera agotado del software de simulación que no debe convertirse en rechazo eléctrico
Una comprobación previa separada del software de simulación superó su tiempo de espera configurado de 180 segundos y no produjo las medidas exigidas.
Su estado de ejecución es failed, con el motivo SOLVER_TIMEOUT.
No es reject.
El método fallido no produjo ninguna conclusión eléctrica con respaldo suficiente para decidir. Se archivó fuera de la población completada de 200 candidatos del método principal y no contaminó esas etiquetas.
El archivo público conserva un registro del fallo sin información sensible y una nota.
Este fallo también impide una afirmación más fuerte: la campaña no ha establecido la equivalencia entre el método principal de equivalente lineal y una implementación en lazo cerrado de mayor fidelidad.
Por qué estos 200 registros aún no son un conjunto de entrenamiento fiable
Todas las decisiones finales proceden de una condición de entrada fija y plena carga. La evidencia no cubre red, carga, temperatura, tolerancias, elementos magnéticos, solicitaciones de semiconductores, validación entre solucionadores, correlación con hardware ni evaluación de modelos con diseños completos reservados.
Los 168 resultados favorables también tienen una sola clase después del punto de control FHA. Un modelo sustituto entrenado con estos registros podría aprender los límites de este generador y este modelo y aparentar una generalidad mayor de la que tiene.
El siguiente conjunto de datos debe añadir diversidad controlada y evidencia más sólida entre métodos, no simplemente más filas.
Aquí empieza la siguiente Nota de campo. Preguntará cuánto debe ampliarse esa diversidad antes de que tenga sentido evaluar diseños no vistos y cómo saber si los candidatos nuevos añaden cobertura o solo más densidad dentro de la misma región estrecha.
Ejecuta los archivos por la ruta que encaje contigo
Empieza con la guía de inicio rápido de 20 candidatos ↗. El archivo de evidencia de 200 candidatos ↗ sirve para una auditoría más profunda.
Ruta A: Windows, sin preparar un entorno de programación
- Descarga el ZIP de la guía de inicio rápido y extráelo.
- Abre la carpeta extraída.
- Haz doble clic en run_demo.bat.
- Espera a que termine la ejecución.
- Abre la nueva carpeta LLC_Demo_Runs situada junto al paquete extraído.
- Abre summary.html en tu navegador.
- Confirma que el informe diga OUTPUT INTEGRITY: PASS.
- Revisa por separado la ejecución FHA, el punto de control FHA, la ejecución en el dominio temporal, la resolución automática final, las advertencias y el estado de aprobación de ingeniería.
OUTPUT INTEGRITY: PASS significa que se han superado las comprobaciones de los archivos esperados y de coherencia. No aprueba ningún candidato para hardware.
Ruta B: PowerShell
Abre PowerShell en la carpeta extraída de la guía de inicio rápido y ejecuta:
py -B run_demo.pyPara cambiar la especificación eléctrica visible y el número de candidatos:
py -B run_demo.py --vin 400 --vout 36 --pout 230 --candidates 20La salida aparece en LLC_Demo_Runs junto al paquete. Cada ejecución recibe su propia carpeta para que la evidencia generada no sobrescriba el paquete de origen.
Ruta C: Jupyter o Colab
Para usar un cuaderno local, abre notebooks/llc_quick_demo.ipynb. Para una ruta íntegramente en el navegador, abre el cuaderno de Colab ↗.
- Busca la celda de parámetros señalada.
- Edita Vin, Vout, Pout o el número de candidatos.
- Elige Run all.
- Lee primero los gráficos de recuentos de los puntos de control y del espacio de diseño.
- Inspecciona los casos FHA aceptados y rechazados.
- Revisa las trazas temporales conservadas y las definiciones de los estados.
- Descarga los archivos generados si quieres comparar o auditar la ejecución más adelante.
Para qué sirve cada salida
| Salida | Qué inspeccionar |
|---|---|
| summary.html | Resultado legible para personas, advertencias, gráficos y campos de estado separados |
| candidate_records.csv | Una fila de tabla por candidato para filtrar rápidamente |
| candidate_records.jsonl | Registros completos legibles por máquinas, un objeto JSON por línea |
| manifest.json | Identidad de la ejecución, archivos y hashes de contenido |
| verification.json | Resultado y comprobaciones de integridad legibles por máquinas |
| pedagogical_cases.json | Ejemplos seleccionados de aceptación, rechazo y fallo para revisión |
| plots/ | Procedimiento, espacio de diseño, recuentos de los puntos de control, casos FHA y trazas conservadas |
| ml_dataset_v1.csv | Exportación acotada para trabajo posterior con datos, no un conjunto de entrenamiento cualificado |
| feature_dictionary.json | Nombres de características, unidades y significados |
| target_dictionary.json | Definiciones de variables objetivo y semántica de los valores ausentes |
| split_manifest.json | Contrato de agrupación por diseño para la evaluación futura del modelo |
| dataset_card.md | Alcance, procedencia, exclusiones y notas de uso seguro |
Vuelve a ejecutar y verifica
Desde la raíz de la guía de inicio rápido o del archivo de evidencia:
py -B -m llc_tool replay
py -B -m unittest discover -s tests -p "test_*.py" -v
py -B VERIFY_RELEASE.pyLa repetición de la ejecución reconstruye el registro identificado bajo el contrato publicado. Las pruebas comprueban el comportamiento de la implementación. El verificador de la versión comprueba la integridad del paquete y las relaciones de evidencia. Ninguno de estos comandos sustituye la simulación de mayor fidelidad ni la revisión de hardware.
La conclusión defendible es deliberadamente acotada:
- Resultado: el ciclo fijado se completó con 32 rechazos FHA y 168 resultados favorables de equivalente lineal en un único punto.
- Artefacto: llc-0186 puede reconstruirse y volver a ejecutarse con evidencia trazable.
- Fallo: el tiempo de espera agotado del software de simulación siguió siendo un fallo del método y nunca se reetiquetó como rechazo eléctrico.
Usa la guía de inicio rápido para inspeccionar esa distinción por ti mismo. Después suscríbete a Notas de campo para el siguiente paso: medir cuánta diversidad de diseños hace falta antes de que tenga sentido una evaluación con diseños no vistos.