Caso de estabilização do software de controle MBE para equipamento semicondutor e entrega Windows

Visão geral do projeto

O projeto tratou de uma aplicação Windows de supervisão e controle para equipamento de processo semicondutor. O sistema Qt/C++ comunica-se com controladores de temperatura, válvula de agulha, medidores de vácuo, controladores de obturadores e uma câmera industrial. O SQLite registra amostras dos dispositivos, eventos de comando e metadados dos quadros da câmera. O trabalho buscou diagnosticar interrupções de temperatura, confirmação incompleta de comandos, regressão da taxa da câmera e paradas silenciosas de gravação sem interromper a aplicação que já operava no local.

A entrega foi separada em duas linhas isoladas. A linha de manutenção aplicou mudanças limitadas e reversíveis na aplicação existente e gerou um instalador Windows x64. A linha v2 usou diretório e AppId próprios para testar a responsabilidade por portas seriais, conexões do banco de dados, workers da câmera e execução de scripts. A configuração e os dados históricos foram preservados, e nenhum software capaz de se conectar ao equipamento foi iniciado sem uma janela de segurança confirmada pelo operador.

Escopo do sistema e tecnologia

Diagnóstico baseado em evidências

Uma análise somente leitura cobriu aproximadamente 8,89 horas de logs e bancos históricos. A COM5 registrou 5.168 limpezas de buffer após a recepção exceder 128 bytes, enquanto as atualizações efetivas dos dez controladores ficaram claramente acima do período configurado de dois segundos. O código mostrava que cada consulta de alta frequência lia cerca de 35 registradores e recebia uma resposta típica de aproximadamente 75 bytes. O agendamento da GUI, lotes lentos do banco e uma janela de espera de 150 ms aumentavam a possibilidade de uma resposta tardia se misturar à solicitação seguinte.

Dois registros históricos de câmera no mesmo computador deram outra comparação. A versão de referência gravava JPEG a 8,006 FPS, enquanto uma versão com regressão gravava 3,919 FPS. Nenhuma amostra tinha JPEGs adjacentes com conteúdo idêntico. O ACK do quadro bruto voltava para a fila do worker da câmera; uma aquisição bloqueante podia ocorrer antes do ACK, fazendo o novo quadro ser ignorado enquanto o anterior ainda aparecia como pendente. Esses números documentam a regressão e o diagnóstico, não um resultado de campo após a correção.

Manutenção limitada da aplicação existente

A linha de manutenção preservou interface, configuração dos dispositivos, pastas de dados e pontos de entrada dos scripts. Os arquivos foram copiados antes da substituição, e o arquivo de patch e o instalador receberam registros SHA-256. O instalador mantém MBE_Data, Scriptfile e a configuração já existente e não inicia automaticamente a aplicação de controle após a instalação.

• As leituras frequentes de temperatura foram limitadas aos registradores de PV, SP e Working SP, reduzindo uma resposta típica de cerca de 75 para cerca de 15 bytes.
• A escrita de temperatura Sub compara a resposta Modbus 0x06 e então relê SP; resposta ausente ou valor diferente é relatado como falha.
• A captura é dirigida pelo worker; pré-visualização e gravação bruta permitem somente um quadro em processamento e usam o quadro mais recente.
• Valores de engenharia em graus Celsius deixaram de ser divididos por dez novamente no status e no caminho de controle antigo.

Leitura do Ramp Rate no dispositivo

A célula Ramp Rate começa com -- em vez de um valor fixo criado pelo software. Em seguida, a aplicação lê o registrador 0x0023. Durante operação estável, um controlador é consultado a cada três segundos e os dez completam uma rodada em cerca de 30 segundos. O Ramp Rate fica fora da solicitação frequente de PV/SP, evitando ampliar todas as respostas no barramento de 9600 baud.

A mudança corrige a origem do valor exibido: um número aparece somente depois da chegada dos dados do dispositivo. A sincronização após uma alteração feita pelo operador no painel ainda precisa ser verificada com a versão 1.0.3 em hardware e não é apresentada como aceitação concluída.

Caminho de captura e armazenamento da câmera

A pré-visualização e a gravação usam o quadro mais recente. Se a GUI ou o codificador JPEG estiver temporariamente mais lento, quadros intermediários podem ser substituídos em vez de criar uma fila crescente. O ACK do quadro bruto libera diretamente o indicador atômico e não fica atrás de outra chamada bloqueante da câmera. O nome do arquivo e os campos do banco usam o momento real de aquisição, enquanto início e término da gravação são registrados separadamente.

A versão 1.0.3 adiciona dois watchdogs. Se a câmera estiver aberta, mas nenhum quadro bruto chegar durante três segundos, a aquisição é fechada e reaberta, com dez segundos de intervalo para novo reinício. Se uma tarefa de gravação ou o tempo desde a última persistência ultrapassar três segundos, o estado preso é liberado e o quadro atual é tentado novamente. O mecanismo trata paradas silenciosas, mas não substitui a análise em campo do driver, ligação USB, desempenho do disco ou erros do banco.

