Caso de estabilización del software de control MBE para equipos semiconductores y entrega Windows

Resumen del proyecto

El proyecto abordó una aplicación Windows de supervisión y control para equipos de proceso de semiconductores. El sistema Qt/C++ se comunica con controladores de temperatura, una válvula de aguja, medidores de vacío, controladores de obturadores y una cámara industrial. SQLite conserva muestras de dispositivos, eventos de comandos y metadatos de fotogramas. El trabajo se centró en diagnosticar datos de temperatura intermitentes, confirmación incompleta de comandos, una regresión de la velocidad de la cámara y paradas silenciosas de grabación sin interrumpir la aplicación que ya estaba operativa en el sitio.

La entrega se dividió en dos líneas aisladas. La línea de mantenimiento aplicó cambios limitados y reversibles a la aplicación existente y produjo un instalador Windows x64. Una línea v2 separada utilizó su propio directorio y AppId para comprobar la propiedad de los puertos serie, las conexiones de base de datos, los workers de cámara y la ejecución de scripts. Se conservaron la configuración y los datos históricos; el software capaz de conectarse al equipo no se inició sin una ventana de seguridad confirmada por el operador.

Alcance del sistema y tecnología

Diagnóstico basado en evidencias

Una revisión de solo lectura cubrió unas 8,89 horas de registros y bases históricas. COM5 registró 5.168 limpiezas del búfer después de superar 128 bytes, mientras que las actualizaciones efectivas de los diez controladores eran claramente más lentas que el periodo configurado de dos segundos. El código mostraba que cada consulta de alta frecuencia leía alrededor de 35 registros y recibía aproximadamente 75 bytes. La planificación de la GUI, los lotes lentos de la base y una espera de 150 ms aumentaban la posibilidad de que una respuesta tardía se mezclara con la solicitud siguiente.

Dos registros históricos de cámara del mismo ordenador permitieron otra comparación. La versión de referencia escribía JPEG a 8,006 FPS, mientras que una versión con regresión escribía 3,919 FPS. Ninguna muestra contenía JPEG adyacentes idénticos. El ACK del fotograma bruto volvía a la cola del worker de cámara; una adquisición bloqueante podía ejecutarse antes del ACK y el nuevo fotograma se omitía mientras el anterior seguía marcado como pendiente. Los números documentan la regresión y su diagnóstico, no un resultado de aceptación posterior a la corrección.

Mantenimiento limitado de la aplicación existente

La línea de mantenimiento conservó la interfaz, la configuración de dispositivos, las carpetas de datos y los puntos de entrada de scripts. Los archivos se copiaron antes de sustituirlos y el archivo de parches y el instalador recibieron registros SHA-256. El instalador mantiene MBE_Data, Scriptfile y la configuración existente, y no inicia automáticamente la aplicación de control después de instalarse.

• Las lecturas frecuentes de temperatura se limitaron a los registros de PV, SP y Working SP, reduciendo una respuesta típica de unos 75 a unos 15 bytes.
• Una escritura de temperatura Sub compara la respuesta Modbus 0x06 y luego vuelve a leer SP; una respuesta ausente o un valor distinto se notifican como fallo.
• La captura está dirigida por el worker; la vista previa y la grabación bruta admiten un solo fotograma en proceso y eligen el más reciente.
• Los valores de ingeniería en grados Celsius ya no se dividen otra vez por diez en el estado ni en la ruta de control antigua.

Lectura del Ramp Rate en el dispositivo

La celda Ramp Rate comienza con -- en lugar de un valor fijo generado por el software. Después, la aplicación lee el registro 0x0023. Durante el funcionamiento estable se consulta un controlador cada tres segundos y una ronda de diez tarda aproximadamente 30 segundos. Ramp Rate queda fuera de la solicitud frecuente de PV/SP, por lo que no alarga todas las respuestas del bus de 9600 baudios.

El cambio corrige el origen del dato mostrado: solo aparece un número cuando llegan datos del dispositivo. La sincronización después de modificar el valor en el panel todavía debe comprobarse con 1.0.3 y hardware real, y no se presenta como aceptación de hardware completada.

Ruta de captura y almacenamiento de cámara

La vista previa y la grabación utilizan el fotograma más reciente. Si la GUI o el codificador JPEG están temporalmente por detrás, los fotogramas intermedios pueden sustituirse en lugar de formar una cola creciente. El ACK del fotograma bruto libera directamente su indicador atómico y no espera detrás de otra llamada bloqueante. Los nombres y campos de la base usan el momento real de adquisición; el inicio y el final del guardado se registran por separado.

La versión 1.0.3 añade dos watchdogs. Si la cámara está abierta pero no llega un fotograma bruto durante tres segundos, la adquisición se cierra y se vuelve a abrir con un intervalo de diez segundos entre reinicios. Si una tarea de guardado o el tiempo desde la última persistencia supera tres segundos, se libera el estado bloqueado y se reintenta con el fotograma actual. El mecanismo trata paradas silenciosas, pero no sustituye el diagnóstico en campo del controlador, USB, rendimiento del disco o errores de la base.

