Let’s talk FDEX (Farming Data Exchange Standard)

The vertical farming industry desperately needs a mutual standard for data exchange. But how should something like this be designed? Read on to find out!

Our vision of vertical, indoor and urban farming is connected, to begin with. Connected means communication, means data being transferred between systems and people. So any given system that is part of that eco-system needs to know and talk the same language, in order to interpret data the same way the sender meant it.

Take HTML, as an example

Let’s call this mutual language standard from now on. In technical terms, think of it like HTML for the web. Every browser speaking HTML can display a website the same way it was intended. So HTML as a standard provides one core function: enabling consistency between differing systems.

You can of course find other standards in all kinds of industries, most importantly in content-transmitting industries like radio, television and so on. It goes without saying that each standard aims to provide the highest fidelity possible while complying with the technical limits of the system used to transfer that data. You’d want your voice to be transferred as lively as possible while taking a phone call, but sometimes the network doesn’t really allow for that. Bummer!

Let’s get back to our proposed standard for exchanging farming data. How could such a conversation look like? And between whom?

Entering: plant recipes

So-called plant recipes store ideal conditions for a given crop plant in a database. Documents like these have been proposed before, e.g. the MIT has them in their Open Ag Initiative as well as the AVF has been working to standardize them. There are also a lot of proprietary formats out there, as well as the old ones that have been printed in books (Yikes!).

These recipes describe what the plant needs, meaning all the value ranges for things like temperature, humidity, nutrients, PH, CO2-levels and everything else that is important for the plant. Let’s assume we would like to provide the most suitable temperate for a given plant using different players within one farming system.

So now the system knows the ideal conditions (whenever I say “system”, it’s actually an application on some kind of computer). What does it have to do next? Yes, well done: figure out the actual temperature. Let’s assume there is a temperature sensor connected to the system. This sensors tells the system the currently measured value.

Here’s the catch: In an ideal world, it doesn’t just dump a bucket full of numbers to the controller, but sends a well formatted message clearly stating what this number actually means, which unit it has and so on.

Then, we have another player. It is an application within the software platform, either part of the core function set of the platform itself, or a third party application installed via the plugin store. Anyway, let’s call it “Temperature Control” for the moment.

So the application has found there is a gap between the ideal value and the measured value. To justify it’s name, the application now sends a control impulse to the system.

So far, only information was recorded and stored, but nothing has really changed. So the platform needs to talk to the actuator and give him instructions about what to do.

Obviously, this is just step one and over-simplified. Normally, things like this might be implemented low-level, close to the hardware itself, and all the software platform would need to do is send the control impulse to turn the temperature to 17° C. It is also only the first step of an iterative process that proceeds over and over again, including all parties mentioned above.

What the fuck?

Sound simple, right? What does it even have to do with this farming standard? As simple as these messages sound for us, they can be really hard to achieve. This is mostly due to a lack of standardization. This is why we propose the Farming Data EXchange Standard (FDEX).

Let’s talk FDEX

The proposed standard consists of two parts for two different fields of application:

FDEX Level 1 describes low level data communication between hard- and software.

FDEX Level 2 describes high level data communication between hard- and software and software and software.

What it’s not

FDEX is not a communication protocol like TCP or HTTP. It is rather using different protocols to transmit clearly formatted messages. It is therefore a message exchange format, or language, like HTML as stated above.

What is a message?

A message is a collection of data being transmitted from sender to receiver. In our case, we’re talking about these specific types of messages:

Level 1

Level 1 is all the information exchanged between controller and sensor or controller and actuator. A controller is some kind of (micro-)computer. Messages exchanged are either:

• Sensor measurements
• Control impulses for actuators

Level 2

Level 2 is all the information exchanged between more complex systems, like controller and a server, for example, most probably in some kind of cloud. It could also be a gateway and the cloud, to name another example. These messages are formatted in JSON. Imagine them like a well-written letters including either:

• Consolidated sensors measurements
• A description of the system configuration, meaning all the available components connected to the system
• A set of instructions to control the actuators

Please note that this computer can be anything that is able to speak HTTP or MQTT, it can also be very tiny like an ESP8266 or some other gateway, it can be an Arduino or Raspberry Pi, your old Linux notebook or that flashy new PLC you’ve just bought, that has all the bells and whistles.

How does such a message look like, for example?

Here‘s an example for transmitting sensor values for both temperature as well as humidity:

“state”: { “sensors”: [ { “name”:”temperature“,”value”:292,15}, {“name”:”humdity”,”value”:55.3}] } }

Please note that temperature, in this case, is transmitted in Kelvin, as proposed in the International System of Units. The user chooses his unit of choice, e.g. Fahrenheit or Celsius, in the GUI only, it has no effect on calculations. 292,15 Kelvin means nothing else than 19° Celsius, by the way.

How will the standard itself look like?

This is hard to describe, but easy to show: Please see the HTML standard description as a reference. This looks a lot like the formal structure we’re using for the FDEX draft (see below).

What‘s next?

We are currently preparing a draft of the standard to open it up for discussion. A standard can only become a standard if it is widely adopted. So what we‘re trying to achieve here is a strong basis to facilitate all different kinds of use cases. But most importantly: interoperability between systems. Let‘s break down these proprietary barriers to unleash the power of a truly open system. Let‘s go FDEX!