Como detectar vazamentos de memória em scripts de automação de borda com o tracemalloc do Python

Para detectar vazamentos de memória em scripts de automação industrial de longa duração, os engenheiros devem usar o módulo `tracemalloc` do Python para comparar snapshots de alocação de memória ao longo do tempo. Executar esses testes contra simulações persistentes do OLLA Lab torna os vazamentos ocultos mais observáveis antes da implantação em dispositivos de borda físicos e ambientes de processo reais.

Vazamentos de memória em automação geralmente não são um problema do Python em abstrato. Eles são um problema de duração de tempo de execução em um sistema 24/7. Um script que se comporta perfeitamente por dez minutos ainda pode falhar na segunda semana, o que não é uma questão filosófica quando o dispositivo de borda está alimentando historiadores, APIs, alarmes ou supervisão de IA.

Um equívoco comum é que a coleta de lixo (garbage collection) torna os serviços Python de longa duração "autolimpantes". Isso não é verdade. O Python recupera objetos que não são mais referenciados; ele não resgata projetos que mantêm referências ativas, deixam sockets abertos ou acumulam threads e buffers indefinidamente.

Durante um teste de estresse recente de 48 horas de um registrador de dados OPC UA baseado em Python conectado ao preset de Tratamento de Água do OLLA Lab, a falha em fechar explicitamente o loop de conexão produziu um aumento de memória medido de 2,4 MB/hora; o mesmo script não mostrou falha visível em um teste de bancada de 10 minutos. [Metodologia: n=1 variante de script sob carga de polling simulada contínua, comparada com o mesmo script com encerramento explícito de conexão, janela de 48 horas.] Isso sustenta um ponto restrito: testes curtos podem perder a instabilidade de memória de longa duração. Isso não estabelece uma taxa de falha em toda a indústria.

Scripts de automação de longa duração vazam memória porque usam alocação dinâmica em ambientes que nunca param realmente. Os ciclos de varredura (scan cycles) de CLPs são determinísticos por design: a memória é alocada para tags, blocos de função e estruturas de execução de forma limitada. O Python não é construído sobre esse modelo. Ele aloca objetos conforme necessário, rastreia referências e depende da coleta de lixo para recuperar o que não é mais alcançável.

Essa distinção é importante porque a automação de borda é cada vez mais híbrida. O CLP ainda executa o controle determinístico, enquanto o Python em um IPC ou gateway lida com polling, tradução de protocolo, chamadas de API, análise local e, às vezes, lógica de IA supervisória. Arquitetura útil, sim. Arquitetura tolerante, não.

Na prática, os vazamentos aparecem quando o script mantém objetos vivos por mais tempo do que o pretendido. As três fontes de OT mais comuns são mundanas e caras:

As 3 fontes mais comuns de vazamentos de memória em OT

Uma quarta categoria vale a pena mencionar porque se esconde bem: buffer em nível de biblioteca. O vazamento nem sempre está no seu código; às vezes, seu código simplesmente o ativa repetidamente.

1. Sockets não fechados Sessões Ethernet/IP, Modbus TCP, OPC UA, MQTT ou HTTP que são abertas repetidamente, mas não fechadas corretamente, acumularão recursos ao longo do tempo.
2. Adições em listas globais Valores de tags históricos, eventos de alarme ou payloads de API armazenados em listas ou dicionários sem limites criam um crescimento constante de memória, a menos que um limite de FIFO ou retenção seja aplicado.
3. Acúmulo de threads ou tarefas Novas threads, tarefas assíncronas ou workers de nova tentativa lançados em falhas de comunicação podem persistir indefinidamente se travarem ou nunca forem encerrados e limpos.

O Python e os runtimes de CLP resolvem problemas diferentes e falham de maneiras diferentes. Um ciclo de varredura de CLP é construído para execução repetitiva e limitada contra estruturas de E/S e memória conhecidas. O Python é construído para computação de propósito geral, onde objetos podem ser criados, referenciados, passados, armazenados em cache e retidos de maneiras flexíveis.

