A different flavour of IIoT: Recipes for the plant thermomix

In this article we explain our IIoT solution for autonomous, declarative plant growing. This article is the second in our series on IIoT. The first article dealt with general questions and problems about IIoT. Growing plants offers unique requirements for hardware, software, and control logic. This also leads to unique solutions. Our IIoT solution is hardware-agnostic, allows for repairs and updates in production without interruption, and can be converted to other use cases in a cost- and time-efficient way. The solution is not limited to plant growing.

More than a hundred years ago, the car superseded the horse as the main means of transport. This mechanisation of transport paved the way for its electrification and eventual automation, culminating in the autonomous behaviour of cars, harvesters, and aeroplanes. Automating a horse is hard, automating an automobile is easier. Here, too, there is additional potential for automation.

The agriculture of the future

We want to enable something similar with our customers for growing plants. Fields and farmers are difficult to automate, but the transition to mechanised and electrified farming systems makes this path easy. At the same time, it allows the obstacle of the optimal “recipe” to be addressed, i. e. a sequence of instructions on when to plant, irrigate, and harvest the crop. Ideal growing conditions can be set and in the end the agricultural economist simply chooses a recipe for a plant. This gives him a clean, safe, reproducible food product that can compete on the world market. His work is simplified to selecting seeds, monitoring equipment and marketing his harvest. Everything is recorded in a completely automated way, proving the quality and safety of the goods produced. Especially in the field of medicinal plants, such seamless monitoring is relevant for appropriate certification.

Plants are alive, they grow, blossom, and die. They need water, nutrients, warmth, light, and changing air, among other things. They are comparatively inert to changes in their environment. A light impulse of a few seconds of high brightness has only little influence on the plant. In order to obtain the highest possible yield, the aeroponic cultivation method is suitable, i. e., the roots are not covered in soil, but are in air and steamed with nutrient solution. This saves both soil and water. However, the plants need water at least every five minutes, otherwise they literally suffocate. Thus, our system must be able to “water” the plants within five minutes.

So if the system fails for more than five minutes, the plant dies. This means that a production run lasting several weeks can be completely lost. Unlike in a classic IIoT project, in which, for example, a production line is automated, a short-term failure during the cultivation of plants can be a total loss. With a classic production line, on the other hand, operation can often be resumed without any problems after a malfunction. However, the time window for a malfunction during the irrigation of the plants is at most the five minutes mentioned above. Therefore, our system must be able to automatically, quickly, and safely become productive again. The system must be able to withstand and react flexibly to failed equipment. Fixed programmed sequences like in a normal PLC would limit us here. Of course, this clearly distinguishes our system from classic PLC systems. In the following, we will go into these differences in detail.

The plant thermomix and its recipes

It turns out that we need a flexible system. An equally agile development and prototyping process simplifies it for us to design this system from scratch. Together with our client’s specifications, this results in several constraints. First, a Revolution Pi (RevPi) with digital and analogue inputs and outputs as well as Modbus and Ethernet interfaces for device control was specified. The RevPi is an industry-certified computer based on the open-source Raspberry Pi Compute Model. As the main control unit, it can be freely programmed and controlled via USB or Ethernet interfaces. We used Python for this because it allowed us to quickly develop and test different prototypes. Since we did not need control with millisecond precision, the execution speed was sufficient. If necessary, the solution can be ported to C++, Rust, and others. In our use case, however, the development speed was important and the execution speed with Python sufficient.

Our solution is comparable to a thermomix for plants. We select a recipe in a web interface, for example “basil”, fill the device with the “ingredients”, i. e. seedlings, water, and nutrients. The device starts and after a few weeks the door of the micro-plantation opens with the ready-grown plants. In the meantime, a dashboard gives us an overview of the plant growth and the condition of the micro-plantation. The use and conversion of the unit does not require a technician or other special staff and drastically simplifies the operation.

