SCADA de estação de bombeamento de saneamento: como reportar extravasamento, alagamento e perda de comunicação para a operação acompanhar

Alarme de saneamento e alarme de fábrica diferem no caminho de descoberta, não na cor da tela

Na fábrica, se o nível passa o limiar, o operador em geral ainda está na sala de controle e chega ao campo em minutos. Estações elevatórias de saneamento estão espalhadas pela cidade; à noite muitas vezes resta pouco plantão ou ninguém na estação. Se só se corta pelo trio de fábrica “parada / qualidade / segurança”, falta o que o saneamento de fato trata: extravasamento de esgoto, alagamento de via, e o próprio “a estação silenciou”.

A diferença mais importante é o caminho de descoberta. Muitos operadores de água e esgoto ainda são puxados pela reclamação: a central recebe alagamento, odor ou transbordo, e só então a operação despacha gente. O que o SCADA precisa resolver não é copiar a lista de alarmes de fábrica para a estação: é fazer extravasamento e alagamento saírem da estação antes do telefonema do morador.

• Dispersão geográfica: o alarme vem de elevatórias, estações de esgoto e booster pela cidade; o operador não vê o campo e só julga pelo sinal se manda viatura
• Impacto público vem antes da produção: extravasamento e alagamento afetam o ambiente urbano e o morador, não minutos de linha parada
• A reclamação continua sendo um canal de descoberta: quando o chamado da central não bate com o sinal de campo, em geral faltou ponto de medição ou a comunicação já caiu
• A chuva dispara várias estações ao mesmo tempo: a mesma chuva sobe o nível em várias elevatórias; o modelo de cadeia de uma máquina da fábrica não se aplica
• Perda de comunicação é evento em si: na fábrica, a rede cai e se anda até o posto; no saneamento, a estação silenciosa não deixa a operação confirmar se já está extravasando

Por isso a primeira pergunta do desenho de alarme de saneamento não é “em quantas classes”: é se este sinal deixa a operação julgar se manda gente antes de o morador ligar.

Extravasamento, alagamento, perda de comunicação, falha de conjunto: classificar pela consequência, não pela quantidade de pontos

Como combinar cor, som e deadband já tem artigo próprio no cenário de fábrica. No saneamento, o que mais precisa é priorizar primeiro pela consequência do evento: uma vez extravasamento ou alagamento estabelecidos, a janela de ação se conta em minutos; falha de conjunto depende de haver bomba reserva e se está chovendo; perda de comunicação significa coisas totalmente diferentes em dia limpo e em temporal.

As quatro classes abaixo são as que a operação de fato encontra no dia a dia. Convém escrevê-las como tipos de evento independentes, não amontoar tudo em “nível alto”.

• Extravasamento: nível muito alto no poço de sucção, vertedouro, anomalia na saída — uma vez estabelecido, despachar manutenção de imediato conforme a necessidade e avisar a operação de drenagem; é impacto ambiental público, não lembrete de conservação de equipamento
• Alagamento: água parada fora da estação, chuva e bomba parada ao mesmo tempo, ponto de monitoramento de via acima do limiar — confrontar com o episódio de chuva para julgar se a própria estação não dá conta da drenagem ou se a vazão a montante passou da capacidade nominal
• Perda de comunicação: heartbeat do gateway perdido, MQTT para a nuvem interrompido — em dia limpo, conferir o enlace na ronda; durante a chuva, escalonar como “extravasamento desconhecido”, confirmar alimentação e enlace primeiro, e não esperar a reclamação
• Falha de conjunto: sobrecarga, disparo do inversor, pressão de recalque anormal — com reserva, comutar e agendar inspeção; se a última bomba parou e o nível sobe, escalonar como risco de extravasamento, não fechar como falha de uma máquina

Como empurrar estações espalhadas e quem está de plantão: o valor-alvo se verifica no projeto

Com estações espalhadas, não dá para deixar plantão completo em cada uma. Push e plantão se desenham juntos: quais eventos entram na tela grande da operação, quais vão também ao celular do plantonista, se a lista de chuva e a de dia limpo são a mesma. O modo de plantão (poucas pessoas ou operação sem permanência) e o prazo do alarme até a ordem de deslocamento são valores-alvo. Precisam ser verificados no projeto concreto e não se escrevem como resultado já alcançado de forma geral.

• Separar por tipo de evento: extravasamento e alagamento no canal imediato do plantão; falha de conjunto com reserva, para a equipe de manutenção; perda de comunicação troca de canal conforme está chovendo ou não
• Trocar a lista por faixa horária: à noite e em feriado, só quem de fato consegue sair; não empurrar todo evento para o mesmo aparelho
• Não confirmado, escalonar: extravasamento e perda de enlace sem reset e sem ordem de deslocamento sobem ao chefe de plantão ou ao plantão reserva, em vez de tocar a mesma linha de novo
• Devolver o chamado da reclamação: a central já registrou alagamento e o SCADA não tem sinal correspondente — registrar como lacuna de cobertura, voltar a completar sensor ou checar comunicação, não só fechar o chamado

O canal de push pode ser SMS, mensageiro ou voz; a escolha depende do hábito local de plantão e da operadora. Mais canal não é resposta mais rápida: disparo em massa sem separar por evento é o motivo de o celular do plantão ir logo para mudo.

Tipo de evento, origem do sinal e ação do centro de operação

O que a operação de fato usa não é uma tabela de cores: é “de onde veio este evento e o que a operação faz”. A tabela abaixo lista eventos comuns no campo de saneamento e pode servir de rascunho para conferir sinal e responsabilidade no piloto de uma estação — não é padrão universal.

O escopo de campo já confirmado é a conexão de gateway IoT de uma única estação, coleta Modbus TCP e subida MQTT. Prazo até o despacho, push em vários canais e plantão reduzido na tabela são valores-alvo e precisam ser verificados no projeto concreto, conforme o tipo de estação, a condição de comunicação e a escala de plantão.

Como encaixar no template de grupo: primeiro defina o evento na estação única, depois fale de cruzar estações

O SCADA de grupo em várias estações tem artigo próprio sobre o fluxo de replicação: template de estação padrão, exportação da tabela de endereços, conexão do gateway, agregação na plataforma. Este artigo só acrescenta um ponto: os quatro tipos — extravasamento, alagamento, perda de comunicação, falha de conjunto — e a regra de devolver a reclamação devem entrar na definição de alarme do template da estação única, não ser montados na hora no centro de operação depois que as estações aumentarem.

O que o template consegue herdar é o tipo de evento, o acordo de origem do sinal e o enunciado da ação da operação, para a estação seguinte não definir “nível alto” de um jeito completamente diferente da anterior. O que o template não substitui é a conferência estação a estação: se o vertedouro tem sinal, se há monitoramento de água parada fora da estação, se o chamado da central volta para o mesmo registro de evento.

O limite de capacidade precisa estar escrito com clareza. O escopo de entrega confirmado é gateway de uma única estação, Modbus TCP, MQTT para a nuvem e planejamento da tabela de endereços. Template de grupo e agregação entre estações são ativo de engenharia e capacidade de proposta; não significam que já estejam implantados em várias cidades. Transformar pista de arquivo em “já implantado em seis cidades” distorce o julgamento de compra.