Uma plataforma de dados de carbono parece mais estável quando vista em uma tela conectada à internet. Os valores dos sensores formam curvas contínuas, os indicadores de cada fazenda são atualizados e o botão de gerar relatórios funciona. Porém, nas fazendas, a conexão cai devido a áreas sem cobertura móvel, falhas no roteador, problemas na qualidade da energia e manutenção de equipamentos. Nesse momento, um problema maior do que a tela ficar temporariamente parada é o desaparecimento das evidências que permitiriam explicar mais tarde o que de fato foi medido.

Carbon Data tem uma natureza diferente dos logs comuns de aplicativos. Como pode ser usado em comparações antes e depois da implementação, análises externas e relatórios da cadeia de suprimentos, é preciso preservar não apenas os valores, mas também o horário da medição, o dispositivo, o estado de calibração, os sinalizadores de qualidade e o histórico de transformações. Preencher por conveniência um período sem conexão com uma linha reta ou contabilizar duas vezes os mesmos dados após a reconexão compromete a própria estimativa de redução. O projeto Edge–Cloud não é uma questão de tecnologia de conectividade, mas de continuidade das evidências.

Corrigindo primeiro um equívoco: ter backup na nuvem significa que os dados estão seguros?

Os dados já enviados à nuvem podem ser protegidos, mas aqueles gerados durante a interrupção ainda não existem na nuvem. Se a memória temporária do dispositivo de campo for a única garantia, os dados podem desaparecer após uma reinicialização ou por falta de espaço de armazenamento. Por outro lado, deixar um arquivo no disco local também não resolve tudo. Se o arquivo estiver corrompido, o horário estiver incorreto, não for possível saber se o envio foi concluído ou não houver como verificar quem o alterou, ele não será um registro verificável.

Também é preciso distinguir entre “a internet caiu” e “o sensor parou”. O sensor pode ter continuado a coletar normalmente, enquanto apenas o uplink foi interrompido; ou a própria coleta pode ter parado devido a uma falha de energia no gateway. Se as duas situações forem exibidas apenas como lacunas, quem utiliza os dados não conseguirá identificar a causa. O estado da coleta, o estado do armazenamento local e o estado do recebimento na nuvem devem ser observados separadamente.

São necessários três horários e um identificador

Para cada registro de campo, é útil manter pelo menos três tipos de horário. observed_at é o horário em que o sensor fez a observação, received_at_edge é o horário em que o gateway a recebeu, e ingested_at_cloud é o horário em que a nuvem a recebeu. Em uma conexão normal, eles são quase iguais, mas a diferença aumenta quando ocorrem interrupções e retransmissões. Preservar essa diferença permite distinguir o atraso da medição do atraso da transmissão.

É mais seguro trocar os horários em um formato com um deslocamento explícito em relação ao UTC e convertê-los para o horário local na interface. A RFC 3339, posteriormente atualizada pela RFC 9557, define uma representação consistente de timestamps em protocolos da internet. Durante os períodos em que o relógio do dispositivo não estiver sincronizado, em vez de descartar os valores, registre também clock_status, o erro estimado e os eventos de correção. Sobrescrever silenciosamente um horário incorreto pode levar a associações erradas entre eventos de alimentação ou ventilação e alterações no metano.

Cada observação precisa de um event_id que não entre em conflito globalmente. Ao retransmitir, mantenha o mesmo ID em vez de criar a mesma observação como se fosse um novo dado. O servidor deve garantir idempotência para que os totais de redução não aumentem mesmo se um ID já processado for recebido novamente. O padrão HTTP também explica que métodos idempotentes como PUT são adequados para novas tentativas automáticas, pois a repetição da mesma solicitação produz o mesmo efeito pretendido. Mesmo ao usar POST, é possível definir uma chave de idempotência separada e regras de detecção de duplicidade.

Cenário de campo: quatro erros após uma interrupção de 17 horas

