En algún piso de fábrica hay un motor girando a 1.400 RPM, con los rodamientos dentro de tolerancia y la temperatura del bobinado subiendo como cualquier día normal. Nada de eso es lo interesante.
Lo interesante es la pantalla atornillada al lado, la que le dice al operador que todo está bien. Porque esa pantalla también es un microcontrolador: tiene RAM donde se puede dar vuelta un bit y tiene un núcleo que puede ejecutar la instrucción equivocada sin avisarle a nadie. Si eso ocurre en silencio, el display sigue diciendo "OK" mucho después de que "OK" dejó de ser cierto.
Esa distancia entre un sistema que funciona y un sistema que puede demostrar que funciona es lo que la norma IEC 60730 intenta cerrar, y es lo que ESP-BIST aporta sobre silicio de Espressif.
¿Qué revisa exactamente un autotest incorporado?
BIST significa Built-In Self Test, y es literalmente eso: rutinas que le preguntan al hardware si sigue siendo el hardware que uno cree, y obtienen una respuesta verificable. ESP-BIST es la implementación de Espressif de esa idea, una biblioteca bajo licencia LGPL-3.0 pensada para aplicaciones que no pueden darse el lujo de enterarse por las malas de que un registro del núcleo quedó pegado.
La biblioteca organiza el trabajo en dos fases. Las pruebas posteriores al arranque corren una sola vez, apenas parte el sistema, y son exhaustivas: barrido completo de RAM, CRC de la memoria flash y verificación de registros, porque en el arranque hay tiempo de sobra para ser paranoico. Las pruebas de tiempo de ejecución corren de forma continua en segundo plano, necesariamente más livianas, con período configurable para no perturbar el lazo de control principal. Si cualquiera de las dos fases detecta algo malo, la biblioteca no se encoge de hombros y sigue: fuerza un estado seguro.
| Fase | Cuándo corre | Alcance |
|---|---|---|
| Post-arranque | Una vez, al encender | Barrido completo de RAM, CRC de flash, registros de CPU y CSR |
| Tiempo de ejecución | Continua, período configurable | Versión liviana, diseñada para no interrumpir el lazo de control |
En los SoC que tienen un núcleo RISC-V de bajo consumo (el ESP32-C5, el ESP32-C6 y el ESP32-P4 de esta demostración) ESP-BIST va un paso más allá con una función llamada Host Diagnostics. El núcleo de bajo consumo corre sus propios autotests como núcleo acompañante de seguridad y después supervisa al núcleo de aplicación. No es un observador pasivo: emite desafíos criptográficos con plazo que la aplicación debe responder de forma correcta y a tiempo, corre su propio perro guardián de manera independiente y, sobre todo, es dueño de la decisión de forzar un estado seguro. La aplicación puede registrar una falla. No puede negociarla.
¿Qué pide realmente la IEC 60730?
La IEC 60730-1, en su edición 2022, se titula "Controles eléctricos automáticos, Parte 1: Requisitos generales". El alcance importa, porque las Clases A, B y C clasifican funciones de control, no categorías de electrodomésticos. Las funciones Clase A no están destinadas a sostener la seguridad de la aplicación (temporizadores, control de iluminación). Las Clase B buscan impedir la operación insegura del equipo controlado, como los cortes térmicos y los bloqueos de puerta en lavadoras. Las Clase C apuntan a prevenir peligros especiales, como los controles automáticos de quemadores. El Anexo H fija los requisitos para controles electrónicos y software que implementan funciones Clase B y C, incluidas las medidas para detectar, controlar o mitigar fallas específicas en vez de asumir sin más que la electrónica va a comportarse.
ESP-BIST está construido contra ese objetivo y es específico sobre qué nivel alcanza cada prueba. Los algoritmos March, por ejemplo, cubren la línea base Clase B para RAM. Donde la biblioteca quiere más, agrega encima el algoritmo Abraham, que llega a cobertura de nivel Clase C para las fallas de acoplamiento entre celdas de memoria, ese caso en que dos bits supuestamente independientes fallan juntos y que las pruebas tipo March no siempre atrapan.
El proyecto respalda esto con un mapa documentado de los requisitos de la Tabla H.1, y las cifras conviene citarlas exactas antes que redondearlas:
"Cobertura de requisitos: el 100% de los componentes de la Tabla H.1 de IEC 60730 están implementados y probados", según la documentación de cobertura de ESP-BIST.
Es una afirmación genuinamente útil y también es incompleta, así que vale ser preciso. Significa que cada componente de autotest que la Tabla H.1 exige tiene una implementación y un caso de prueba con resultados registrados. No significa que ESP-BIST entregue un producto certificado. La propia documentación de Host Diagnostics lo dice sin rodeos: "Estado: descripción de arquitectura e implementación (no es una declaración de seguridad certificada)".
El mismo documento es igual de directo sobre los límites del núcleo de bajo consumo como supervisor: es un perro guardián por software válido, pero comparte pastilla de silicio, dominios de alimentación y de reloj con el núcleo que vigila. Es una línea de defensa real y útil. No es, por sí sola, el canal de seguridad físicamente independiente que daría un circuito integrado externo o un segundo microcontrolador. Si un producto necesita esa garantía más fuerte, la documentación de ESP-BIST recomienda agregarla y no pretende que el núcleo de bajo consumo sea algo que no es.
La certificación es un proceso que se corre sobre un producto terminado, con un laboratorio de ensayos, un expediente de seguridad y el nombre del fabricante encima. Lo que ESP-BIST entrega es la cobertura de autotest trazable y documentada sobre la que ese proceso se apoya.
¿Por qué le importa esto a un control de motor?
Un variador industrial completo no cae, estrictamente, bajo el alcance de la IEC 60730-1: ese documento trata sobre controles domésticos y similares, y un accionamiento industrial pesado suele vivir bajo una norma vecina como la IEC 61800-5-1. Pero la disciplina de fondo es idéntica, y por eso el control de motores aparece siempre como ejemplo cuando alguien explica el Anexo H. Un variador que lee mal su propia realimentación de velocidad, o que no detecta una sobrecorriente, no falla en silencio. Detectar una falla en la electrónica de control antes de que se convierta en falla del equipo controlado es el mismo trabajo diga la placa "lavadora" o "accionamiento de cinta transportadora". Solo cambia el papeleo que lo gobierna.
Pero hay una segunda máquina en esta historia que recibe menos atención: la pantalla. Cerca de ese motor hay una interfaz hombre-máquina cuyo trabajo completo consiste en decirle la verdad a una persona. "Motor operando en consigna". "Alarma de sobrevelocidad". "Falla de sistema: no acercarse". Cada una de esas frases es una afirmación relevante para la seguridad, y cada una vale exactamente lo que valga el silicio que la dibuja.
De ahí la pregunta incómoda: si la interfaz nunca revisa su propia salud, ¿qué respalda lo que afirma? Una pantalla táctil necesita un procesador de aplicaciones de verdad, con RAM suficiente para una biblioteca gráfica, cómputo para una interfaz que responda y periféricos para el enlace serial con el equipo que monitorea. Históricamente eso significó echar mano de un chip bueno en gráficos y malo en autocertificarse, y atornillarle al lado un controlador de seguridad mínimo que hiciera la parte que importa. Dos chips, dos imágenes de firmware, dos cosas que mantener sincronizadas.
El ESP32-P4 resulta interesante justamente porque no obliga a ese canje. Es un procesador de aplicaciones RISC-V de doble núcleo y alto rendimiento, capaz de correr LVGL, decodificar un panel táctil y manejar un display por MIPI DSI, con un núcleo RISC-V de bajo consumo al costado. Host Diagnostics usa ese núcleo tal como se describió arriba: se autoevalúa y después supervisa al núcleo que corre la interfaz. Un chip. Una placa.
¿Cómo funciona la demostración BIST HMI?
La aplicación de ejemplo arma un lazo físico concreto con dos placas que juegan papeles muy distintos:
- El M5Stack Tab5, un kit de desarrollo con ESP32-P4 y pantalla táctil integrada, corre el firmware de la interfaz: LVGL, el agente de Host Diagnostics en el núcleo de alto rendimiento, el acompañante en el núcleo de bajo consumo y un maestro Modbus RTU.
- Una segunda placa ESP, independiente, corre un firmware pequeño que simula un variador y responde como esclavo Modbus RTU en la dirección 1, exponiendo el tipo de registros que expondría un accionamiento real.
Las dos hablan por RS-485, la capa física de siempre en control industrial, porque si uno va a demostrar un patrón industrial conviene demostrarlo sobre el cableado que los ingenieros industriales usan de verdad.
La aplicación consulta ese conjunto de registros de forma continua, acciona la bobina de encendido y apagado, y refleja en la pantalla táctil todo lo que lee. Nada de esa parte es novedoso: un maestro Modbus interrogando a un esclavo es uno de los patrones más antiguos de la automatización industrial. Lo distinto es lo que ocurre antes de que ese sondeo tenga permiso de empezar.
La compuerta de arranque: sin autotest, no hay control
Esta es la parte de la demostración que efectivamente se gana la palabra "seguridad" en lugar de usarla como adorno.
Cuando el ESP32-P4 arranca la aplicación, el núcleo de alto rendimiento le ordena al de bajo consumo despertar y correr su batería de autotest posterior al arranque: registros de CPU, registros de control y estado, barrido completo de RAM y CRC de flash. Recién cuando esa batería pasa, el núcleo de bajo consumo reporta un estado aprobado al núcleo de aplicación por el protocolo de Host Diagnostics. Y recién cuando el núcleo de aplicación recibe ese estado, el firmware hace cualquier otra cosa. La pantalla no se enciende. El maestro Modbus no se inicializa. No hay interfaz y no hay control de motor hasta que el chip se demostró a sí mismo que está en condiciones de manejar cualquiera de las dos.
Ese orden no es un detalle de implementación, es el argumento completo. Una interfaz que empieza a interrogar a un control de motor sin importar su propia salud es un pasivo con una linda pantalla. Una interfaz que se niega a mostrar siquiera un cuadro hasta haberse revisado es un sistema que hace una afirmación que puede respaldar.
Qué se necesita para replicarlo
El montaje no exige instrumental de laboratorio. Basta una placa con ESP32-P4 y pantalla, una segunda placa ESP cualquiera para simular el variador, y un par de transceptores RS-485 con su par trenzado y tierra común. La biblioteca es abierta bajo LGPL-3.0, de modo que el costo de entrada para evaluar la disciplina de autotest en un producto propio es el de dos kits de desarrollo, no el de una licencia de seguridad funcional.
