“Keep safety data at the Edge and carbon data in the Cloud” is an easy principle to understand. Gas hazard alerts require an immediate response, while long-term carbon analysis requires substantial storage and computing resources. Dividing a real system into only these two boxes, however, leaves out important questions. Should the history of safety events be preserved in the cloud? Should raw carbon data be discarded when the internet connection fails? Where should field correction and quality checks run?
Data placement should be determined not by the name of the data, but by decision time, tolerance for disconnection, raw-data retention, computational load, confidentiality, and on-site recovery capability. A single methane observation may be used immediately for a local alert, then used again later for daily quality checks and monthly carbon aggregation. A practical architecture therefore does not choose between Edge and Cloud; it assigns distinct roles to functions and replicas.
Correcting a misconception: define responsibility before location
Edge can refer to computing and storage close to where data originate, such as within a sensor, a gateway, or a farm server. Cloud refers to remote, scalable storage and analytics services. NIST SP 500-325 explains that large-scale, heterogeneous IoT and high latency can challenge traditional cloud-centric architectures, and describes a fog model that distributes computing, management, and analytics closer to the network.
Edge is not always fast and secure, nor is Cloud always slow and unreliable. A field gateway with unstable power may stop more often than a cloud service, and unmanaged local devices can be difficult to patch and back up. Conversely, the cloud is well suited to systematizing long-term retention, version control, comparisons across farms, and access auditing, but it cannot guarantee action in the field during an external network outage.
Responsibilities should therefore be assigned to functions first. Must decisions about hazard thresholds, activation of warning lights, and safety ventilation interlocks continue on site under any failure? For how many hours or days must raw-data collection and buffering survive? Where, and with which version of the code, should carbon calculations run to support reproducibility and approval procedures? The answers determine the location.
First principle: close control loops that protect life and equipment on site
Functions directly tied to the safety of people, animals, or equipment must not depend on a round trip over the internet. Decisions to sound an alarm or place ventilation equipment in a safe state when gas concentration exceeds a hazard threshold must continue to operate locally. The cloud can monitor status and distribute policies, but protection must continue through the last validated safety rules and local sensor inputs even when connectivity is lost.
Methane analysis for carbon purposes must not be confused with gas detection for safety. Their measurement ranges, response times, installation locations, certifications, and fail-safe requirements may differ. Whether a single sensor reading can serve both purposes must be established from the device specifications and risk assessment. Correction by a carbon model or AI-based anomaly detection must not be assumed to replace statutory or on-site safety devices.
NIST SP 800-82 explains that OT senses or directly changes the physical environment and that security controls must also account for performance, reliability, and safety requirements. A safety control path needs a minimum function, a priority, manual override, a defined state on failure, and periodic testing. Permission boundaries must prevent cloud commands from bypassing local protective devices.
Second principle: raw carbon data must also survive at the Edge
The fact that carbon data are aggregated at the end of the month does not make on-site storage unnecessary. Rural communications can fail, and delays and retransmissions occur between the gateway and the cloud. The Edge must buffer raw data in order, attach integrity information, and retransmit the data when connectivity returns. Storage capacity should be determined by the expected maximum outage duration, retransmission headroom, and the priority of safety logs—not by average data generation alone.
A buffer needs a clear queue policy rather than a simple folder of files. Each record should include a device ID, observation time, receipt time, sequence number, unit, quality state, and a hash or signature. Data should be deleted under the local retention policy only after upload has been acknowledged, and duplicate transmissions should be handled safely with a unique key. The policy must also determine what is retained first when storage runs low. Original safety-event records and calibration or configuration change logs may require longer retention than routine, high-frequency environmental readings.
Local aggregation reduces transmission volume but creates a risk of discarding raw data too early. If 1-second values are transmitted only as 10-minute averages, it becomes difficult to review peaks and device anomalies later. After determining the time resolution and auditability needed for carbon measurement, reporting and verification (MRV), set different retention periods for raw data, summaries, and events.
Third principle: the Cloud handles long-term lineage and cross-farm analysis
The cloud excels at storing data from many farms under the same rules, comparing them over long periods, and managing calculation versions and approval histories. It should connect raw methane data, calibration records, animal counts, feeding, ventilation, and weather data to calculate baselines and reductions, and be able to reproduce earlier results after a methodology, emission factor, or code change.
Rather than calling the values stored in the cloud the single source of truth, it is more accurate to define the authority of each stage of the data. Raw device signals, gateway receipt records, corrected data, cleaned data for analysis, and approved reported results are records with different purposes. Do not overwrite raw data; link derivative stages and calculation lineage. Standard models such as OGC SensorThings can serve as a reference for consistently exchanging observations and metadata from heterogeneous sensors.
The cloud can run computationally intensive models across many farms and detect drift throughout the fleet. When a trained model or threshold is sent to the Edge, however, its version, signature, approver, intended targets, and rollback must be managed. A model deployment, like a firmware deployment, changes the remote code used in field decisions.
Field scenario: a 36-hour communications outage
Suppose a typhoon cuts a farm off from the external network for 36 hours. In a sound architecture, local safety alerts and ventilation protection continue to operate. The gateway stores sensor observations and fan and alert events with UTC timestamps and sequence numbers, while the display shows the cloud connectivity fault and remaining buffer time. Field staff can inspect local status and carry out manual procedures.
When connectivity returns, the gateway retransmits the oldest observations first. The cloud places them according to their original observation time, not their receipt time, removes duplicates, and checks for gaps in the original sequence numbers. It reruns the central quality checks and aggregations that could not be performed during the 36 hours and flags the delayed-upload interval. The monthly carbon report is updated only after completeness has been confirmed.
In a poor architecture, a safety alert waits for a cloud API response, raw carbon data disappear because there is no buffer, or every value is stored with the current time after recovery. The problem is not whether the system uses Edge or Cloud, but that the responsibilities of each function during a failure and the order of recovery were never designed.
Five questions for making data-placement decisions
First, within how many seconds must the decision be made? Second, must the function continue during an outage lasting how many hours? Third, would harm from a wrong decision appear in safety, production, or reporting? Fourth, how long must raw data be retained to support reproduction and verification? Fifth, can security patches, access controls, and audits be operated more reliably on the device or in the cloud?
Classify the data according to these questions. P0 safety control can use local decisions and local outputs; P1 safety and operational events can be preserved immediately on site and replicated to the cloud; P2 raw carbon data can use a local buffer and reliable retransmission; P3 long-term analytics and reporting can use cloud computation and approval; and P4 models and configurations can use central management and signed deployment to the field. The specific class names may be adapted to the organization while preserving the principle.
Implementation checklist
Inventory the decisions made from the data and their maximum allowable delay, rather than simply inventorying the data.
Test whether safety controls continue to operate without the internet or the cloud.
Size the raw-carbon-data buffer using the maximum outage duration and data generation rate.
Preserve observation times, sequence numbers, device IDs, and quality flags during retransmission.
Define rules for deduplication, gap detection, upload acknowledgment, and retries.
Set different retention periods for raw data, summaries, events, and audit logs.
Assign owners for access permissions, keys, patches, backups, and recovery at both the Edge and the Cloud.
Apply signing, canary rollout, approval, and rollback to model and configuration deployments.
Indicate how delayed-upload and model-substituted intervals affected carbon results.
Regularly exercise communications outages, storage shortages, and cloud failures.
Conclusion
Separating safety data at the Edge from carbon data in the Cloud is a useful starting point, but it is not a complete design. Safety decisions must be closed on site, and raw carbon data must also survive there during a loss of connectivity. The cloud has strengths in long-term lineage, comparisons across farms, computationally intensive analysis, and approved reporting.
A sound data-placement strategy does not pit Edge against Cloud. It assigns immediacy and resilience to the field, scalability and reproducibility to the center, and connects responsibilities so that the same records move without loss. The most important test is not the dashboard during normal operation, but what happens when the internet is disconnected. If safety functions continue, raw carbon data are preserved, and the data return to the same timeline after recovery, the placement strategy is ready to withstand real field conditions.