O contraste claro é este: memória de varredura determinística versus tempo de vida de objeto dinâmico.

É por isso que "funcionou uma vez" é quase sem sentido para a confiabilidade de borda. Um engenheiro de comissionamento não validaria uma sequência de alternância de bombas com um comando de partida e consideraria o trabalho concluído. O software merece o mesmo ceticismo.

É também aqui que Simulation-Ready (Pronto para Simulação) precisa de uma definição precisa. No uso da Ampergon Vallis, Simulation-Ready não significa "familiarizado com a sintaxe" ou "confortável em um editor de código". Significa que um engenheiro pode provar, observar, diagnosticar e fortalecer a lógica relacionada ao controle contra o comportamento real do processo antes que ele chegue a um processo real. A sintaxe é necessária. A capacidade de implantação é o teste.

O `tracemalloc` identifica o crescimento de memória rastreando as alocações de memória do Python e comparando snapshots ao longo do tempo. Ele se conecta ao alocador do Python e registra onde os blocos foram alocados, o que permite aos engenheiros inspecionar o crescimento por arquivo, número da linha ou agrupamento de rastreamento (traceback).

Isso o torna útil para depuração de OT porque responde à única pergunta que importa quando a memória começa a subir: onde o crescimento está se originando?

Um padrão de linha de base simples parece com isto:

import tracemalloc import time

tracemalloc.start()

snapshot1 = tracemalloc.take_snapshot()

time.sleep(3600) # Executar por 1 hora

snapshot2 = tracemalloc.take_snapshot() top_stats = snapshot2.compare_to(snapshot1, 'lineno')

print("[Top 5 Locais de Crescimento de Memória]") for stat in top_stats[:5]: print(stat)

Isso não detecta todos os problemas de memória possíveis em todas as camadas de dependência. Ele rastreia alocações gerenciadas pelo Python, o que geralmente é o primeiro passo certo, mas não a palavra final. Se uma extensão C ou driver vazar fora do alocador do Python, você pode precisar de ferramentas em nível de SO também.

Um padrão industrial mais útil é o snapshot periódico com registro controlado:

import tracemalloc import time from datetime import datetime

tracemalloc.start(25) # armazena histórico de traceback mais profundo

baseline = tracemalloc.take_snapshot()

for cycle in range(1, 25): # exemplo: 24 verificações horárias time.sleep(3600)

current = tracemalloc.take_snapshot() stats = current.compare_to(baseline, 'lineno')

print(f"\n[Snapshot {cycle}] {datetime.now().isoformat()}") for stat in stats[:10]: print(stat)

O objetivo não é admirar a saída. O objetivo é estabelecer se o crescimento da memória é limitado, estável e atribuível.

O `tracemalloc` prova que as alocações gerenciadas pelo Python aumentaram entre os snapshots e mostra onde esse aumento está associado no código. Ele não prova, por si só, que o aumento é prejudicial, permanente ou operacionalmente inaceitável.

Essa distinção é importante porque nem todo crescimento é um vazamento. Algum crescimento de memória é esperado durante a inicialização, aquecimento de cache, carregamento de modelo ou inicialização de lote. Um vazamento é melhor definido operacionalmente como crescimento de memória que continua sem um teto de estado estacionário justificado durante o perfil de tempo de execução pretendido.

Para automação de borda, o perfil de tempo de execução pretendido geralmente é medido em dias ou semanas, não em minutos.

Uma regra de decisão prática é:

- Crescimento esperado: aumenta durante a inicialização e depois estabiliza. - Crescimento suspeito: aumenta com picos de carga de trabalho e depois se recupera parcialmente. - Comportamento de vazamento: aumenta monotonicamente ou em degraus sem um patamar significativo.