Suponha que uma fazenda fique sem internet das 3 da tarde até as 8 da manhã seguinte. Os sensores e o gateway continuam funcionando e armazenam localmente dados em intervalos de 10 segundos. Quando a conexão é restabelecida, o primeiro risco é uma enxurrada de transmissões. Os valores mais recentes, em tempo real, passam a competir com os dados acumulados durante 17 horas, e algumas mensagens podem expirar ou chegar fora de ordem.

O segundo risco é a duplicidade. Se o gateway transmitir os dados, mas a conexão cair novamente antes de receber a resposta, não será possível saber se o envio foi bem-sucedido. Reenviar o mesmo lote após a recuperação é a conduta correta, mas, se o servidor contabilizar o mesmo evento duas vezes, as emissões também serão duplicadas. O terceiro risco é um erro de horário. Se o dispositivo reiniciar durante a interrupção e o relógio for redefinido, a ordem das observações pode se inverter. O quarto risco é exceder a capacidade de armazenamento. Se a capacidade não tiver sido calculada previamente, os dados brutos mais antigos poderão ser sobrescritos silenciosamente.

Para evitar esses quatro erros, o gateway deve primeiro confirmar os dados em uma fila durável, atribuir um ID de evento e um número de sequência e só então transmiti-los. Apenas os dados cuja recepção e persistência tenham sido confirmadas pela nuvem devem ser removidos de acordo com a política de retenção local. Alertas recentes e o acúmulo histórico devem ser transmitidos com prioridades diferentes, e o servidor deve calcular os intervalos ausentes por fazenda, dispositivo e sequência. A recuperação só deve ser declarada concluída após conferir se as quantidades esperada, recebida, duplicada e corrompida de eventos correspondem, não apenas porque o sistema indica “conectado”.

Como dividir as funções entre Edge e Cloud

A borda é o repositório de evidências mais próximo da medição. Ela é responsável por receber os dados brutos, executar a validação básica do esquema, associar o estado do dispositivo, armazenar localmente com criptografia, atribuir números de sequência, manter a fila de transmissão e emitir os alertas locais mínimos. Mesmo durante uma interrupção, o operador deve conseguir ver o estado recente e o espaço disponível. Alterações locais em configurações importantes também devem ser registradas no log de auditoria.

A nuvem é a camada que integra vários dispositivos e períodos. Ela é responsável pela deduplicação, retenção de longo prazo, controle de versões, separação de permissões entre fazendas, análises, relatórios e APIs externas. Os agregados calculados na borda não devem ser tratados automaticamente como verdade; eles devem permanecer vinculados aos dados brutos e à versão do cálculo. Se um resultado recalculado na nuvem diferir daquele gerado no campo na época, não sobrescreva um pelo outro: registre a diferença e sua causa.

O contrato entre as duas camadas deve ser explicitado em um esquema de mensagens. Os campos obrigatórios incluem identificadores da fazenda, do galpão, do dispositivo e do sensor; ID do evento; número de sequência; horários de observação e recebimento; valor medido e unidade; estado de qualidade; e versões de calibração e configuração. Quando a versão do esquema mudar, devem existir regras de compatibilidade e um período de migração para evitar que dispositivos antigos sejam rejeitados repentinamente. Também é necessário definir se campos desconhecidos serão ignorados e se dados sem campos obrigatórios serão isolados.

A capacidade de armazenamento e o período de retenção devem ser projetados com números

“Um disco grande o suficiente” não é um requisito. A capacidade mínima deve ser calculada multiplicando o número de sensores pela frequência de amostragem, pelo tamanho das mensagens e pelo período máximo de interrupção, e acrescentando a sobrecarga de índices, logs e criptografia, além de uma margem de segurança. É preciso testar, por exemplo, se o sistema suporta o período máximo de interrupção mesmo quando novos sensores são adicionados ou o modo de alta resolução é ativado. Quando a utilização do disco ultrapassar os limiares de alerta e perigo, o operador deve ser avisado.

