Data from the field: edge processing and connectivity in smart agriculture

01Desk assumptions do not hold in the field

When building web applications, I accept some things almost without question: the server is reachable, there is a connection, data that is sent arrives right away. Working on GAIA / AgroBlock, I had to accept that I could rely on none of these assumptions. An agricultural field is a very different place from the environment software is usually imagined in.

This R&D effort aims to bring IoT sensors and camera nodes together with edge processing, offline communication, AI and blockchain-based data integrity components. The work is ongoing. What I write here are not finished results but notes on how I approach the scope.

02The physical environment is part of the architecture

Collecting field data from different devices, handling changing connectivity and processing that data traceably are not needs that can be considered separately. Where a sensor stands, the conditions a camera node operates in and how often a device can talk to the center all directly affect software decisions.

So when thinking about the architecture, I try to treat the physical layer as part of the design rather than abstracting it away as just an input source. How data taken from a device moves into the next stages of the system is the question I focus on most in this work.

This approach has a practical consequence too: every decision on the software side carries an assumption about how a device will behave in the field. Writing those assumptions down explicitly, for example discussing early how long a device might stay disconnected or which data takes priority, reduces surprises later. In R&D, I find asking such questions early even more valuable than finding their answers.

IoT sensors  ──┐
Camera nodes ──┴──> edge processing ──> offline communication ──> AI and blockchain-based data integrity

03Why edge processing

In an environment where connectivity is not constant, a design that depends on sending everything to the center stays fragile. Edge processing finds a sensible place here: if part of the data is processed close to where it is produced, the system does not go completely blind when communication with the center drops. This matters even more for sources that produce large volumes of data, such as camera nodes, because moving raw data is not always possible or meaningful.

The question I ask myself here is which work should happen on the device and which at the center. I do not think there is a single right answer. The device's capacity, the state of the connection and what the data will be used for are factors that need to be weighed together. Striking that balance is one of the parts of the R&D process that takes the most thinking.

04Offline communication is not an exception

I try to think of offline communication not as an error state but as one of the system's normal operating conditions. How data is kept while there is no connection, how it is transferred when the connection returns and how its integrity is preserved along the way are not features to add later. In my view they need to be part of the design from the start.

In the field, a dropped connection is not an exception but a condition the design must account for from the start.

Coming from the web world, this perspective changed some of my habits. Showing the user an error when a request fails is not enough, because in the field there is often no user waiting in front of a screen. The system needs to recover on its own, without anyone stepping in.

05Data integrity and traceability

The blockchain-based data integrity side of the work is about data being traceable. Data that comes from different devices, at different times and under changing connectivity needs to be reliably followed later on. Blockchain is one of the approaches I am researching within this scope. I believe a technology should be used not because it is interesting but because the problem it solves is clearly defined, and I evaluate this component within that frame.

I take a similar stance on the AI component. Making sense of field data is part of this scope, but which work happens where depends on the overall balance between the edge and the center. To me, the value of this R&D work comes from thinking about the components together within one system rather than one by one.