IIoT mal anders: Rezepte für den Pflanzen-Thermomix

In diesem Artikel erläutern wir unsere IIoT-Lösung zur autonomen, deklarativen Pflanzenzucht. Dieser Artikel ist der zweite in unserer Reihe zu IIoT. Der erste Artikel befasste sich mit allgemeinen Fragen und Problemstellungen zum Thema. Pflanzen zu züchten stellt einzigartige Anforderungen an Hardware, Software und die Steuerungslogik. Dies führt auch zu einzigartigen Lösungen. Unsere IIoT-Lösung ist Hardware-agnostisch, erlaubt Reparaturen und Updates in Produktion ohne Stopp und kann kosten- und zeiteffizient auf andere Anforderungen umgerüstet werden. Die Lösung ist dabei nicht auf die Pflanzenzucht beschränkt.

Vor über 100 Jahren löste das Auto das Pferd als Transportmittel ab. Durch die Mechanisierung des Transportes war der Weg für dessen Elektrifizierung und schließlich Automatisierung geebnet. Dies gipfelt im autonomen Verhalten von Autos, Mähdreschern und Flugzeugen. Ein Pferd zu automatisieren ist schwer, bei einem Automobil ist dies leichter. Auch hier bietet sich zusätzliches Potential zur Automatisierung.

Die Landwirtschaft der Zukunft

Ähnliches möchten wir mit unseren Kunden für das Züchten von Pflanzen ermöglichen. Felder und Bauern lassen sich schwerlich automatisieren, doch durch den Übergang zu mechanisierten und elektrisierten Anbausystemen ist dieser Weg leicht. Gleichzeitig lässt sich dadurch die Hürde des optimalen „Rezeptes“ angehen, also einer Abfolge von Instruktionen, wann die Pflanze auszusäen, zu bewässern und zu ernten ist. Ideale Wachstumsbedingungen können eingestellt werden und am Ende wählt der Agrarökonom lediglich ein Rezept für eine Pflanze. Dadurch erhält er ein sauberes, sicheres, reproduzierbares Lebensmittel, das auf dem Weltmarkt konkurrieren kann. Seine Arbeit wird vereinfacht auf die Auswahl der Saaten, die Überwachung der Geräte und die Vermarktung seiner Ernte. Alles wird lückenlos automatisiert protokolliert und belegt damit die Qualität und Sicherheit der produzierten Waren. Vor allem im Feld medizinischer Pflanzen ist solch eine lückenlose Überwachung relevant für geeignete Zertifizierung.

Pflanzen sind lebendig, sie wachsen, blühen und sterben. Sie benötigen u. a. Wasser, Nährstoffe, Wärme, Licht und wechselnde Luft. Sie sind vergleichsweise träge gegenüber Veränderungen ihrer Umwelt. So hat ein Lichtimpuls von wenigen Sekunden hoher Helligkeit nur geringen Einfluss auf die Pflanze. Um höchstmöglichen Ertrag zu erhalten, eignet sich die aeroponische Anbauweise, d. h. die Wurzeln stecken nicht in Erde, sondern befinden sich in Luft und werden mit Nährlösung bedampft. Dadurch werden sowohl Erde als auch Wasser gespart. Allerdings benötigen die Pflanzen mindestens alle fünf Minuten Wasser, da sie sonst regelrecht ersticken. Somit muss unser System zwingend in der Lage sein, die Pflanzen innerhalb von fünf Minuten zu „gießen“.

Fällt das System länger als fünf Minuten aus, so stirbt also die Pflanze. Dadurch kann ein mehrwöchiger Produktionslauf komplett verloren gehen. Anders als bei einem klassischen IIoT-Projekt, bei dem zum Beispiel eine Produktionsstraße automatisiert wird, ist ein kurzzeitiger Ausfall während der Aufzucht der Pflanze durchaus vergleichbar mit einem Totalschaden. Bei einer klassischen Produktionsstraße hingegen lässt sich häufig problemlos der Betrieb nach einer Störung wieder aufnehmen. Das Zeitfenster für eine Störung bei der Bewässerung der Pflanzen beträgt jedoch maximal die oben genannten fünf Minuten. Daher muss unser System in der Lage sein automatisch, schnell und sicher wieder produktiv zu werden. Das System muss ausfallende Geräte überstehen und flexibel darauf reagieren. Fest einprogrammierte Abfolgen wie in einer normalen speicherprogrammierbaren Steuerung (SPS) würden uns hier einschränken. Dies unterscheidet unser System natürlich deutlich von klassischen SPS-Systemen. Folgend gehen wir auf diese Unterschiede im Detail ein.