É por isso que um par de snapshots raramente é suficiente. A tendência importa. Falhas industriais são frequentemente lentas o suficiente para passar em uma demonstração e rápidas o suficiente para arruinar um fim de semana.

Você testa scripts de borda contra simulações de CLP de longa duração conectando o script a um processo virtual persistente, executando a carga de trabalho de polling ou orquestração pretendida por horas ou dias e comparando snapshots de memória enquanto o estado do processo continua a evoluir.

O hardware físico é o lugar errado para começar este teste. Prender um rack de CLP, E/S remota e dispositivos de campo para um teste de estabilidade de software de 48 ou 72 horas é caro, operacionalmente estranho e muitas vezes impossível em um ambiente adjacente à produção. A planta geralmente tem outras prioridades.

É aqui que o OLLA Lab se torna operacionalmente útil. O OLLA Lab é um simulador de lógica ladder e gêmeo digital baseado na web que permite aos engenheiros construir lógica, executar simulações persistentes, inspecionar E/S e variáveis e validar o comportamento contra cenários industriais realistas. Nesse contexto, seu valor é limitado e prático: ele fornece um ambiente persistente e contido em risco para validação de longa duração de software de borda interagindo com comportamento de controle simulado.

Operacionalmente, o fluxo de trabalho é direto:

• Inicie um cenário do OLLA Lab com comportamento de processo estável, como uma estação de bombeamento, unidade de tratamento de ar HVAC ou sequência de tratamento de água.
• Execute a lógica ladder no Modo de Simulação.
• Use o Painel de Variáveis para confirmar tags em mudança, valores analógicos, saídas e estados de sequência.
• Conecte o script Python externo ao ambiente de tags simulado ou fluxo de trabalho de E/S espelhado usado para teste.
• Inicie o `tracemalloc`.
• Deixe o script rodar sob condições realistas de polling, nova tentativa, registro e tratamento de falhas por um período sustentado.

O ponto importante é a persistência. Um vazamento que aparece após seis horas é invisível em um teste de cinco minutos, e um gêmeo digital não fica entediado.

O fluxo de trabalho para depurar um vazamento de memória no OLLA Lab é estabelecer uma linha de base, induzir carga realista, comparar snapshots de memória, isolar a causa, refatorar o script e repetir a simulação até que o comportamento da memória se estabilize.

Fluxo de trabalho de depuração passo a passo

1. Estabeleça a linha de base Abra um preset industrial do OLLA Lab, como uma Unidade de Tratamento de Ar HVAC, estação elevatória ou processo de tratamento de água. Inicie a simulação e tire um snapshot inicial do `tracemalloc` antes que o polling sustentado comece.
2. Induza a carga Execute o script Python contra o processo simulado na taxa operacional pretendida. Por exemplo, faça o polling das tags a cada 50 ms, grave os resultados em um buffer local e acione quaisquer chamadas normais de API ou historiador. Mantenha a execução por pelo menos quatro horas; mais tempo é melhor quando o ciclo de trabalho de produção é contínuo.
3. Compare os snapshots Use `snapshot2.compare_to(snapshot1, 'lineno')` ou comparações periódicas contra a linha de base para identificar quais linhas ou módulos acumulam memória.
4. Inspecione o modo de falha Determine se o crescimento vem do tratamento de conexão, estruturas de dados retidas, novas tentativas, tarefas assíncronas ou comportamento da biblioteca. É aqui que o julgamento de engenharia importa mais do que a familiaridade com a sintaxe.
5. Refatore e valide Feche os sockets explicitamente, implemente filas limitadas, junte ou cancele threads, reduza a retenção de objetos ou revise a lógica de nova tentativa. Em seguida, execute novamente a mesma simulação do OLLA Lab e confirme se o crescimento da memória atinge um teto estável ou permanece efetivamente plano.
6. Documente a evidência Mantenha os deltas dos snapshots antes e depois, duração do tempo de execução, cenário simulado, intervalo de polling e notas de revisão de código. Se a correção não puder ser explicada, ela não foi realmente validada.

