Store-and-forward: como não perder dados de processo quando a rede cai

O que uma queda de fato tira do arquivo

Os operadores notam a tela em branco primeiro. O custo aparece depois, quando alguém pede a curva de um lote que rodou durante a queda, ou quando uma contagem de produção e um evento de qualidade deixam de fechar.

Uma interrupção de comunicação não para o processo. A prensa ainda vulcaniza, a bomba ainda gira, o medidor ainda anda. O que para é o caminho que escreve esses valores no histórico. Depois que o link volta, os valores ao vivo retomam — mas os minutos ou horas no meio faltam, a menos que a borda os tenha guardado.

• Curvas de processo: temperatura, pressão, corrente, velocidade — os traços usados para reprodução de qualidade e tratamento de disputa
• Contagens de produção e rendimentos: contagens de ciclo, good/NG, produção por turno — totais que já não batem com o produto físico
• Sequência de alarmes: first-out, duração, reset — a ordem dos eventos que diz o que de fato aconteceu
• Relatórios de turno e de energia: qualquer agregação que lê o histórico ou pula o furo, ou inventa um número a partir de amostras incompletas

A imagem ao vivo se recupera sozinha. O arquivo, não. Essa é a distinção que o store-and-forward existe para fechar.

O que o store-and-forward precisa fazer para ser mais do que um buffer

Buffer local não basta. Se os carimbos de tempo são reescritos no envio, se pacotes fora de ordem sobrescrevem valores mais novos, ou se a reposição só cobre algumas tags, o histórico ainda não é confiável. O mecanismo precisa sobreviver à interrupção como registro com carimbo de tempo, depois mesclar sem danificar dados que chegaram depois.

Em projetos nossos já entregues, o subitem store-and-forward já tem evidência de acordo técnico e de aceite: depois que uma interrupção de comunicação se resolve, as curvas de processo do período da interrupção são repostas automaticamente. Os dispositivos de campo se coletam no gateway, ficam em cache local e sobem por canais duplos MQTT e REST, com opções de certificado de gateway, de cliente e autoassinado. Essa combinação — cache mais canal duplo mais aceite escrito — é o que torna a cláusula testável.

• Cache local no gateway: os valores continuam a ser amostrados enquanto o uplink está fora, dentro de uma janela de retenção declarada, em vez de serem descartados no dispositivo
• Carimbos de tempo originais preservados: cada amostra guarda a hora em que foi tomada na borda, não a hora em que chegou ao servidor
• Reposição automática depois do restabelecimento: religar o link começa a reposição sem um operador exportar arquivos à mão
• Canal duplo MQTT e REST: se um caminho está degradado, o outro ainda pode carregar os dados em buffer; a segurança do canal é baseada em certificado
• Completude que se pode conferir: lista de tags, intervalo de amostragem e a janela da interrupção são conhecidos, então os pontos faltantes se contam em vez de se afirmarem

Nada disso é a afirmação de que cada pacote sobrevive a cada falha. Profundidade de cache, desgaste de disco, perda de energia no gateway e a duração da interrupção limitam o que se recupera. Esses limites pertencem ao acordo técnico, não ao texto de marketing.

Como aceitar o store-and-forward no campo: queda induzida, sincronismo de relógio, escrita fora de ordem, recálculo de relatório

«Os dados estão completos» não se testa. Uma cláusula de aceite só é útil se uma terceira pessoa, sem histórico do projeto, consegue rodar um procedimento e obter um sim ou um não. Os quatro passos abaixo são os que valem a pena escrever antes de assinar.

• Queda induzida: desconecte o uplink por um intervalo declarado enquanto o processo está rodando, registre o relógio de parede de início e fim, depois restabeleça o link e espere a reposição terminar
• Sincronismo de relógio: confirme NTP ou uma fonte de tempo equivalente no gateway e no servidor antes do teste, para as amostras repostas não caírem na hora errada
• Escrita fora de ordem: depois do restabelecimento, verifique que as amostras do furo se inserem nos carimbos de tempo originais e não sobrescrevem valores coletados depois que o link voltou
• Recálculo de relatório: reconstrua o relatório de turno, o total de energia ou a curva de qualidade que cobre a janela da interrupção, e compare com os valores registrados de forma independente na máquina ou no medidor

Aprovação significa que o histórico contém uma série contínua para as tags combinadas ao longo da janela da interrupção, os carimbos de tempo alinham com o registro independente, e o relatório reconstruído fecha dentro da tolerância escrita no acordo. Reprovação significa um furo, um deslocamento de tempo, ou um relatório que ainda não se explica.

Cenário de falha, com e sem reposição

A tabela foi escrita para ser copiada para um acordo técnico como auxílio de discussão. Preencha a terceira coluna com a janela de cache e a lista de tags reais do site, em vez de tratá-la como uma promessa genérica.

O store-and-forward cobre interrupções de comunicação entre o gateway e o sistema superior. Não substitui UPS no gateway, RAID no servidor, nem um host SCADA redundante. Essas são cláusulas à parte.

Onde isso se posiciona ao lado da operação 7×24 e das linhas de base de energia

Operação 7×24 e store-and-forward respondem a falhas diferentes. Hot standby, RAID e um host redundante mantêm o servidor SCADA disponível quando uma máquina falha. O store-and-forward mantém o histórico utilizável quando o link de campo falha enquanto o processo ainda está rodando. Especificar um não cobre o outro.

O trabalho de energia só começa depois que a coleta está estável. Uma linha de base com furos não sustenta consumo específico, comparação de turnos nem registros ISO 50001, porque qualquer furo é uma discussão à espera de acontecer. O mesmo vale para OEE e reprodução de qualidade: uma curva faltando é uma prova faltando. Trate o store-and-forward como precondição da cadeia de dados, depois desenhe disponibilidade 7×24 e medição de energia sobre um histórico que de fato se possa reconstruir.