Tempo de Ciclo de Coleta de Dados e Fatores de Desempenho
O ciclo de coleta (aquisição) de dados via protocolo MODBUS e SCP-HI no Portal de Telemetria possui um intervalo mínimo configurado de 30 segundos no Conector.
No entanto, este valor representa o intervalo mínimo entre o início dos ciclos, e não uma garantia de que toda a coleta será concluída dentro desse período.
Na prática, o tempo total de execução do ciclo depende de diversos fatores, incluindo a configuração do Conector, o volume de Dados cadastrados e suas configurações, o comportamento do equipamento remoto, a quantidade de registros armazenados localmente e as condições de comunicação.
Em cenários onde a comunicação ocorre através de redes móveis (como 3G, 4G ou conexões de maior latência), pode haver maior variabilidade no tempo de resposta, o que pode impactar o desempenho do ciclo de coleta.
Dependendo dessas condições, o ciclo pode levar mais tempo para ser concluído, influenciando a frequência de atualização dos dados, já que o Portal em todo ciclo, realiza a aquisiçao de todos os Dados habilitados para a coleta no Conector.
Atenção
O intervalo de aquisição configurado no Conector (ex: 30 segundos) define apenas o intervalo mínimo entre o início dos ciclos, não garantindo que todas as operações de coleta sejam concluídas dentro desse período.
Isso significa que, mesmo com um intervalo configurado de 30 segundos, eventualmente os Dados podem ser atualizados em intervalos maiores.
Esse comportamento depende dos fatores de desempenho envolvidos no processo de coleta, como volume de Dados, organização dos endereços, utilização de vetores/strings, uso de buffer, comandos de escrita e condições de comunicação.
Como funciona o ciclo de coleta
A cada ciclo de coleta no equipamento remoto, o Portal realiza as seguintes etapas:
Leitura (consumo) do buffer de registros local do equipamento, quando habilitado no Dispositivo;
Leitura dos Dados (variáveis) configurados no Conector;
Execução de comandos de escrita em dados (quando houver);
Tratamento de escritas via Mapeamento de Dados entre Conectores (quando houver);
Processamento das respostas do equipamento;
Avaliação de alarmes associados aos dados coletados;
Persistência de registros no histórico de dados (quando aplicável).
Essas operações são executadas de forma sequencial e compartilham o tempo disponível do ciclo.
É importante destacar que o buffer local e o histórico de dados são mecanismos distintos.
O buffer local é utilizado para armazenar temporariamente registros no equipamento remoto, permitindo que o Portal os consuma posteriormente. Já o histórico de dados corresponde ao armazenamento dos dados coletados pelo Portal para posterior consulta.
Portanto, a utilização do buffer local não significa que o dado esteja sendo armazenado no histórico do Portal, e a configuração de histórico de um Dado não determina a geração de registros no buffer local.
Fatores que impactam o tempo de coleta
Quantidade de Dados configurados
Quanto maior o número de Dados configurados:
Maior o número de leituras necessárias;
Maior o tempo total do ciclo.
O impacto pode ser maior quando os Dados estão distribuídos em diferentes regiões de memória ou possuem configurações que exigem maior quantidade de informações para serem lidas.
Organização dos endereços MODBUS
O Portal pode agrupar leituras quando os endereços são sequenciais (modo otimizado configurado no Conector).
Para mais detalhes sobre como essa otimização funciona, consulte Otimização de Pacotes.
Endereços agrupados/sequenciais:
Permitem que o Portal agrupe múltiplas leituras em um único comando MODBUS;
Menor quantidade de requisições ao equipamento;
Melhor desempenho e menor tempo de coleta.
Endereços dispersos:
Impedem o agrupamento de leituras pelo modo otimizado;
Cada grupo de endereços não contíguos exige um comando MODBUS separado;
Maior número de requisições ao equipamento;
Aumento proporcional no tempo total do ciclo.
Nota
Mesmo para Dados com endereços diretos, a dispersão dos endereços impede a otimização das leituras. O ideal é manter os endereços das variáveis o mais próximos possível no programa de aplicação do equipamento, permitindo que o Portal agrupe as leituras em menos comandos e reduza o tempo do ciclo de coleta.
Tipos de memória diferentes
Dados em diferentes tipos de memória (ex: COIL, Holding Register):
Exigem comandos MODBUS distintos;
Não são lidos exatamente no mesmo instante.
Isso pode resultar em diferenças de timestamp entre os dados, mesmo dentro de um mesmo ciclo de coleta.
Dados do tipo Vetor e String
Dados configurados como vetores ou strings possuem impacto adicional no ciclo de aquisição:
Vetores exigem leitura de múltiplos endereços consecutivos;
Strings são normalmente representadas como uma sequência de registradores;
O tamanho do dado (quantidade de elementos ou comprimento da string) influencia diretamente o tempo de leitura.
Impactos:
Aumento do tempo de resposta do equipamento;
Maior volume de dados trafegados na comunicação;
Possível necessidade de múltiplos comandos de leitura.
Buffer local de registros no equipamento
O buffer local é um mecanismo que permite ao programa de aplicação do equipamento remoto registrar valores de variáveis localmente para que esses registros sejam posteriormente consumidos pelo Portal de Telemetria.
Esse recurso é especialmente útil em situações em que a comunicação entre o equipamento e o Portal fica indisponível.
Durante o período de indisponibilidade, o programa de aplicação pode continuar registrando os valores no buffer. Quando a comunicação é restabelecida, o Portal passa a consumir os registros armazenados, permitindo recuperar informações que não puderam ser coletadas durante o período offline.
O funcionamento do buffer, portanto, depende de dois processos distintos:
Produção de registros: realizada pelo programa de aplicação do equipamento, de acordo com a lógica implementada e a frequência com que os registros são inseridos no buffer;
Consumo de registros: realizado pelo Portal durante os ciclos de coleta.
O Portal consome até 200 registros por ciclo e, para isso, realiza uma série de leituras específicas para o consumo desses registros no equipamento remoto.
Cada registro é processado individualmente.
Impacto do volume de registros no buffer
O uso do buffer pode aumentar o tempo de execução dos ciclos de coleta, pois o consumo dos registros armazenados exige operações adicionais de comunicação e processamento.
Quando existem registros acumulados:
O Portal precisa dedicar parte do ciclo ao consumo do buffer;
O tempo disponível para as demais operações de coleta é reduzido;
Quanto maior o volume de registros acumulados, maior pode ser o tempo necessário para recuperar essas informações;
O consumo do buffer pode competir com a leitura dos Dados associados diretamente a endereços no equipamento remoto.
Dessa forma, o buffer local deve ser utilizado considerando não apenas a capacidade de armazenamento do equipamento, mas também a capacidade do Portal de consumir os registros gerados.
Relação entre geração e consumo dos registros
Um ponto importante na utilização do buffer é a relação entre a frequência de geração dos registros no equipamento e a capacidade de consumo do Portal.
Se o programa de aplicação gerar registros mais rapidamente do que o Portal consegue consumi-los, o número de registros armazenados no buffer continuará aumentando.
Por exemplo, considere uma situação em que:
O programa de aplicação gera 300 registros entre dois ciclos de coleta;
O Portal consegue consumir no máximo 200 registros por ciclo.
Nesse cenário, mesmo que a comunicação esteja funcionando normalmente, haverá um saldo de registros que permanecerá no buffer após cada ciclo.
Se essa condição continuar, o Portal poderá permanecer continuamente processando registros antigos, fazendo com que a informação apresentada se mantenha atrasada em relação ao valor atual do equipamento.
Esse comportamento é diferente de uma simples demora pontual na coleta. Quando a taxa de geração de registros permanece maior que a taxa de consumo, pode ocorrer um acúmulo contínuo, mantendo o processamento do buffer atrasado.
Atenção
O uso do buffer local exige que a frequência de geração de registros pelo programa de aplicação seja compatível com a capacidade de consumo do Portal.
Uma configuração que gere registros em excesso pode provocar acúmulo contínuo no buffer.
Nessa situação, mesmo com a comunicação restabelecida e funcionando normalmente, o Portal poderá permanecer processando registros antigos antes de alcançar os registros mais recentes.
Como consequência, os dados provenientes do buffer podem apresentar atraso crescente ou persistente em relação ao momento em que os valores foram efetivamente registrados pelo equipamento.
Comportamento após perda de comunicação
Quando a comunicação com o Portal fica indisponível, os registros gerados pelo programa de aplicação podem permanecer armazenados localmente no buffer.
Após o restabelecimento da comunicação, esses registros passam a ser consumidos pelo Portal.
O volume acumulado dependerá principalmente de:
Duração do período em que o equipamento permaneceu offline;
Frequência com que o programa de aplicação gera registros;
Quantidade de registros gerados durante o período offline;
Capacidade de consumo do Portal;
Tempo necessário para processar cada registro.
Quanto maior o volume acumulado, maior poderá ser o período necessário para que o Portal processe todos os registros pendentes.
Durante esse período, os registros consumidos pelo Portal representam informações referentes a momentos anteriores. Portanto, a existência de registros pendentes no buffer pode fazer com que os dados processados pelo Portal estejam temporalmente atrasados em relação ao estado atual do equipamento.
Nota
O buffer local deve ser entendido como um mecanismo de armazenamento temporário e recuperação de registros, principalmente para situações de indisponibilidade de comunicação.
Ele não deve ser confundido com o mecanismo de histórico de dados do Portal.
Histórico de Dados
Quando os Dados estão configurados com histórico, o Portal persiste os registros coletados ao final de cada ciclo de coleta.
O histórico de dados possui finalidade diferente do buffer local:
O buffer local mantém registros temporariamente no equipamento para posterior consumo pelo Portal;
O histórico de dados mantém os registros coletados pelo Portal para posterior consulta e análise.
A habilitação do histórico não determina a geração de registros no buffer local.
A geração de registros no buffer depende da lógica do programa de aplicação do equipamento e da frequência com que essa aplicação insere registros no buffer.
Impactos do histórico de dados
A persistência de dados no histórico também representa uma etapa de processamento do ciclo de coleta.
Impactos:
Grande quantidade de Dados com histórico habilitado aumenta o volume de processamento ao final do ciclo;
A configuração do tipo de histórico e da taxa de armazenamento influencia diretamente o volume de registros persistidos;
Quanto maior o volume de dados a ser persistido, maior pode ser o tempo necessário para concluir o processamento do ciclo.
Avaliação de Alarmes
A cada ciclo de coleta, o Portal avalia as condições de alarme configuradas nos Dados.
Impactos:
Um alto volume de Dados com alarmes configurados aumenta o tempo de processamento por ciclo;
Em cenários com muitos Dados e alarmes que transacionam com frequência, o impacto pode ser significativo na duração total do ciclo.
Comandos de escrita
O envio de comandos de escrita em dados para o equipamento remoto pode ocorrer em diferentes situações:
Ações do usuário via interface do Portal;
Regras automáticas como Mapeamento de Dados entre Conectores;
Chamadas via API.
Impactos:
As escritas compartilham o mesmo canal de comunicação MODBUS;
Podem aumentar o tempo do ciclo quando realizadas em grande volume;
Dependem diretamente do tempo de resposta do equipamento remoto.
Latência de comunicação
O tempo de comunicação entre o Portal e o equipamento remoto é um dos fatores que podem influenciar o desempenho do ciclo.
Esse tempo pode ser impactado por:
Tempo de resposta do equipamento;
Qualidade da rede;
Uso de redes móveis (3G, 4G ou similares);
Presença de VPNs ou links com alta latência.
Em redes móveis, é comum observar:
Maior latência;
Variação no tempo de resposta;
Eventuais perdas ou retransmissões.
Essas condições podem aumentar o tempo total do ciclo de coleta.
Consequências práticas
Quando o tempo de execução do ciclo ultrapassa o intervalo configurado:
O próximo ciclo inicia com atraso;
Os Dados podem apresentar atualização mais lenta;
Pode haver maior diferença de tempo entre os registros (timestamps).
Quando existe também um volume elevado de registros pendentes no buffer local, o impacto pode ser ainda maior, pois parte do ciclo precisa ser utilizada para consumir e processar esses registros.
Em situações em que a geração de registros no buffer é continuamente maior que a capacidade de consumo, pode ocorrer um atraso persistente na leitura dos registros, mesmo que a comunicação esteja funcionando normalmente.
Boas práticas de configuração
Para garantir melhor desempenho e estabilidade:
Organize os endereços de forma sequencial, pois permite um melhor uso da leitura otimizada (consulte Otimização de Pacotes).
Evite excesso de Dados no mesmo Conector e distribua os Dados quando necessário.
Utilize Dados vetores e strings com extremo critério e prefira tamanhos adequados quando não for possível evitar.
Tenha bom senso na definição do intervalo de aquisição dos Dados, configurando um valor que respeite as condições de funcionamento do ciclo de coleta.
Ao utilizar o buffer local, configure a lógica do programa de aplicação de forma que a frequência de geração dos registros seja compatível com a capacidade de consumo do Portal.
Evite gerar registros no buffer em uma frequência excessivamente alta, principalmente quando cada registro representa uma variável ou conjunto de variáveis que não necessita dessa frequência de armazenamento.
Considere o volume de registros que poderá ser acumulado durante períodos de indisponibilidade de comunicação.
Em aplicações que utilizam buffer local, avalie não somente o funcionamento durante a comunicação normal, mas também o comportamento após períodos offline, quando uma quantidade significativa de registros poderá precisar ser recuperada.
Utilize o histórico de dados de acordo com a necessidade da aplicação. A quantidade de Dados com histórico habilitado deve ser considerada no dimensionamento do processamento, mas não deve ser confundida com a geração de registros no buffer local.
Evite excesso de comandos de escrita, especialmente em cenários com alta frequência de atualização, como por exemplo, através do recurso de Mapeamento de Dados entre Conectores.
Considere as condições de comunicação e, em redes móveis, priorize configurações mais leves e eficientes.
Resumo dos principais fatores
O desempenho do ciclo de coleta é resultado da combinação de diversos fatores. Entre os principais estão:
Intervalo de aquisição configurado;
Quantidade de Dados;
Organização dos endereços de memória;
Tipos de memória utilizados;
Tamanho de vetores e strings;
Quantidade e frequência de comandos de escrita;
Quantidade de Dados com histórico;
Quantidade de alarmes e frequência de suas transições;
Condições de comunicação;
Quantidade de registros pendentes no buffer local;
Frequência de geração de registros pelo programa de aplicação;
Capacidade do Portal de consumir os registros do buffer.
Portanto, o intervalo de aquisição configurado no Conector deve ser considerado apenas como uma referência para a periodicidade desejada. A frequência efetiva de atualização dependerá da capacidade do sistema de executar todas as operações necessárias dentro de cada ciclo.
No caso do buffer local, é especialmente importante garantir que a taxa de geração de registros pelo equipamento seja compatível com a capacidade de consumo do Portal. Caso contrário, o acúmulo de registros pode fazer com que a coleta permaneça atrasada, mesmo após o restabelecimento da comunicação.