The recipe is characterised by a declarative approach, i. e. actions are specified on a time axis, such as “switch on light”, “heat to 35°C” or “spray 10 g of water”. It is unimportant for the recipe who the manufacturer of the specific hardware is. The only important thing is that the micro-plantation heats up to 35°C within the specification. Comparable hardware from different suppliers can be exchanged with little effort. The recipe can be easily generated and modified. The recipe contains the business logic. Any user can customise the recipe and start it on a micro-plantation. A technician is not necessary. The recipe can be validated before starting, so that impossible or destructive processes do not go into production.

This distinguishes our system from a traditional PLC, since dynamic behaviour is implemented instead of hard-coded sequences. This approach is more complex and potentially more error-prone, but at the same time more flexible to changes in the environment and requirement. The recipe and the hardware used can be changed in production. This reduces downtime and makes our solution more valuable to customers for a wide range of applications as it is easy to retool the micro-plantation. In the event of a failure, the micro-plantation is able to continue the recipe seamlessly. Even if the RevPi fails, it can be replaced and production resumed within five minutes. Thus, the complexity that comes with flexibility brings direct added value and potential errors are systematically and categorically mitigated. Errors are logged and can be completely eliminated through updates, even during operation. This resilience is elementary for the maximum five-minute downtime so that the plants survive.

The software of the plant thermomix

On the software side, our architecture consists of three main components: the engine, the circuits, and the device drivers. The engine takes care of time and asks circuits to process the instructions from the recipe. The engine does not see the hardware, but only instructions, while the circuits do not see the recipe. The circuits are tasked with implementing these instructions, e. g. “heat to 35°C”. They contain the logic for the implementation, e. g., “heat via driver A until driver B indicates 35°C”. The device drivers implement interfaces, providing an abstraction, so the circuits do not interact directly with the hardware. This means that the circuits are able to operate different hardware versions, manufacturers, and scenarios. If the aforementioned driver B, which measures the temperature, fails, driver C can seamlessly step in. Both drivers B and C are temperature sensors, but driver C uses a simpler sensor at a different position in the micro-plantation. Therefore, driver C must be treated differently, which is described in the circuit.

A circuit can be differently coupled with a hardware combination and can be exchanged without having to adapt the recipe. For example, if one manufacturer implements a feedback loop in the hardware and another does not, this can be implemented separately in the corresponding circuit. If both manufacturers offer the same functionality but speak a different protocol or use different addresses, only different device drivers are required. If only one address changes from one version to the next with the same functionality, only the configuration in the driver must be adapted. Only the device drivers interact directly with the hardware. They contain the protocols and receive “SET” and “GET” commands. The device drivers thus function as a hardware abstraction layer. Similarities among the drivers can be shared, which greatly accelerates the implementation of new drivers.

These three components allow us to separate business logic, the recipe, and the actual hardware in the device drivers. Everything can be exchanged flexibly without having to adapt other elements. The components interact via abstracted interfaces, so that an exchange of components is as smoothly possible. These predefined interfaces standardise communication, which allows us to gain flexibility and speed in product development. This package as a whole ensures the required high availability and resilience.

The high flexibility enables us to easily adapt our solution to other use cases and business logic. Ideally, only the recipe needs to be adapted, in extreme cases the business logic in the circuits and the device drivers, while the architecture, communication, resilience mechanisms and monitoring systems remain functional.

All this makes our solution interesting for novel fields of application where the requirements and hurdles are not yet known. Instead of spending weeks and months discussing requirements, architectures and the like, we can quickly implement and test our proof-of-concept. This allows hypothesis-driven work in test and production environments. Requirements can thus be tested and solved precisely. If a component proves to be insufficient, it can easily be replaced without having to go back to the drawing board. Together with our approach, we are hardware-agnostic and can offer a cost- and time-efficient solution.

Conclusion

In this second blog post of our series on IIoT, we have shown how automated plant growing challenges the standard solutions of IIoT. Short and fast feedback and development cycles influence the hardware choice, programming language, and software architecture. At the same time, our system gains flexibility and is thus suitable for a broad range of use cases. In the following articles, we will go into more detail about our technical implementation and architecture.