Una plataforma de datos de carbono parece más fiable cuando se contempla en una pantalla conectada a internet. Las lecturas de los sensores forman una curva continua, los indicadores de cada explotación se actualizan y el botón para generar informes funciona. Sin embargo, en las explotaciones la conexión se interrumpe por zonas sin cobertura móvil, fallos del router, problemas de calidad del suministro eléctrico o tareas de mantenimiento de los equipos. En ese momento, más grave que una breve congelación de la pantalla es que desaparezcan las pruebas que permitirán explicar más adelante qué se midió realmente.

Los Carbon Data tienen una naturaleza distinta de los registros de una aplicación convencional. Pueden utilizarse para comparar el antes y el después de una actuación, para revisiones externas y para informes de la cadena de suministro; por eso deben conservarse no solo los valores, sino también el momento de la medición, el dispositivo, el estado de calibración, los indicadores de calidad y el historial de transformaciones. Si, por comodidad, se rellena con una línea recta un intervalo sin conexión o se contabilizan dos veces los mismos datos tras restablecerla, la propia estimación de la reducción pierde fiabilidad. El diseño Edge–Cloud no es un problema de tecnología de conexión, sino de continuidad de las pruebas.

Aclarar primero un malentendido: ¿los datos están seguros si existe una copia en la nube?

Los datos que ya se han subido a la nube pueden protegerse, pero los generados durante una interrupción todavía no existen en ella. Si se confía únicamente en la memoria temporal del dispositivo de campo, pueden desaparecer al reiniciarlo o cuando se agote el espacio de almacenamiento. Tampoco basta, en el extremo contrario, con dejar un archivo en un disco local. Si el archivo está dañado, la hora es incorrecta, se desconoce si terminó de transmitirse o no puede comprobarse quién lo modificó, no constituye un registro verificable.

También hay que distinguir entre «se ha cortado internet» y «se ha detenido el sensor». Es posible que el sensor haya seguido recopilando datos con normalidad y que solo se haya perdido el enlace ascendente, o que la recopilación se haya interrumpido porque el gateway se quedó sin alimentación. Si ambas situaciones se muestran como el mismo hueco, los usuarios de los datos no pueden conocer la causa. El estado de la recopilación, el del almacenamiento local y el de la recepción en la nube deben observarse por separado.

Se necesitan tres marcas de tiempo y un identificador

En cada registro de datos de campo resulta útil disponer, como mínimo, de tres tipos de marcas de tiempo. observed_at indica cuándo realizó la observación el sensor; received_at_edge, cuándo la recibió el gateway; e ingested_at_cloud, cuándo la recibió la nube. Con una conexión normal son casi idénticas, pero las diferencias aumentan cuando hay interrupciones y retransmisiones. Es necesario conservarlas para poder distinguir un retraso de medición de uno de transmisión.

Es más seguro intercambiar las horas en un formato que incluya un desfase explícito con respecto a UTC y convertirlas a la hora local solo al mostrarlas en pantalla. RFC 3339, actualizado posteriormente por RFC 9557, define una representación uniforme de las marcas de tiempo para los protocolos de internet. Durante los periodos en que el reloj de un dispositivo no esté sincronizado, en vez de descartar los valores hay que registrar también clock_status, el error estimado y el evento de corrección del reloj. Sobrescribir sin dejar rastro una hora incorrecta puede llevar a relacionar equivocadamente los episodios de alimentación o ventilación con variaciones del metano.

Cada observación necesita un event_id que no colisione a escala global. Al retransmitirla, debe conservarse el mismo ID en lugar de tratar la observación como un dato nuevo. El servidor debe garantizar la idempotencia para que volver a recibir un ID ya procesado no incremente el cómputo de la reducción. El estándar HTTP también explica que los métodos idempotentes, como PUT, son adecuados para los reintentos automáticos porque repetir una solicitud idéntica produce el mismo efecto previsto. Aunque se utilice POST, pueden definirse una clave de idempotencia independiente y reglas de detección de duplicados.

Escenario de campo: cuatro errores tras una interrupción de 17 horas