Línea de prueba aislada de arquitectura v2

v2 utiliza su propio árbol de código, AppId y directorio de instalación y no reemplaza la aplicación antigua. De forma predeterminada no conecta puertos serie, no inicia monitorización, no abre la cámara y no envía comandos de obturador al arrancar. Un puerto físico pertenece a un solo PortWorker; consultas, comandos del operador y del script entran en una cola común de transacciones con prioridad.

SQLite mantiene una única conexión de escritura. Las muestras y los metadatos se confirman por tiempo o umbral de lote y las consultas históricas usan otra conexión de solo lectura. Captura, vista previa y grabación JPEG son responsabilidades separadas. El script avanza en pasos breves de máquina de estados y se detiene cuando falla una respuesta o la lectura del valor objetivo.

Compilación, empaquetado y conservación de datos

La versión de mantenimiento 1.0.3 se compiló con CMake y MSVC en Release x64 y se empaquetó con Inno Setup 6.7.3. El ejecutable Release mide 1.727.488 bytes. El área del instalador contiene 78 archivos con un total de 66.292.772 bytes. La comprobación encontró Galaxy SDK, bibliotecas Qt, controlador SQLite, VC Runtime y configuración del equipo, sin DLL de depuración de Qt.

La versión del instalador es 1.0.3.20260728 y su tamaño es 19.884.961 bytes. Los SHA-256 completos del programa, el archivo de parche y el instalador permanecen en el registro de entrega. El instalador no tiene firma Authenticode, por lo que Windows puede mostrar un aviso de editor desconocido.

Evidencias de verificación y límites

Seguridad del sitio y plan de aceptación

Al iniciar, la aplicación puede conectar dispositivos serie y la cámara y puede emitir comandos de control. Por eso la sesión remota no ejecutó el nuevo build en un escritorio sin supervisión ni detuvo el proceso existente. Después de que un operador confirme la condición segura, la aceptación debe avanzar desde monitorización a comandos aislados, cámara, válvula y obturadores, scripts y operación combinada.

• Monitorizar 30 minutos y calcular intervalo de muestra, tasa de timeout y mayor hueco de cada controlador.
• Escribir varios objetivos Sub seguros y comparar respuesta 0x06, lectura de SP, panel del equipo y PV.
• Fijar exposición, resolución y directorio para medir FPS de captura, FPS guardados, fotogramas omitidos y latencia extremo a extremo.
• Interrumpir y restablecer el enlace de cámara, verificando el registro del watchdog, la vista previa y la grabación.
• Registrar ocho horas de operación combinada antes de decidir la sustitución de la aplicación antigua.

Método de ingeniería reutilizable

El método es aplicable a aplicaciones industriales Windows que deben seguir disponibles y con una vía de retorno durante las mejoras: equipos semiconductores, sistemas de vacío, control térmico, cámaras industriales, adquisición multipuerto, equipos de laboratorio y scripts de proceso. Primero se crean evidencias reproducibles desde registros, bases y rutas de protocolo; después se seleccionan correcciones limitadas o una línea de arquitectura separada según el riesgo.

Entradas para un proyecto similar

Una revisión inicial suele requerir protocolos, topología serie, mapas de registros, SDK y muestras de cámara, código y entorno de compilación, logs y bases históricas, límites de seguridad, método de retorno y objetivos medibles para periodo de muestreo, éxito de comandos, velocidad de fotogramas, latencia y operación continua. El diagnóstico estático, las pruebas sin hardware, la comprobación del instalador y el plan de aceptación pueden realizarse antes de disponer de equipos, pero no sustituyen la aceptación en campo.

Preguntas frecuentes

¿Fue desarrollo nuevo o mantenimiento de un sistema existente?

Se utilizaron ambas líneas. Mantenimiento produjo cambios limitados y el instalador 1.0.3. v2 es una línea separada para responsabilidades más claras de hilos, transacciones y datos y no sustituye la aplicación antigua.

¿Por qué no se inició el nuevo build por SSH?

El arranque puede ocupar la cámara y los puertos serie y emitir comandos. Sin una condición segura confirmada, solo se realizaron código, compilación, empaquetado y verificaciones estáticas.

¿8,006 FPS es el resultado medido después de la corrección?

No. Es una referencia histórica en el mismo ordenador; 3,919 FPS pertenece a la versión con regresión. La comparación localizó el problema de ACK. La versión corregida aún requiere una medición controlada.

¿Las pruebas cubrieron todas las funciones del equipo?

No. El proyecto de mantenimiento no registró pruebas automáticas. Un programa v2 cubrió 11 grupos sin hardware de protocolo, estado, script y almacenamiento. Los equipos reales y la operación prolongada siguen pendientes.

¿Cómo se protegieron los datos y la configuración?

Los archivos se copiaron antes de los cambios, se registraron hashes, el instalador conserva datos, scripts y configuración, y v2 utiliza AppId y directorio separados. El cambio de versión depende de la aceptación en campo.