Um padrão de vazamento real geralmente parece chato no início. Isso é parte do problema. O script continua coletando dados, o processo continua se movendo e a carga do sistema parece normal até que a pressão da memória cruze um limite e tudo se degrade de uma vez.

Considere um antipadrão simplificado:

import time data_log = []

while True: tag_values = read_plc_tags() # retorna dict dos valores atuais data_log.append(tag_values) # crescimento ilimitado send_to_api(tag_values) time.sleep(0.05)

Este código pode estar funcionalmente correto e operacionalmente imprudente. Se o processo rodar continuamente, `data_log` se torna um dreno de memória.

Uma versão limitada é mais segura:

import time from collections import deque

data_log = deque(maxlen=2000)

while True: tag_values = read_plc_tags() data_log.append(tag_values) send_to_api(tag_values) time.sleep(0.05)

O mesmo princípio se aplica às conexões:

client = open_connection() while True: if need_refresh(): client = open_connection() # conexão antiga pode persistir poll(client)

Um padrão mais seguro usa gerenciamento de ciclo de vida explícito:

while True: with open_connection() as client: poll(client) process_data(client) sleep_interval()

A implementação exata depende da biblioteca, mas a regra não muda: o tempo de vida do recurso deve ser explícito no código de OT de longa duração.

Um teste de vazamento de memória deve ser executado por tempo suficiente para cobrir o ciclo de trabalho pretendido, o ritmo de comunicação e o comportamento de tratamento de falhas do script implantado. Na prática, isso geralmente significa horas no mínimo e, frequentemente, 24 a 72 horas para cargas de trabalho de borda em execução contínua.

Não existe uma duração mágica universal. Um script fazendo polling a cada segundo com uploads de lote horários tem um perfil de risco diferente de um fazendo polling a cada 50 ms com tempestades de nova tentativa em comunicações intermitentes. A duração do teste deve estar vinculada ao comportamento relevante mais lento do sistema.

Uma abordagem de engenharia razoável é:

- 1–2 horas: detecta crescimento descontrolado óbvio - 4–8 horas: detecta muitos problemas de retenção e buffer - 24+ horas: começa a representar o comportamento de serviço contínuo - 48–72 horas: mais credível para serviços de borda que devem rodar sem supervisão

O teste também deve incluir estados anormais, não apenas operação nominal. Um script que sobrevive ao polling em estado estacionário, mas vaza durante tempestades de reconexão, ainda é um script com vazamento.

Os engenheiros devem construir um corpo compacto de evidências de validação, não uma galeria de capturas de tela. O artefato deve mostrar o que foi testado, o que significava "correto", como a falha foi induzida e o que mudou após a revisão.

Use esta estrutura:

Defina o sucesso em termos observáveis: memória estável durante uma execução de 24 horas, sem crescimento ilimitado de objetos, comportamento de reconexão bem-sucedido e sem perda das atualizações de tag necessárias.

Declare a falha introduzida ou observada: sessão OPC UA não fechada, lista de eventos ilimitada, thread de nova tentativa travada ou loop de reconexão malformado.

Documente a mudança de código ou arquitetura: encerramento explícito de socket, fila limitada, backoff de nova tentativa, limpeza de thread ou substituição de biblioteca.

1. Descrição do Sistema Descreva o processo simulado, a função da lógica ladder, a função do script de borda, o intervalo de polling, os protocolos e o alvo de tempo de execução.
2. Definição operacional de "correto"
3. Lógica ladder e estado do equipamento simulado Registre o cenário do OLLA Lab, estados de sequência relevantes, condições analógicas, condições de alarme e o contexto da lógica ladder com o qual o script interagiu.
4. O caso de falha injetada
5. A revisão feita
6. Lições aprendidas Resuma o que a falha revelou sobre suposições de tempo de execução, interação de processo e risco de implantação.

