Se os sensores de metano, temperatura e umidade tiverem precisão suficiente, será possível analisar os três conjuntos de dados em conjunto imediatamente? Não necessariamente. Se o valor de metano representa o ar das 10:00, enquanto a temperatura corresponde às 10:03 e a umidade ao estado das 9:58, os três números reunidos em uma linha não descrevem o mesmo fenômeno. Uma diferença de poucos minutos entre sensores pode parecer pequena, mas pode inverter causa e efeito em torno de eventos rápidos, como alimentação, acionamento de ventiladores e abertura de portas.
A sincronização de tempo não consiste apenas em acertar o horário exibido na tela. É preciso distinguir o momento em que o fenômeno ocorreu, o momento em que o sensor produziu o valor, o momento em que o gateway recebeu o valor, o momento em que o servidor o armazenou e o momento em que foram realizados a correção e o agrupamento, gerenciando as relações e incertezas entre eles. Sem essa distinção, dados normais que chegam atrasados viram anomalias, e uma falha de comunicação pode ser interpretada como uma mudança real de concentração.
Quatro maneiras pelas quais o erro do relógio altera a análise
A primeira é a distorção da correlação. Se a concentração de metano caiu durante 5 minutos após o ventilador ser ligado, mas o relógio do sensor de metano está 7 minutos adiantado, o gráfico mostrará primeiro a queda da concentração e só depois o acionamento do ventilador. O modelo analítico pode subestimar o efeito da ventilação ou estimá-lo na direção oposta.
A segunda é a perda do valor máximo e da janela do evento. Se os 30 minutos após a alimentação forem definidos como uma janela analítica e o relógio estiver deslocado em 10 minutos, parte do período de elevação ficará fora da janela em alguns sensores. Mesmo que a média diária de cada sensor seja parecida, a causa do pico e o tempo de resposta serão diferentes. A terceira é uma interpolação incorreta. Quando valores de horários diferentes são tratados como se fossem do mesmo horário e interpolados linearmente, criam-se combinações de metano e umidade que nunca existiram.
A quarta é a duplicação e o erro de ordenação. Se apenas o horário de recebimento for armazenado quando o dispositivo retransmitir dados coletados offline, um valor observado ontem aparecerá como uma mudança brusca de hoje. Se o relógio for reinicializado após uma reinicialização do dispositivo, timestamps antigos podem se repetir; se o horário de verão ou a conversão do horário local forem aplicados incorretamente, uma hora pode ser duplicada ou desaparecer. Mesmo que apenas fazendas coreanas sejam operadas, servidores, ferramentas de análise e organizações parceiras usam fusos diferentes, por isso o armazenamento baseado em UTC é mais seguro.
O horário da observação e o horário do recebimento não são intercambiáveis
A OGC SensorThings API distingue, em uma Observation, o phenomenonTime, em que ocorreu o fenômeno, do resultTime, em que o resultado foi gerado. Em um sistema de campo, também podem ser acrescentados o horário de recebimento e o horário de carregamento. A vantagem dessa estrutura é permitir separar atrasos de rede de problemas no relógio do sensor.
Por exemplo, se o horário de observação é 10:00, o horário de recebimento no gateway é 10:00:03 e o horário de carregamento na nuvem é 12:15, é provável que o sensor e a comunicação local estejam normais e que os dados tenham sido retransmitidos após uma interrupção da rede externa. Por outro lado, se vários dispositivos chegam simultaneamente ao gateway, mas apenas o horário de observação de um sensor permanece 4 minutos adiantado, pode-se suspeitar de deriva no relógio do dispositivo.
Em dispositivos simples sem relógio, o gateway pode atribuir o horário da observação. Nesse caso, os dados devem indicar timestamp_source=gateway e é necessário conhecer o atraso máximo de transmissão do dispositivo ao gateway. Copiar silenciosamente o horário de recebimento no servidor para o campo de observação pode parecer inofensivo durante a operação normal, mas produzirá grandes oscilações nos resultados em dias com atraso de comunicação.
Princípios da sincronização de tempo: considerar referência, erro e atraso em conjunto
A IETF RFC 5905 especifica a arquitetura e os algoritmos do NTPv4 para sincronizar os relógios de sistemas distribuídos de servidores e clientes de tempo. Porém, o simples fato de usar NTP não garante que todos os dados estejam corretamente alinhados. É preciso verificar quando o dispositivo foi sincronizado pela última vez, qual é o atraso de rede até o servidor de referência e como o relógio é mantido durante reinicializações e interrupções da rede externa.
Ao gerenciar a qualidade do tempo como indicador operacional, convém observar em conjunto offset, drift e uncertainty. Offset é a diferença entre o horário de referência e o horário atual do dispositivo; drift é a velocidade com que o erro aumenta ao longo do tempo; uncertainty é o intervalo ao redor do valor indicado em que o horário real da observação pode estar. Se um dispositivo ficar offline por 6 horas e seu relógio puder atrasar 1 segundo por hora, a incerteza temporal estará acumulada no momento da recuperação.
A precisão necessária deve ser calculada a partir da finalidade da análise. Em dados usados para observar tendências mensais por médias de 10 minutos, uma diferença de alguns segundos pode quase não afetar a conclusão. Já ao analisar uma resposta de 30 segundos após o controle de um ventilador ou comparar o tempo de chegada de uma pluma a sensores diferentes, um erro de 1 minuto pode ser crítico. Não é necessário exigir precisão de nanossegundos de todos os dispositivos, mas um estado de sincronização concluída sem tolerância definida também não tem significado.
Cenário de campo: por que a umidade pareceu causar a elevação do metano
Suponha que, no verão, tenha sido identificado em um galpão um padrão em que a concentração de metano aumentava 3 minutos depois de cada elevação da umidade. A equipe de análise interpretou que a mudança de umidade afetava a resposta do sensor ou a atividade dos animais. Porém, uma inspeção revelou que o sensor de umidade usava o horário do gateway, enquanto o de metano usava seu relógio interno, que estava 5 minutos adiantado em relação ao horário real. Após a correção, a elevação do metano ficou mais alinhada à alimentação e à parada do ventilador, ocorridas antes da mudança de umidade.
Nesse caso, os valores dos sensores em si não estavam errados; o que estava errado era a ordem dos eventos. Antes da correção do eixo temporal, o coeficiente de correlação e o modelo de efeito defasado podem parecer estatisticamente plausíveis e, ainda assim, levar a uma conclusão incorreta. A sincronização de tempo não é um item secundário do pré-processamento analítico, mas uma condição prévia para a interpretação causal.
Um método de verificação é criar um evento de referência. Registre um evento controlado que vários dispositivos possam detectar simultaneamente, ou uma alteração no estado do ventilador, e compare a diferença entre os timestamps. Quando possível, confronte-os com um relógio de referência independente ou com o log do gateway. Não compare apenas os horários do banco de dados: para localizar o trecho onde ocorreu o atraso, é preciso acompanhar o mesmo evento na tela do dispositivo, nos pacotes do gateway e nos logs do servidor.
Como projetar um pipeline analítico sincronizado
Nos dados originais, preserve sem alterações o horário informado pelo dispositivo. Em campos separados, mantenha o horário convertido para UTC, o horário corrigido da observação, o valor da correção, o fuso horário, o relógio de referência, o horário da última sincronização e um indicador de qualidade. Se o timestamp original for sobrescrito, posteriormente não será possível examinar a regra de sincronização.
Em seguida, estabeleça as regras de reamostragem. Se o metano for medido a cada 10 segundos, a temperatura a cada 1 minuto e a umidade a cada 5 minutos, use uma janela temporal e uma função de agregação comuns, em vez de simplesmente combinar linhas. Escolha média, mediana, manutenção do último valor ou integração conforme o significado físico. Defina a diferença máxima admissível para a correspondência temporal mais próxima e considere ausentes os valores que excedam esse limite. É preferível revelar a ausência a preencher à força um valor distante no tempo.
Também é necessário distinguir o tempo de resposta do sensor do erro do relógio. Mesmo quando recebem o mesmo ar ao mesmo tempo, metano e umidade podem responder com atraso por causa do filtro de proteção, do comprimento do tubo de amostragem, da vazão da bomba e do princípio do sensor. Esse atraso não desaparece com a sincronização de tempo; portanto, as características de resposta de cada dispositivo devem ser obtidas por testes lado a lado e incorporadas à análise.
A versão da regra de correção temporal também deve ser preservada junto com a fórmula de cálculo. Se, por exemplo, uma correção linear de drift foi aplicada apenas a determinado período, registre os horários de início e fim, o evento de referência, o coeficiente de correção e quem a aprovou. Mesmo que posteriormente sejam encontrados dados melhores do relógio de referência, não sobrescreva os dados originais: crie uma nova versão da correção para poder reproduzir tanto o relatório anterior quanto o resultado corrigido. O relatório de qualidade também deve informar quanto os principais indicadores mudaram antes e depois da correção.
As diretrizes de segurança de OT do NIST exigem que desempenho, confiabilidade e requisitos de segurança sejam considerados em conjunto nos sistemas que detectam e controlam o ambiente físico. Se um servidor de tempo ou gateway distribuir um horário incorreto por ataque ou falha, a ordem dos alarmes e os registros de auditoria também podem ser comprometidos. Fontes de tempo aprovadas, controle de acesso, logs de alterações de horário, detecção de saltos anormais e estratégia de manutenção local devem fazer parte dos critérios operacionais.
Lista de verificação para implementação
Defina o erro temporal máximo admissível e a frequência de amostragem necessária para cada análise.
Armazene em campos separados o horário da observação, da geração do resultado, do recebimento e do carregamento.
Preserve o horário original, a conversão para UTC, o valor da correção e seu motivo.
Colete, por dispositivo, a fonte de tempo, a última sincronização, o offset, o drift e a incerteza.
Teste o comportamento do tempo durante reinicializações, interrupções da rede externa e substituições do gateway.
Defina previamente a janela temporal comum, a função de agregação e a tolerância para correspondência por proximidade.
Ordene os dados retransmitidos pelo horário original da observação, não pelo horário de recebimento.
Separe o tempo de resposta do sensor do erro do relógio por meio de testes lado a lado.
Associe também os logs de eventos, como ventilador, alimentação e abertura de portas, à mesma referência temporal.
Sinalize na análise de redução os períodos cuja qualidade temporal excede o limite e avalie a sensibilidade.
Conclusão
A sincronização temporal dos dados de metano, temperatura e umidade não é uma tarefa de organização destinada a produzir gráficos mais bonitos. Ela é o sistema de coordenadas da análise que permite determinar qual evento ocorreu primeiro e como os sensores e o galpão responderam às mudanças ambientais. Mesmo com valores corretos, um horário errado pode alterar correlações, picos, tempos de resposta e o efeito estimado da redução.
Um bom sistema não confia indiscriminadamente em todos os timestamps. Ele registra a origem e o erro temporal, separa observação de transmissão e aplica tolerâncias adequadas à finalidade analítica. A primeira providência é comparar o horário atribuído ao mesmo evento nos dados de metano, temperatura, umidade e ventiladores. Quando essa diferença pode ser medida e gerenciada, os números de vários sensores finalmente passam a descrever um único local.