Supongamos que una explotación pierde la conexión a internet desde las 3 de la tarde hasta las 8 de la mañana del día siguiente. Los sensores y el gateway siguen funcionando y almacenan localmente datos cada 10 segundos. Al restablecerse la conexión, el primer riesgo es una avalancha de transmisiones. Los últimos valores en tiempo real compiten con los datos acumulados durante 17 horas, de modo que algunos mensajes pueden caducar o llegar desordenados.

El segundo riesgo son los duplicados. Si el gateway transmite, pero la conexión vuelve a caer antes de recibir una respuesta, no puede saber si el envío se completó. Reenviar el mismo lote tras la recuperación es lo correcto, pero si el servidor contabiliza dos veces un mismo evento, las emisiones también se duplican. El tercer riesgo es un error temporal: si el dispositivo se reinicia durante la interrupción y su reloj vuelve al estado inicial, el orden de las observaciones puede invertirse. El cuarto es el agotamiento del almacenamiento. Si la capacidad no se calculó de antemano, los datos brutos más antiguos pueden sobrescribirse sin aviso.

Para evitar estos cuatro errores, el gateway debe confirmar primero los datos en una cola duradera, asignarles un ID de evento y un número de secuencia y, después, transmitirlos. Solo debe eliminar, conforme a la política local de conservación, aquellos datos cuya recepción y almacenamiento persistente haya confirmado la nube. Las alertas recientes y los datos históricos acumulados deben enviarse con prioridades distintas, y el servidor debe calcular los intervalos que faltan por explotación, dispositivo y secuencia. La recuperación no debe declararse completa porque aparezca el estado «conectado», sino después de conciliar el número de eventos previstos con los recibidos, duplicados y dañados.

Cómo repartir las funciones entre Edge y Cloud

El edge es el repositorio de pruebas más próximo a la medición. Se encarga de recibir los datos brutos, efectuar una validación básica del esquema, asociar el estado del dispositivo, almacenar localmente con cifrado, asignar números de secuencia, mantener la cola de transmisión y emitir las alertas locales imprescindibles. Incluso durante una interrupción, el personal operador debe poder consultar el estado reciente y el espacio de almacenamiento disponible. Los cambios locales en configuraciones importantes también deben quedar registrados en el historial de auditoría.

La nube es la capa que integra múltiples dispositivos y periodos. Se ocupa de eliminar duplicados, conservar datos a largo plazo, gestionar versiones, separar los permisos de las distintas explotaciones y ofrecer análisis, informes y API externas. No considera que los cálculos agregados por el edge sean una verdad incuestionable, sino que los vincula con los datos brutos y con la versión del cálculo. Si un resultado recalculado en la nube difiere del generado en campo en aquel momento, no deben sobrescribirse ambos valores: hay que registrar la diferencia y su motivo.

El contrato entre ambas capas se especifica mediante el esquema de mensajes. Los campos obligatorios incluyen los identificadores de la explotación, la nave ganadera, el dispositivo y el sensor; el ID de evento; el número de secuencia; las horas de observación y recepción; el valor medido y su unidad; el estado de calidad; y las versiones de calibración y configuración. Cuando cambie la versión del esquema, deben establecerse reglas de compatibilidad y un periodo de migración para evitar que los dispositivos antiguos sean rechazados de repente. También hay que decidir si se ignorarán los campos desconocidos y si se pondrán en cuarentena los datos a los que les falte un campo obligatorio.

Diseñar con cifras la capacidad y el periodo de conservación

«Un disco suficientemente grande» no es un requisito. La capacidad mínima debe calcularse multiplicando el número de sensores × la frecuencia de muestreo × el tamaño del mensaje × la duración máxima de la interrupción, y sumando la sobrecarga de índices, registros y cifrado, además de un margen de seguridad. Por ejemplo, debe comprobarse si el sistema sigue soportando la interrupción máxima cuando aumenta el número de sensores o se activa un modo de alta resolución. Hay que avisar al personal operador cuando el uso del disco supere los umbrales de advertencia y peligro.

No es necesario conservar todos los datos de forma permanente, pero el orden de eliminación debe responder a su valor probatorio. Tienen prioridad alta los datos brutos vinculados con incidentes de seguridad y declaraciones sobre carbono, los cambios de calibración y configuración y los registros de las decisiones de calidad. Los registros de depuración y las cachés reproducibles pueden tener una prioridad menor. Se permiten la compresión y la agregación, pero la política debe dejar constancia del momento en que se eliminan los originales, la fórmula de transformación reproducible y la persona responsable de la conservación.