Nem todos os dados precisam ser preservados para sempre, mas a ordem de exclusão deve refletir o valor das evidências. Dados brutos associados a incidentes de segurança e alegações de carbono, alterações de calibração e configuração e logs de decisões de qualidade têm prioridade alta. Logs de depuração e caches que possam ser recriados podem ter prioridade baixa. Compressão e agregação podem ser permitidas, mas a política deve registrar quando o original será excluído, qual transformação reproduzível foi aplicada e quem é responsável pela retenção.

O backup também deve ser avaliado pela capacidade de recuperação, não pela mera “existência de uma cópia”. A NIST SP 1339 enfatiza que os backups de OT devem ser integrados ao gerenciamento de mudanças, criados e testados regularmente e analisados em exercícios de recuperação. Deve ser possível restaurar as configurações do gateway, os certificados, o esquema de mensagens, os modelos e regras e a lista de dispositivos, e os métodos de backup dos dados operacionais e das chaves secretas precisam ser separados. Os testes de recuperação devem ser executados em um ambiente isolado que não coloque o sistema original em risco.

Por que a confiabilidade não deve ser separada da segurança

Um invasor pode fazer o sistema parecer desconectado sem interromper a internet. Ele pode apagar a fila de transmissão, alterar o relógio, reproduzir dados antigos ou manipular as configurações do gateway. Por isso, criptografar apenas a transmissão dos dados não é suficiente. São necessários identidade exclusiva do dispositivo, rotação de certificados, atualizações assinadas, proteção dos dados armazenados, privilégio mínimo e logs de auditoria imutáveis ou replicados externamente.

Para verificar a integridade, é possível registrar o hash de cada lote de mensagens e seu vínculo com o lote anterior. No entanto, a existência de um hash não significa que os valores dos sensores representem a realidade com exatidão. O hash apenas detecta alterações posteriores ao registro; ele não corrige valores medidos incorretamente desde o início devido a configurações manipuladas. Calibração, lacres físicos, inspeções em campo e controles de integridade dos dados devem funcionar em conjunto.

Checklist de implementação

  • Foi definido o tempo máximo previsto de interrupção para cada fazenda e sua justificativa?

  • A capacidade de armazenamento local foi calculada com base no número de sensores, na frequência e no tamanho das mensagens?

  • O horário da observação, o horário de recebimento na borda e o horário de ingestão na nuvem são diferenciados?

  • É possível detectar duplicidades, lacunas e inversões de ordem com o ID do evento e o número de sequência de cada dispositivo?

  • O resultado agregado permanece inalterado mesmo após retransmissões repetidas?

  • Os dados brutos são mantidos até a confirmação da conclusão da transmissão?

  • Em caso de falta de espaço em disco, a prioridade de exclusão e o alerta local funcionam?

  • Falhas de sincronização do relógio e períodos de reinicialização ficam registrados como estados de qualidade?

  • O backup e a recuperação de configurações, certificados, esquemas e dados foram testados na prática?

  • Alterações de configuração e intervenções manuais feitas durante a interrupção também são registradas no log de auditoria?

  • Após a recuperação, as contagens esperada, recebida, duplicada e corrompida são comparadas?

  • A falta de recebimento na nuvem é exibida de modo a não ser confundida com ausência de medição pelo sensor?

Conclusão: é preciso concluir a recuperação das evidências, não apenas da conexão

Uma interrupção da internet não é uma exceção, mas uma das condições normais de operação de um sistema agrícola. Uma boa arquitetura Edge–Cloud não presume uma rede ininterrupta. Ela continua coletando durante a queda, confirma os dados localmente de forma segura, reenvia-os com os mesmos identificadores, combina-os no servidor sem duplicidade e registra lacunas e erros de horário como estados de qualidade.

A recuperação também não termina quando o ícone de conexão volta a ficar verde. É preciso comparar a ordem dos eventos antes e depois da interrupção, a quantidade de dados, o relógio do dispositivo, a versão das configurações e a integridade para manter a Evidence Chain dos Carbon Data. Dizer que os dados de carbono estão “vivos” não significa apenas que os valores ficaram armazenados em algum lugar, mas que qualquer pessoa poderá entender mais tarde o que foi observado e como foi transmitido.

Fontes