Der Pflanzen-Thermomix und seine Rezepte

Es ergibt sich, dass wir ein flexibles System benötigen. Ein ebenso agiler Entwicklungs- und Prototypisierungsprozess erleichtert es uns, dieses System von Grund auf zu entwerfen. Zusammen mit den Vorgaben unseres Kunden ergeben sich dadurch mehrere Randbedingungen. Zunächst war ein Revolution Pi (RevPi) mit digitalen und analogen Ein- und Ausgängen sowie Modbus- und Ethernetschnittstellen zur Gerätesteuerung vorgegeben. Der RevPi ist ein Industrie-zertifizierter Computer basierend auf dem als Open Source verfügbaren Raspberry Pi Compute Model. Als zentrale Steuereinheit kann er frei programmiert und via USB oder Ethernetschnittstellen gesteuert werden. Wir haben dafür Python genutzt, da wir so schnell verschiedene Prototypen entwickeln und testen konnten. Da keine auf Millisekunden genaue Steuerung benötigt wurde, reichte die Ausführungsgeschwindigkeit auch aus. Die Lösung lässt sich bei Bedarf nach C++, Rust u. a. portieren. In unserem Use Case war die Entwicklungsgeschwindigkeit wichtig und die die Ausführungsgeschwindigkeit mit Python ausreichend.

Unsere Lösung ist gut vergleichbar mit einem Thermomix für Pflanzen. Wir wählen ein Rezept in einer Weboberfläche aus, bspw. „Feinblättriger Basilikum“, befüllen das Gerät mit den „Zutaten“, also Setzlingen, Wasser und Nährstoffen. Das Gerät startet und nach ein paar Wochen öffnet sich die Tür der Mikroplantage mit den fertig gezüchteten Pflanzen. In der Zwischenzeit bietet uns ein Dashboard Überblicke über das Pflanzenwachstum und den Zustand der Mikroplantage. Die Nutzung und Umrüstung der Anlage benötigt keinen Techniker oder weiteres spezielles Personal und vereinfacht den Betrieb drastisch.

Das Rezept zeichnet sich durch einen deklarativen Ansatz aus, d. h. auf einer Zeitachse sind Aktionen angegeben, wie bspw. „Schalte Licht an“, „Heize auf 35°C“ oder „Bedampfe mit 10g Wasser“. Dabei ist es unwichtig für das Rezept, wer der Hersteller der konkreten Hardware ist. Wichtig ist lediglich, dass die Mikroplantage innerhalb der Spezifikation auf 35°C aufgeheizt. Vergleichbare Hardware verschiedener Anbieter kann mit wenig Aufwand ausgetauscht werden. Das Rezept kann leicht generiert und verändert werden. Es beinhaltet die Business-Logik. Jede*r Benutzer*in kann das Rezept geeignet anpassen und auf einer Mikroplantage starten. Ein*e Techniker*in ist nicht nötig. Das Rezept kann vor Start validiert werden, sodass unmögliche oder zerstörerische Abläufe nicht in Produktion kommen.

Damit unterscheidet sich unser System von einer traditionellen SPS, da statt aufwendig fest einprogrammierter Abfolgen ein dynamisches Verhalten umgesetzt wird. Dieser Ansatz ist zwar komplexer und potenziell fehleranfälliger, aber gleichzeitig flexibler gegenüber Änderungen der Umgebung und Anforderung. Das Rezept und die benutzte Hardware können in Produktion verändert werden. Das verringert die Ausfallzeiten und macht unsere Lösung wertvoller für Kunden mit breit gefächerten Anwendungsgebieten, da die Umrüstung der Mikroplantage einfach ist. Im Falle eines Ausfalls ist die Mikroplantage in der Lage, das Rezept nahtlos fortzuführen. Selbst bei einem Ausfall des RevPi ist ein Austausch dieser sowie Wiederaufnahme der Produktion innerhalb von fünf Minuten möglich. So bringt die mit der Flexibilität einhergehende Komplexität direkten Mehrwert und potentielle Fehler werden systematisch und kategorisch abgefedert. Fehler werden protokolliert und können durch Updates auch im laufenden Betrieb vollständig behoben werden. Diese Resilienz ist elementar für die maximal fünf Minuten Ausfallzeit, damit die Pflanzen überleben.

Die Software des Pflanzen-Thermomix