Las copias de seguridad tampoco deben evaluarse por la mera «existencia de una copia», sino por la posibilidad real de recuperación. NIST SP 1339 destaca que las copias de seguridad de OT deben integrarse en la gestión de cambios, crearse y probarse periódicamente y revisarse durante los ejercicios de recuperación. Debe ser posible restaurar la configuración del gateway, los certificados, el esquema de mensajes, los modelos y reglas y la lista de dispositivos, y puede ser necesario separar los métodos de copia de seguridad de los datos operativos y de las claves secretas. Las pruebas de recuperación deben realizarse en un entorno aislado que no ponga en riesgo el sistema original.

Por qué la fiabilidad no debe separarse de la seguridad

Un atacante puede hacer que el sistema parezca desconectado sin cortar internet. Puede borrar la cola de transmisión, cambiar el reloj, reproducir datos antiguos o manipular la configuración del gateway. Por tanto, no basta con cifrar la transmisión de datos. Se necesitan una identidad propia de cada dispositivo, rotación de certificados, actualizaciones firmadas, protección de los datos almacenados, privilegios mínimos y registros de auditoría inmutables o replicados en un sistema externo.

Para comprobar la integridad, puede conservarse el hash de cada lote de mensajes y su vínculo con el lote anterior. Sin embargo, la existencia de un hash no significa que las lecturas de los sensores reflejen fielmente la realidad. El hash solo detecta cambios posteriores al registro; no puede corregir valores que ya se midieron mal desde el principio debido a una configuración manipulada. La calibración, los precintos físicos, las inspecciones de campo y los controles de integridad de datos deben aplicarse de forma conjunta.

Lista de comprobación para la puesta en práctica

  • ¿Se han definido para cada explotación la duración máxima prevista de una interrupción y su justificación?

  • ¿Se ha calculado la capacidad de almacenamiento local a partir del número de sensores, la frecuencia y el tamaño de los mensajes?

  • ¿Se distinguen la hora de observación, la de recepción en el edge y la de ingesta en la nube?

  • ¿Permiten el ID de evento y el número de secuencia de cada dispositivo detectar duplicados, omisiones y cambios de orden?

  • ¿Se evita que el resultado agregado aumente aunque se repita la retransmisión?

  • ¿Se conservan los datos brutos hasta que se confirme que la transmisión ha terminado?

  • ¿Funcionan las prioridades de eliminación y las alertas locales cuando queda poco espacio en disco?

  • ¿Se registran como estado de calidad los fallos de sincronización del reloj y los intervalos en los que hubo reinicios?

  • ¿Se han probado realmente las copias de seguridad y la recuperación de la configuración, los certificados, el esquema y los datos?

  • ¿También se registran en el historial de auditoría los cambios de configuración y las intervenciones manuales durante una interrupción?

  • ¿Se concilia después de la recuperación el número previsto de registros con los recibidos, duplicados y dañados?

  • ¿Se muestra con claridad que la falta de recepción en la nube no significa que el sensor no haya medido?

Conclusión: hay que completar la recuperación de las pruebas, no solo la conexión

La interrupción de internet no es una excepción, sino una de las condiciones normales de funcionamiento de un sistema para explotaciones ganaderas. Una buena arquitectura Edge–Cloud no presupone una red que nunca falle. Sigue recopilando durante el corte, confirma los datos localmente de forma segura, los reenvía con el mismo identificador, los integra en el servidor sin duplicados y registra como estados de calidad las omisiones y los errores del reloj.

La recuperación tampoco termina cuando el icono de conexión vuelve a ponerse verde. Es necesario conciliar la secuencia de eventos antes y después de la interrupción, la cantidad de datos, el reloj del dispositivo, la versión de configuración y la integridad para que continúe la Evidence Chain de los Carbon Data. Decir que los datos de carbono «siguen vivos» no significa que los valores permanezcan guardados en algún sitio, sino que cualquier persona podrá explicar más adelante qué se observó y cómo se transmitió.

Fuentes