← Volver a casos Caso de software científico

Software de control y adquisición de datos para instrumentación de investigación de semiconductores: fiabilidad de un sistema Windows

Caso anonimizado de Sinovanta sobre una aplicación Qt/C++ para Windows, control térmico Modbus, cámara industrial, registros SQLite, escrituras verificadas e instalación reproducible.

Servicio
Auditoría del sistema existente y actualización de software dirigida
Alcance
Software Windows, comunicación con dispositivos, cámara industrial, datos y empaquetado
Plataforma
Windows 10/11 x64, Qt 5.12, C++/MSVC, Modbus RTU y SQLite
Versión con evidencia
Instalador de prueba de cliente 1.0.3.20260728
01

Contexto del proyecto

La aplicación existente coordinaba diez controladores de temperatura, obturadores, una cámara industrial, guiones de proceso y registros experimentales. El diagnóstico de campo detectó datos térmicos discontinuos, interrupciones silenciosas de almacenamiento y retraso de vista previa, escrituras aparentes sin cambio real, Ramp Rate mostrado antes de leer el equipo y escalas de temperatura inconsistentes.

02

Objetivo de ingeniería

Conservar las integraciones probadas y aislar los recorridos de mayor riesgo: hacer trazables las escrituras, sincronizar parámetros en ambos sentidos, recuperar adquisición y almacenamiento, unificar unidades, generar un instalador Release repetible y definir la aceptación pendiente en el hardware del cliente.

Fiabilidad en toda la ruta de control y datos

La comunicación serie, la captura de cámara, la persistencia, el estado de interfaz y el empaquetado se trataron como una única cadena observable. Cada cambio responde a un modo de fallo y a un resultado comprobable.

  1. 01

    Línea base y evidencia

    Fijar las versiones de código e instalador, revisar registros y SQLite, identificar límites de dispositivos y separar fallos observados de hipótesis.

  2. 02

    Adquisición serie y lectura

    Mantener estable el sondeo rápido PV/SP y leer Ramp Rate del registro 0x0023 a baja frecuencia, un controlador cada tres segundos.

  3. 03

    Control verificado

    Aceptar una escritura solo cuando la respuesta Modbus 0x06 coincide con esclavo, registro y valor y el SP se confirma por lectura; reintentar o informar el fallo.

  4. 04

    Recuperación de cámara

    Supervisar por separado la llegada de tramas y su guardado, reabrir la captura tras tres segundos sin tramas y reprogramar el guardado si llegan imágenes sin persistencia.

  5. 05

    Consistencia de datos y unidades

    Usar una sola ruta de unidades, eliminar el desfase heredado por factor diez, conservar marcas de tiempo reales y mantener diagnósticos revisables.

  6. 06

    Release y aceptación

    Construir el paquete x64, auditar dependencias, registrar versiones y SHA-256, conservar material de reversión y emitir la lista de aceptación de hardware.

03

Entregables controlados

Parche de código dirigido
Parche de 12 archivos para lectura de Ramp Rate, escrituras verificadas, recuperación de cámara, almacenamiento y unidades.
Instalador de prueba
Versión 1.0.3.20260728 para Windows x64 con Qt, controlador SQLite, SDK de cámara, configuración de dispositivos y VC Runtime.
Revisión de arquitectura y código
Revisión de estructura, comunicaciones, tratamiento de datos y riesgos P0/P1 priorizados.
Registro de compilación
Salida Release, inventario de dependencias, metadatos, recuentos y sumas SHA-256.
Lista de aceptación de campo
Lectura del equipo, escrituras repetidas, prueba prolongada de cámara, reconexión, continuidad y unidades.
04

Evidencia de ingeniería

Cada elemento identifica artefacto, alcance y límite. No sustituye la aceptación en el instrumento del cliente.

Revisión de arquitectura

83 archivos fuente y cabeceras C++; unas 36.200 líneas físicas revisadas.

Se identificaron riesgos P0/P1 y límites de responsabilidad. No es una certificación del software.

Diagnóstico de la versión anterior

Intervalo mediano cercano a 125 ms; 99 % igual o inferior a 130 ms; huecos de 562,921 s y 17,306 s; 1.486 imágenes sin duplicados consecutivos.

Define la línea base del fallo anterior, no la resistencia de la versión 1.0.3.

Compilación Release

Compilación superada; EXE de 1.727.488 bytes; SHA-256 CB4A11624F97BABC892399DF0975059408AA62CA4502622BBEE84D058D2FD5FD.

Confirma el artefacto reproducible y las comprobaciones estáticas inspeccionadas.

Auditoría del instalador

78 archivos y 66.292.772 bytes; ninguna DLL Qt Debug; presentes Qt, SQLite, SDK de cámara, VC Runtime y archivos de dispositivo.

SHA-256 del instalador: 6908988BF48670AC25A9F004BC77070960AE55D19D35AB51212EBDD64B4321A9. El paquete no está firmado.

05

Estado de validación

  • Comprobaciones estáticas superadas para lectura de Ramp Rate, escritura y lectura verificadas, watchdogs de captura y almacenamiento y eliminación de la escala antigua.
  • CTest terminó correctamente, pero no encontró pruebas; no constituye evidencia funcional.
  • Se comprobaron ProductVersion, FileVersion, contenido del paquete, dependencias y valores SHA-256.
  • La versión 1.0.3 no se había instalado ni ejecutado en el instrumento del cliente en la fecha de evidencia; faltan las pruebas de dispositivo y duración.
06

Alcance y limitaciones

El resultado publicado es un instalador Windows de prueba de cliente acompañado de evidencia de código, compilación, paquete y revisión estática. No acredita aceptación final en sitio, firma de producción, precisión metrológica certificada, almacenamiento continuo prolongado ni funcionamiento con toda combinación de controladores y cámaras. La aceptación final exige leer Ramp Rate real, confirmar escrituras repetidas en el panel del dispositivo, ejecutar la cámara al menos dos horas sin huecos inexplicados, probar desconexión y recuperación y verificar unidades en el instrumento.

Consultar software para instrumentación científica

Indique topología, protocolos, modelo de cámara, conservación de datos, secuencia operativa, código o ejecutable existente, entorno y criterios de aceptación.

Enviar requisitos →