Esse é o tipo de evidência que suporta a revisão de engenharia. Também viaja bem entre as equipes porque explica o comportamento, não apenas a aparência.

O teste de vazamento de memória não é a mesma coisa que a validação de segurança funcional, mas ainda é uma questão de risco de comissionamento. A IEC 61508 e as práticas de segurança relacionadas concentram-se na integridade sistemática, disciplina do ciclo de vida e controle de falhas perigosas em sistemas elétricos, eletrônicos e programáveis. Um script de borda com vazamento pode ficar fora da função de segurança principal, mas ainda criar riscos operacionais através da perda de visibilidade, alarmes atrasados, decisões supervisórias obsoletas ou integrações falhas.

A distinção segura é simples: nem todo serviço de borda está relacionado à segurança, mas todo serviço de borda instável é um risco de confiabilidade.

A validação por gêmeo digital é útil aqui porque permite a exposição repetida ao comportamento realista do processo sem exigir equipamento real. A literatura em engenharia baseada em simulação e sistemas ciberfísicos industriais apoia o valor de ambientes virtuais de alta fidelidade para validação, treinamento de operadores e análise de falhas, desde que as alegações sejam mantidas limitadas à tarefa que está sendo simulada, em vez de tratadas como prova universal (Antonino et al., 2024; Tao et al., 2019; Villalonga et al., 2021).

Nesse quadro, o OLLA Lab deve ser entendido como um ambiente de validação e ensaio para tarefas de automação de alto risco. Não é um substituto para testes de aceitação no local, trabalho formal de ciclo de vida de segurança ou revisão de perigos específica da planta.

Você deve usar o OLLA Lab em vez de hardware físico quando a questão de engenharia for sobre comportamento de longa duração, repetibilidade, injeção de falhas e validação de baixo risco de software interagindo com a lógica de controle.

Isso inclui casos como:

• registradores de dados de borda fazendo polling de tags de CLP simuladas continuamente
• pontes de protocolo movendo dados entre sistemas de OT e TI
• scripts de orquestração conectados por API
• scripts supervisórios assistidos por IA que observam o estado do processo e emitem recomendações ou comandos limitados
• ensaios de comissionamento onde a lógica, o estado de E/S e cenários anormais precisam ser reproduzidos repetidamente

O hardware físico ainda é importante para a integração final, validação de tempo, comportamento específico do dispositivo e restrições ambientais. Mas o hardware é um lugar ruim para descobrir que uma lista Python tem crescido silenciosamente por 19 horas.

A resposta prática é direta: se espera-se que um script de automação Python rode continuamente, o `tracemalloc` deve fazer parte do fluxo de trabalho de validação. Testes de bancada curtos não estabelecem estabilidade de memória, e falhas de borda causadas por vazamentos lentos são exatamente o tipo de defeito que sobrevive a testes superficiais.

O padrão de engenharia mais forte é emparelhar o `tracemalloc` com um ambiente de simulação persistente. Essa combinação permite observar o comportamento da memória sob condições de processo realistas, isolar o crescimento para caminhos de código específicos, revisar o projeto e executar novamente a mesma carga de trabalho sem prender ativos físicos.

É assim que o trabalho Simulation-Ready se parece na prática: não apenas escrever código que executa, mas provar que ele permanece estável, observável e correto quando o processo continua se movendo.

Equipe de Engenharia da OLLA Lab, especializada em sistemas ciberfísicos e automação industrial.

Este artigo foi revisado por especialistas em sistemas de controle e engenharia de software industrial para garantir a precisão técnica das práticas de depuração de memória em ambientes de borda.

- IEC 61131-3: Controladores programáveis — Parte 3 - Família de normas de segurança funcional IEC 61508 - NIST AI Risk Management Framework (AI RMF 1.0) - EU AI Act: estrutura regulatória - Visão geral da cibersegurança industrial ISA/IEC 62443