Linha isolada de teste da arquitetura v2

A v2 usa árvore de código, AppId e diretório de instalação próprios e não substitui a aplicação antiga em execução. Por padrão, não conecta portas seriais, não inicia monitoramento, não abre a câmera e não envia comandos de obturador ao iniciar. Uma porta física pertence a um único PortWorker; consultas, comandos do operador e comandos de script entram em uma fila única de transações com prioridade.

O SQLite mantém uma única conexão de escrita. Amostras e metadados são confirmados por tempo ou limite de lote, e consultas históricas usam conexão independente somente leitura. Captura, pré-visualização e gravação JPEG são responsabilidades separadas. O script de processo avança em passos curtos de máquina de estados e para quando uma resposta ou a releitura do valor-alvo falha.

Build, empacotamento e retenção de dados

A versão de manutenção 1.0.3 foi compilada com CMake e MSVC em Release x64 e empacotada com Inno Setup 6.7.3. O executável Release tem 1.727.488 bytes. A área de instalação contém 78 arquivos, totalizando 66.292.772 bytes. A checagem encontrou Galaxy SDK, bibliotecas Qt, driver SQLite, VC Runtime e configuração do equipamento, sem DLLs Qt de depuração.

A versão do instalador é 1.0.3.20260728 e seu tamanho é 19.884.961 bytes. Os SHA-256 completos do programa, arquivo de patch e instalador permanecem no registro de entrega. O instalador não possui assinatura Authenticode, portanto o Windows pode exibir um aviso de editor desconhecido.

Evidências de verificação e limites

Segurança no local e plano de aceitação

Após iniciar, a aplicação pode conectar dispositivos seriais e câmera e pode emitir comandos de controle. Por isso, a sessão remota não iniciou o novo build em uma área de trabalho sem supervisão nem encerrou o processo existente. Depois de um operador confirmar a condição segura, a aceitação deve avançar de monitoramento para comandos isolados, câmera, válvula e obturadores, scripts e operação combinada.

• Monitorar durante 30 minutos e calcular intervalo de amostra, taxa de timeout e maior lacuna de cada controlador.
• Escrever vários alvos Sub seguros e comparar resposta 0x06, releitura de SP, painel do equipamento e PV.
• Fixar exposição, resolução e diretório para medir FPS de captura, FPS gravado, quadros ignorados e latência ponta a ponta.
• Interromper e restaurar a ligação da câmera, verificando log do watchdog, pré-visualização e gravação.
• Registrar oito horas de operação combinada antes de decidir pela substituição da aplicação antiga.

Método de engenharia reutilizável

O método se aplica a aplicações Windows industriais existentes que precisam continuar disponíveis e com retorno possível durante a melhoria: equipamento semicondutor, sistemas de vácuo, controle térmico, câmeras industriais, aquisição multipporta, equipamentos de laboratório e controle por scripts. Primeiro são criadas evidências reproduzíveis a partir de logs, bancos e caminhos de protocolo; depois são escolhidas correções limitadas ou uma linha arquitetural isolada conforme o risco.

Entradas para um projeto semelhante

Uma avaliação inicial normalmente requer protocolos, topologia serial, mapas de registradores, SDK e amostras da câmera, código e ambiente de build, logs e bancos históricos, limites de segurança, método de retorno e metas mensuráveis para período de amostra, sucesso de comandos, taxa de quadros, latência e operação contínua. Diagnóstico estático, testes sem hardware, checagem do instalador e plano de aceitação podem ocorrer antes de uma janela com os dispositivos, mas não substituem a aceitação em campo.

Perguntas frequentes

Foi desenvolvimento novo ou manutenção do sistema existente?

Os dois caminhos foram usados. A manutenção produziu mudanças limitadas e o instalador 1.0.3. A v2 é uma linha de teste separada para responsabilidades mais claras de threads, transações e dados e não substitui a aplicação antiga.

Por que o novo build não foi iniciado pela sessão SSH?

A inicialização pode ocupar câmera e portas seriais e emitir comandos. Sem condição segura confirmada, foram realizados somente código, build, empacotamento e verificações estáticas.

8,006 FPS é o resultado medido após a correção?

Não. É um registro histórico de referência no mesmo computador; 3,919 FPS pertence à versão com regressão. A comparação localizou o problema de ACK. A versão corrigida ainda precisa de medição controlada.

Os testes cobriram todas as funções do equipamento?

Não. O projeto de manutenção não registrou testes automáticos. Um programa v2 cobriu 11 grupos sem hardware de protocolo, estado, script e armazenamento. Dispositivos reais e operação prolongada continuam na aceitação.

Como dados e configuração foram protegidos?

Arquivos foram copiados antes das mudanças, hashes foram registrados, o instalador preserva dados, scripts e configuração existente, e v2 usa AppId e diretório separados. A mudança de versão depende da aceitação em campo.