Softwareseitig besteht unsere Architektur aus drei wesentlichen Komponenten: der Engine, den Regelkreisläufen und den Gerätetreibern. Die Engine kümmert sich um Zeit und fordert Regelkreisläufe auf, die Instruktionen aus dem Rezept zu verarbeiten. Die Engine sieht also nicht die Hardware, sondern lediglich Instruktionen, während die Regelkreisläufe das Rezept nicht sehen. Die Regelkreisläufe werden damit beauftragt, diese Instruktionen umzusetzen, bspw. „Heize auf 35°C“. Sie implementieren die Logik zur Umsetzung, bspw., „Heize über Treiber A, bis Treiber B 35°C anzeigt“. Die Gerätetreiber sind Schnittstellen, die Regelkreisläufe interagieren nicht direkt mit der Hardware. Dadurch sind die Regelkreisläufe in der Lage, verschiedene Hardwareversionen, -hersteller und -szenarien zu bedienen. Fällt der eben genannte Treiber B aus, der die Temperatur misst, so kann nahtlos Treiber C einspringen. Sowohl Treiber B als auch C sind Temperatursensoren, aber Treiber C nutzt einen einfacheren Sensor an einer anderen Position in der Mikroplantage. Daher muss Treiber C anders behandelt werden, was im Regelkreislauf beschrieben ist.

Ein Regelkreislauf kann dabei unterschiedlich eng mit einer Hardwarekombination gekoppelt sein und lässt sich austauschen, ohne das Rezept anpassen zu müssen. Wenn bspw. ein Hersteller eine Feedbackschleife in der Hardware implementiert und ein anderer nicht, so kann dies im entsprechenden Regelkreislauf gesondert implementiert werden. Bieten beide Hersteller die gleiche Funktionalität, aber sprechen ein anderes Protokoll oder nutzen andere Adressen, werden lediglich andere Gerätetreiber benötigt. Ändert sich von einer Version auf die nächste nur eine Adresse bei gleicher Funktionalität, muss nur die Konfiguration im Treiber angepasst werden. Erst die Gerätetreiber interagieren direkt mit der Hardware. Sie beinhalten die Protokolle und erhalten „SOLL“- und „MESS“-Befehle. Die Gerätetreiber fungieren damit als Hardware Abstraction Layer. Gemeinsamkeiten unter den Treibern können dabei geteilt werden, was die Implementierung neuer Treiber stark beschleunigt.

Modulares System

Diese Dreiteilung ermöglicht uns eine Separierung von Business-Logik, dem Rezept, sowie der eigentlichen Hardware in den Gerätetreibern. Alles ist flexibel austauschbar, ohne dass andere Elemente angepasst werden müssen. Die Komponenten interagieren über abstrahierte Schnittstellen, sodass auch hier ein Austausch von Komponenten reibungslos abläuft. Diese vorgegebenen Schnittstellen vereinheitlichen die Kommunikation, was uns einen Zugewinn an Flexibilität und Geschwindigkeit bei der Produktentwicklung ermöglicht. Dieses Gesamtpaket stellt die geforderte hohe Verfügbarkeit und Resilienz sicher.

Die hohe Flexibilität ermöglicht uns, problemlos unsere Lösung auf andere Use Cases und Business-Logiken umzustellen. Im Idealfall muss nur das Rezept angepasst werden, im Extremfall die Business-Logik in den Regelkreisläufen und die Gerätetreiber, während die Architektur, Kommunikation, Resilienzmechanismen und Überwachungssysteme unangetastet funktional bleiben.

All dies macht unsere Lösung interessant für neuartige Anwendungsfelder, in denen die Anforderungen und Hürden noch nicht bekannt sind. Statt wochen- und monatelang über Anforderungen, Architekturen und ähnliches zu diskutieren, können wir zügig einen Proof of Concept umsetzen und testen. Dadurch kann in Test- und Produktionsumgebungen hypothesengetrieben gearbeitet werden. Anforderungen können so zielgenau getestet und gelöst werden. Sollte sich eine Komponente als unzureichend erweisen, kann sie problemlos ausgetauscht werden, ohne zurück ans Reißbrett zu müssen. Zusammen mit unserem Ansatz sind wir hardware-agnostisch und können eine kosten- und zeiteffiziente Lösung anbieten.

Fazit

In diesem zweiten Blogpost unserer Reihe zu IIoT haben wir aufgezeigt, wie das automatisierte Züchten von Pflanzen die Standardlösungen von IIoT in Frage stellt. Kurze und schnelle Feedback- und Entwicklungszyklen beeinflussen die Hardwarewahl, Programmiersprache und Softwarearchitektur. Gleichzeitig gewinnt unser System an Flexibilität und ist damit für breite Anwendungszwecke geeignet. In den folgenden Artikeln gehen wir näher auf die Details unserer technischen Implementierung und Architektur ein.