Gabriel von Heijne – Cirkulärodling

Att bygga en akvaponi – del 6 – integration med blockkedja

Detta är en beskrivning av hur vi på Johannas Stadsodlingar och Concinnity tillsammans har byggt Johannas Akvaponi Pilotanläggning. Vi vill dela med oss hur vi har gjort och tänkt. Det är ganska mycket att tänka på, så det blir flera inlägg för att täcka det mesta.

Del 1 – att starta, förkunskaper
Del 2 – design
Del 3 – bygglogg
Del 4 – vattenkvalitet och näringstester
Del 5 – produktionsspårning
Del 6 – integration med blockkedja (denna blogpost)

Cultivation Management Platform

De digitala system vi byggt har grundats på den vision vi satte i början på projektet som vi kallar Cultivation Management Platform (CMP).

CMP kan delas upp i fyra delar:

● Vattenkvalitets- och näringstester (Water quality & nutrient tests)
● Vatten-, luft- och automationssensorer (Water & air sensors)
● Produktionsspårning (Production management)
● Distributed ledger / blockkedja (Blockchain)

I detta avsnitt beskriver vi arbetet med distributed ledger / blockkedja (Blockchain).

Vi har byggt ett system som demonstrerar hur man kan använda en distributed ledger. En distributed ledger är en databas som kan delas mellan många olika parter, där alla parter gemensamt kontrollerar informationen och där all data som lagras är ”permanent”, dvs den går i princip inte att ändra på i efterhand. Det kan låta väldigt opraktiskt, men vad man istället gör när data behöver ändras är att man refererar till den ursprungliga informationen och lägger till en ändring. På så vis blir alla förändringar av databasen synliga för alla parter. Blockkedjan, blockchain, är den underliggande teknologi som används för att garantera att informationen som lagra i databasen inte går att ändra i efterhand. (Detta är naturligtvis en mycket förenklad beskrivning av hur en distributed ledger fungerar i praktiken!)

Vi har fått tillgång till IBM Food Trust(IFT) för att bygga vår blockkedjedemonstration i samarbete med IBM och Atea som är en svensk IBM-partner. IFT är en distributed ledger baserad på open-source programvaran Hyperledger som implementerar en blockkedjebaserad databas. IFT tillhandahåller API:er för att lagra data i och hämta data från blockkedjan.

Systemet i stora drag

Data från vårt produktionsspårningssystem transformeras för att “passa” i IFT och skickas dit för lagring (XML Gen). Detta sker regelbundet med automatik så att data i IFT är synkroniserad med produktionsspårningssystemet. En andra del, Data display, hämtar information från IFT. Vi presenterar en lista över alla skördar som gjorts och man kan välja en skörd för att få en detaljerad beskrivning av alla stegen som just denna planta gått igenom på sin väg från frö till färdig produkt.

Data

Den data vi lagrar i IFT är baserad på kärnan av den data vi genererar i produktionsspårningssystemet. Detta innefattar varje steg i spårningen av en planta från groddning till skörd. All data som lagras i IFT får unika ID:n som vi sedan använder när vi hämtar information ur IFT i klientappen (Data display). På så sätt har vi kunna bygga klientappen så att den inte är beroende av någon del av den ursprungliga informationen från produktionsspårningssystemet utan all information kommer från IFT.

Implementation

Systemet består av två delar. Den första delen, XML Gen, hämtar data från produktionsspårningssystemet och efter att ha transformerat denna data till XML skickas den till IFT för lagring i blockkedjan. Den andra delen, Data display, hämtar data från IFT och presenterar den som webbsidor. Denna del hämtar informationen från IFT, där data levereras i formatet JSON, och efter transformation av denna data skapar vi vyer som webbsidor. Observera att Data display är helt oberoende av den ursprungliga informationen i produktionsspårningssystemet. Den köras som en helt oberoende tjänst eftersom den hämtar all nödvändig information från IFT.

XML Gen

Det visar sig att de händelser vi skapar i produktionsspårningssystemet låter sig översättas till liknande händelser i IFT. Den data som vi på så sätt lagrar i IFT är baserad på GS1 EPCIS Standard 17 . Vi har skapat en XML-mall för varje typ av händelse som vi sedan fyller i med aktuell data varefter den laddas upp till IFT. Utöver denna information registrerar vi varje kombination av frön och leverantörer vi använder som produkter i IFT, samt en plats, gården där vi driver akvaponin. Dessa dokument är baserade på GS1 GDSN Standard 18 och data i IFT skapas på liknande sätt från en kombination av XML-mallar och data från produktionsspårningssystemet. IBM har en wiki på GitHub med information om hur de använder dessa standarder, om API:erna mot IFT etc som vi haft mycket nytta av.

IFT definierar ett antal olika händelser och vi har använt tre typer för att registrera vår data, Commission, Observation och Transformation. Dessa tre händelser är definierade i EPCIS. Commission används när en ny enhet av en viss produkt ska registreras. Vi använder denna händelse för att registrera Groddningshändelsen. Observation används för att registrera en förändring hos en existerande enhet. Denna typ av händelse använder vi för att registrera händelserna Stickling och Skörd från produktionssystemet. Slutligen använder vi en Transformation för att registrera våra händelser av typ Planta. En Transformation “gör om” en produkt till en annan. I vårt fall transformerar vi en stickling till en planta. Detta modellerar bra den praktiska förflyttningen av sticklingarna från odlingsbrickan till flottarna där de växer till färdiga plantor.

Data display

Data display hämtar data från IFT via ett flertal API-anrop (endpoints). Med hjälp av anropet “/products” får vi en lista på alla registrerade produkter. Utifrån denna lista kan vi sedan hämta detaljer om varje skörd. Sedan hämtar vi fullständig produktdata för varje skörd så att vi kan visa vilken typ av planta och leverantör den består av. Slutligen använder vi anropet “/trace” för att få “historiken” för varje skörd, dvs de fyra händelserna i plantans liv. På så sätt kan vi visa den fulla historiken för varje skördad planta.

Diskussion

Denna prototyp är mycket “minimalistisk”, men den innefattar ändå de fundamentala delarna i ett blockkedjebaserat spårningssystem. Vi skulle kunna leverera våra produkter med en märkning i form av en streck- eller QR-kod, som länkar till en webbsida där köparen kan få den fulla historiken av hur plantan kom till.

[track’n’trace image?]

I dagsläget saknas information om vad som hänt med produkten från det att den skördats till dess att kunden har den i sin hand, men om man spårar även denna del skulle kedjan kunna förlängas och hela förloppet kunna finnas dokumenterat i blockkedjan i IFT. Den delen av spårningen skulle kunna göras av ett speditionsföretag och/eller av butiken som säljer produkten. De olika parterna skulle lagra “sin del” av informationen var för sig i blockkedjan samtidigt som kunden kan se hela det resulterande händelseförloppet.

I nästa inlägg så tittar vi närmare på lärdomar från pilotsystemet som vi byggt.

Texten i detta inlägg är licensierad under Creative Commons BY-NC-SA International.

Build an aquaponic indoor farm – part 6 – Block chain integration

This is a description of how we at Johannas Stadsodlingar (urban farms) and Concinnity together have built Johanna’s aquaponic pilot facility. We want to share how we did it and our thinking behind it. There is quite a lot to think about, so there will be several posts to cover most things.

Part 1 – start and prior knowledge
Part 2 – design
Part 3 – build log
Part 4 – water quality and nutrients testing
Part 5 – production management
Part 6 – distributed ledger/block chain integration (this post)

Cultivation Management Platform

The digital systems we have built are based around the vision we set out with at the start of the project. We call it the Cultivation Management Platform.

The CMP consists of four parts:

Water quality and nutrients tests
Water, air and automation sensors
Production management
Distributed ledger / block chain

In this part we will describe our work around integrating a distributed ledger/block chain system.

We have built a system that demonstrates how to use a distributed ledger. A distributed ledger is a database that can be shared between many different parties, where all parties jointly control the information and where all data stored is ”permanent”, i.e. it can in principle not be changed after having been recorded. This may sound very impractical, but instead of changing data you create a reference to the original information and add a change. In this way, all changes to the database become visible to all parties. The blockchain is the underlying technology used to ensure that the information stored in the database cannot be changed afterwards. (This is of course a very simplified description of how a distributed ledger works in practice!)

We have gained access to IBM Food Trust (IFT) to build our blockchain demonstration in collaboration with IBM and Atea, a Swedish IBM partner. IFT is a distributed ledger based on the open-source software Hyperledger that implements a blockchain-based database. IFT provides APIs for storing data in and retrieving data from the blockchain.

System overview

Data from our production tracking system is transformed to ”fit” in IFT and sent there for storage (XML Gen). This is done using automation so that data in IFT is continuously synchronized with the production tracking system. A second part, Data display, retrieves information from IFT. We present a list of all harvests that have been made and you can choose a harvest to get a detailed description of all the steps that this particular plant went through on its way from seed to finished product.

Data

The data we store in IFT is based on the core of the data we generate in the production management system. This includes every step in the tracing of a plant from germination to harvest. All data stored in IFT gets unique IDs which we then use when we retrieve information from IFT in the client app (Data display). In this way, we have been able to build the client so that it does not depend on any part of the original information from the production tracking system, but all information comes from IFT.

Implementation

The system consists of two parts. The first part, XML Gen, retrieves data from the production tracking system and, after transforming this data into XML, sends to IFT for storage on the blockchain. The second part, Data display, retrieves data from IFT and presents it as web pages. This part fetches the information from IFT, where data is delivered in the JSON format, and after transforming this data, we create views as web pages. Note that the Data display is completely independent of the original information stored in the production management system. Data display part can be run as a completely independent service since it retrieves all necessary information from IFT.

XML Gen

It turns out that the events we create in the production management system can be translated into similar events in IFT. The data we store in this way in IFT is based on GS1 EPCIS Standard 17. We have created an XML template for each type of event which is filled in with data for the current event and then uploaded to IFT. In addition to this information, we register every combination of seeds and suppliers we use as ”products” in IFT, as well as a ”location”, our aquaponics farm. These templates are based on GS1 GDSN Standard 18 and data in IFT is created in a similar way from a combination of XML templates and data from the production management system. IBM has a wiki on GitHub with information about how they use these standards, about the APIs of IFT etc that we have benefited a lot from.

IFT defines a number of different events and we have used three types to register our data; Commission, Observation and Transformation. These three events are defined in EPCIS. The Commission event is used when a new unit of a particular product is to be registered. We use this event to register the production management system Plant event. Observation is used to register a change in an existing unit. We use this type of event to register the events Seedling and Harvesting from the production management system. Finally, we use a Transformation to record our Plant events. It transforms one product into another. In our case, we transform a seedling into a plant. This models well the practical transfer of the seedlings from the cultivation tray to the rafts where they grow into finished plants.

Data display

Data display retrieves data from IFT via several API calls (endpoints). With the help of the call “/ products” we get a list of all registered products. Based on this list, we can then retrieve details about each harvest. Then we retrieve complete product data for each harvest so that we can show what type of plant and supplier it consists of. Finally, we use the call “/ trace” to get the “history” for each harvest, ie the four events in the plant’s life. In this way we can show the full history of each harvested plant.

Discussion

This prototype is very minimalistic, but it still includes the fundamental parts of a blockchain-based tracking system. We could deliver our products with a label in the form of a bar or QR code, which would link to a website where the buyer can get the full history of how the plant came to be.

[track’n’trace image?]

At present, there is no information about what happened to the product from the time it was harvested until the customer has it in their hands, but if you also trace this part, the chain could be extended and the entire process could be documented on the blockchain in IFT. That part of the tracking could be done by a delivery company and/or by the store that sells the product. The various parties would store “their share” of the information separately in the blockchain at the same time as the customer can see the entire resulting sequence of events.

In the future we could also include more information like the environmental ”footprint” of the product and its nutritional value. This would of course require more thorough data gathering and analysis on our end than we are capable of at present, but it is definitely something we are discussing.

This concludes our series Build an aquaponic indoor farm. At least for now!

The text in this posted is licensed under Creative Commons BY-NC-SA International.

Build an aquaponic indoor farm – part 5 – Production management

Part 1 – start and prior knowledge
Part 2 – design
Part 3 – build log
Part 4 – water quality and nutrients testing
Part 5 – production management (this blog)
Part 6 – distributed ledger/block chain integration (coming soon)

Cultivation Management Platform

The digital systems we have built are based around the vision we set out with at the start of the project. We call it the Cultivation Managment Platform.

The CMP consists of four parts:

Water quality and nutrients tests
Water, air and automation sensors
Production management
Distributed ledger / block chain

In this part we will describe our work with the production management system.

Production management system – overview

With digital tracking, or production tracking, we collect data on how the cultivation itself is progressing. The main components of this system are a mobile app and a cloud-based service with which the app communicates. With the mobile app, we record every significant event during a plant’s path through the system, from seed to finished lettuce head! All data is stored in the cloud service and is accessible both from the app and from an administrative interface in the service.

Cultivation process as data

The cultivation process is organized in what we call batches, where one batch is one or more germination occasions of the same seed made at the same time. As a plant goes from seed to harvest, we generate and record four events that we call Seed, Seedling, Plant and Harvest. Each batch in turn consists of one or more ”containers” where the plants grow. At the start of a batch, the seeds are placed in substrates in trays with between 77 and 150 plants. These trays stand on a cultivation table, a shallow basin with a few centimeters of water. The tray is covered with a plastic hood for higher temperature and humidity. The first event, Seed, is recorded when we sow a tray.

Anke moving seedlings from a tray to a raft

The germination period is about a week long, after which the tray is moved to another cultivation table where the seedlings can continue their growth for a few weeks. When this move is made, we register a Seedling event. How long the plants spend as seedlings depends on the type of plant.

When the seedlings have grown to the right size on the tray, it is time to move them out to the large cultivation basins. This is done by moving each individual plant to a raft. The rafts are just under a square meter in size, and hold 30 or 32 plants. The two different types of rafts have different sized holes where the plant is placed and are therefore suitable for different types of plants. For each raft, we register a Plant event. After a number of weeks on the rafts, again for different lengths of time depending on the type of plant, the finished plants are harvested. This is usually done the same day or the day before they are delivered to the customer. For each raft that is harvested, we create a Harvest event.

A raft is being brought out for harvest

For each event, we record the time of the event, who does the registration, and the number of plants that are currently on the tray or raft. For example, some seeds have not germinated properly and we register the loss when we create the Seedling event. In the case of Seed and Plant events, we register the ID of the cultivation tray or raft used. You can also add a free text note. In addition, the following data is stored for the various events:

Seed: seed variety and supplier, ID of cultivation tray, number of seeds and any cultivation accessories used
Seedling: the number of seedlings
Plant: raft ID and the number of plants
Harvest: the number of plants harvested

Implementation

The production management system consists of two main parts; a mobile app and a server with which the app communicates via HTTP and where we store the data registered via the app. The app is built with the Flutter framework. Flutter makes it possible to create apps that use the same source code but can run on both Android and iOS-based phones and tablets. The cloud service is built with the Django framework, a framework for all types of HTTP-based backend solutions. In addition to Django, we also use PostgreSQL as a database and Hasura which provides a GraphQL API to the database.

In the next post we will have a look at our distributed ledger/block chain integration.

The text in this posted is licensed under Creative Commons BY-NC-SA International.

Att bygga en akvaponi – del 5 – Produktionsspårning

Del 1 – att starta, förkunskaper
Del 2 – design
Del 3 – bygglogg
Del 4 – vattenkvalitet och näringstester
Del 5 – produktionsspårning (denna blogpost)
Del 6 – integration med blockkedja (kommande blogpost)

Cultivation Management Platform

De digitala system vi byggt har grundats på den vision vi satte i början på projektet som vi kallar Cultivation Management Platform (CMP).

CMP kan delas upp i fyra delar:

I detta avsnitt beskriver vi arbetet med produktionsspårning.

Systemet i stora drag

Med digital spårning, eller produktionsspårning, samlar vi in data om hur själva odlingen framskrider. Huvuddelarna i detta system är en mobilapp och en molnbaserad service som appen kommunicerar med. Med mobilappen registrerar vi varje betydelsefull händelse under en plantas väg genom systemet, från frö till färdigt salladshuvud! All data lagras i molntjänsten och är tillgänglig både från appen och från ett administrativt gränssnitt i tjänsten.

Odlingsprocessen som data

Odlingsprocessen organiseras i vad vi kallar för omgångar, där en omgång är ett eller flera groddningstillfällen av samma frö gjorda vid samma tidpunkt. Under tiden en planta går från frö till skörd genererar och registrerar vi fyra händelser som vi kallar Groddning, Stickling, Planta och Skörd. Varje omgång består i sin tur av en eller flera “behållare” där plantorna växer. Vid groddningens början sätts fröna i substrat i brickor med mellan 77 och 150 plantor. Dessa brickor står på ett odlingsbord, en grund bassäng med några centimeter vatten. Brickan är täckt med en plasthuv för högre värme och luftfuktighet. Den första händelsen, Groddning, registreras när vi frösätter en bricka.

Anke flyttar sticklingar från en bricka till en flotte

Groddningsperioden är ca en vecka lång varefter brickan flyttas till ett annat odlingsbord där sticklingarna får fortsätta sin tillväxt under några veckor. När denna flytt görs registrerar vi en Stickling-händelse. Hur lång tid plantorna spenderar som stickling beror på typen av planta. När sticklingarna växt till rätt storlek på brickan är det dags att flytta ut dem till de stora odlingsbassängerna. Detta sker genom att varje enskild planta flyttas till en flotte. Flottarna är en knapp kvadratmeter stora, och rymmer 30 eller 32 plantor. De två olika typerna av flottar har olika stora hål där växten placeras och är därför lämpliga för olika typer av plantor. För varje flotte registrerar vi en Planta-händelse. Efter ett antal veckor på flottarna, återigen olika lång tid beroende på typ av växt, skördas de färdiga plantorna. Vanligen görs detta samma dag eller dagen innan de levereras till kund. För varje flotte som skördas skapar vi en Skörd-händelse.

En flotte tas ur bassängen för skörd

För varje händelse registrerar vi data om tidpunkt för händelsen, vem som gör registreringen, och antalet plantor som just då finns på brickan eller flotten. Exempelvis har några frön inte kommit igång och vi registrerar bortfallet när vi skapar sticklingshändelsen. Vid Groddning och Plantering registrerar vi det ID den odlingsbricka eller -flotte som används har. Man kan också göra en anteckning. Därutöver lagras följande för de olika händelserna:

Groddning: frösort, leverantör, ID på odlingsbricka, antal frön och ev. odlingtillbehör som används
Stickling: antal sticklingar
Plantering: ID på flotte och antal plantor
Skörd: antal skördade plantor

Implementation

Produktionsspårningssystemet består i huvudsak av två delar. En mobilapp och en server som appen kommunicerar med via HTTP och som lagrar den data som registreras via appen. Appen är byggd med ramverket Flutter. Flutter gör det möjligt att skapa appar som använder samma källkod men som kan användas på både Android- och iOS-baserade telefoner och surfplattor. Molntjänsten är byggd med ramverket Django, ett ramverk för alla typer av HTTP-baserade backendlösningar. Utöver Django använder vi också PostgreSQL som databas och Hasura som tillhandahåller ett GraphQL-API mot databasen.

I nästa inlägg tittar vi närmare på vår integration med blockkedja.

Texten i detta inlägg är licensierad under Creative Commons BY-NC-SA International.

Build an aquaponic indoor farm – part 4 – water quality and nutrients testing

Part 1 – start and prior knowledge
Part 2 – design
Part 3 – build log
Part 4 – water quality and nutrients testing (this blog)
Part 5 – Production management

Cultivation Management Platform

The digital systems we have built are based around the vision we set out with at the start of the project. We call it the Cultivation Managment Platform.

The CMP consists of four parts:

Water quality and nutrients tests
Water, air and automation sensors
Production management
Distributed ledger / block chain

In this part we will describe our work with Water quality and nutrients tests.

An aquaponic farm is an ecosystem with many ”moving parts” and you need continuous, precise monitoring of it with the help of both manual and automated systems. On top of that it’s important for us to acquire as much knowledge as possible about the ins and outs of how the system actually works, like how long time different plants take from seed to harvest, how much the fish grow and so on. We use our CMP to achieve these goals with the help of modern technology in combination with our knowledge on plant and fish cultivation.

Water quality and nutrients tests

To get an understanding of an aquaponics system and to be sure that ”everything’s all right” we need to make regular tests of the water to be able to discover any problems that might arise and to analyze how the water quality affects the system as a whole.

When the system was started and the bacterial culture for the nitification process was built up, we took measurements every day to get good control and understanding of the growth process. Now, when the system is up and running in a stable manner, we measure most indicators once a week.

We had initially planned to use a system for data collection and analysis that we have worked with before, Avo Flow by Akvo Foundation. Akvo Flow consists of an Android based app for data collection with a web based backend for admin and visualization tools, along with an integration with photo-metric and other water quality sensor systems called Akvo Caddisfly. However we realized that the amount of reagent chemicals needed was larger than what was advisable in our fairly small pilot system.

Thus we chose to use a combination of photometric and other sensors from different suppliers. One of the down sides of this is that these other components have very poor or totally lacking digital integration, so we now have a large spreadsheet instead for all the data we collect this way.

Indicator	Sensor	Comment
Alkalinity	eXact iDip, ITS
Ammonium	eXact iDip, ITS
Phosphate	eXact iDip, ITS; Checker, Hanna Instruments	eXact iDip can only be used up to 3 ppm
Hardness	eXact iDip, ITS
Iron	Checker, Hanna Instruments
Potassium	Photometer Potassium, Hanna Instruments
Dissolved oxygen	Handy Polaris 2, Oxyguard	Portable reference meter
Nitrate	eXact iDip, ITS
Nitrite	eXact iDip, ITS
pH	pH-Checker, Hanna Instruments	Portable reference meter

Water quality and nutrients tests

Digital monitoring – Water, air and automation sensors

The system we developed for collection, storage and presentation of real-time data consists of two main parts. The system that collects the data is called Aquasensor and the system for storage and display of the data is called Aquadata.

An overview of the digital monitoring system, Aquasensor and Aquadata

Critical indicators as well as indicators that are relatively easy to measure are automatically measured every minute by the sensors. These sensors are connected to Aquasensor which is a tailor-made program written in the programming language Python. Aquasensor communicates with the sensors and collects raw data which is converted into measured values and then, via a buffer program, Grafsy, sends this data to the storage part of the system. The following are the most important indicators we measure:

Indicator	Sensor	Comment / unit of measure
Electricity usage	Electricity meter with pulse output	1 pulse/Wh (1000 pulses/kWh)
Light	TSL2561	Lux
Air: temperature	Sensirion SCD30	°C
Air: humidity	Sensirion SCD30	%
Air: CO₂	Sensirion SCD30	ppm
Sensor hub, CPU-usage	The Linux operating system
Sensor hub, mains electricity	230-volts relay	on/off
Sensor hub, network packets	The Linux operating system
Sensor hub, SMS signal strength	3G-modem, Huawei E303	% or dBm
Water: electric conductivity	Sensorex CS150TC	mS/cm
Water flow	XKC-Y25 inductive detector	on/off
Water intake	Water meter with pulse output	53 pulses/liter
Water: dissolved oxygen	Vernier Optical DO	mg/l
Water: level measurement	Ultra sound sensor, JSN-SR04T and a float switch	cm
Water: pH	Sensorex pH2000
Water: temperature	Dallas DS18B20	°C
Drum filter cleaning	230-volts relay	on/off
Weather: humidity	USB-connected electronic weather station	%
Weather: temperature	USB-connected electronic weather station	°C
Weather: air pressure	USB-connected electronic weather station	hPa

Indicators and equipment for automated sensors

The storage and display system, Aquadata, is based on the two open source software systems Graphite och Grafana.

*System architecture of Aquasensor and Aquadata.*

Graphite was originally a tool for monitoring computers. It has a database that is tailored for storing time series and is therefore well suited for other time-oriented data, such as sensor data from our aquaponics.

Grafana is a tool for visualizing data, with enormous flexibility in terms of the ability to combine information into larger dashboards. Several graphs can thus coexist on one screen and each graph can contain several different types of data, combined in a logical way.

Grafana dashboard with data from Johanna’s pilot site

System implementation – Aquasensor

Aquasensor runs on RaspberryPi computers, we call them the ”Pies” or sensor hubs. We currently have two of them that collect data from different parts of the cultivation. Every full minute, data is collected from the sensors. Aquasensor uses a supporting software, Grafsy, to temporarily store the collected information. In turn, Grafsy sends data to the Aquadata storage system. Grafsy ensures that all information is delivered and data from several hours of measurements can be stored if communication with Aquadata is temporarily interrupted. A sensor hub can also have a ”sub-hub” which is an Arduino computer with sensors. Some sensors are easier to communicate with from an Arduino. Since power outages can occur, the Pies have backup power in the form of battery packs. They are of the same type that you can use to charge your mobile phone. In this way, Aquasensor can continue to monitor the cultivation even if the power goes out. If reserve power is available to the router, Aquasensor can continue to send data even during power outages, if the router does not work, the information is buffered in Grafsy until communication is re-established.

Aquasensor connected to an electronic weather station (which uses wireless communication to get data from sensors on the roof).

System implementation – Aquadata

Aquadata is a system built around the open source software Graphite and Grafana. Graphite stores all information from the sensors and Grafana presents data in graphs that can be collected in dashboards. With these two systems as a base, we have built a cloud service that enables storage of sensor data over the Internet and access to the information in the same way.

Data and time series

Data collected by Aquasensor is sent to Aquadata. There it is stored in Graphite, a database that is tailored for storage of so-called time series, i.e. data containing a timestamp. When Aquasensor sends data from a sensor, it is in the form: ”name timestamp data”.

The configuration of the storage is automatic, when a measured value enters Aquadata, it is automatically added to the named series. If the name does not exist, it is created in the database and the information is added there as a first entry.

Example

Aquasensor sends the following data:

johannas.husby1.sensor.luft.co2.stickling 2020-12-14T02:16:00+02:00 348

The name of the measured value, johannas.husby1.sensor.luft.co2.stickling, contains a lot of information that specifies the kind of data we’re sending. The name is is made up of sub-names in a hierarchical structure. The first two parts of the name, johannas.husby1 is the facility we send data from. Then follows what type of data it is, sensor.luft.co2, i.e. carbon dioxide, and finally the name, stickling, of the sensor from which the measured value comes, in this case the sensor in the seedling room. Using this type of hierarchical names you can build logical structures for your data which in turn makes it easy to find the right information when it is to be presented in graphs.

The next part of the data is the timestamp, 2020-12-14T02:16:00+02:00. Most measurements are made every full minute, with the exception of EC (electric conductivity; measured by running a weak current through the water) which is made on the half minute so as not to interfere with the pH that is easily affected by it.

The last part of the measurement is the measured value, i.e. the data itself, 348. The unit is specified when creating the visualizations and is not part of the value, but is in most cases obvious. In the case of carbon dioxide content, it is ppm, parts per million.

Graphs and dashboards

The collected data is presented by Grafana, an open-source software for visualizing data. With Grafana, we have built dashboards, information panels where we collect information that ”fits together”. We currently have three main panels, Water, Cultivation Rooms and Tech infra, technical infrastructure. The water panel shows the values for temperature, oxygen content, pH and electrical conductivity. The Tech infra dashboard shows more ”physical” measurement values such as electricity consumption (and that we have electricity at all!), the system’s water level (to be able to alert if we get a major leak) and monitoring of the drum filter whose activity is indirectly an indication that the system is OK. The Cultivation Room panel shows the measurements we take in the seedling room, such as temperature, humidity and carbon dioxide content.

Grafana dashboards on TV screens at the pilot site

Alterts

Aquasensor and Aquadata have two integrated alerting systems. On is SMS-based and sends an SMS to a list of telephone numbers in the event of an alarm condition. The second system is an integration with the cloud service PagerDuty, which can be configured to send alarms via: email, SMS and phone calls.

Digital security

Our monitoring system is explicitly not to be used to control the aquaponics. We are of the firm opinion that in the future it may be very difficult to protect ourselves from external actors who want to disrupt and/or destroy our computer systems, or to exercise digital blackmail by, for example, breaking into our system, encrypting the computer disks and request money to unlock data again. In systems that operate critical infrastructure, such as our fish farming, this should not be possible and our control systems are air-gapped, i.e. have no digital access from the internet or other external networks. This means that the data flow in our monitoring systems only goes in one direction: from the sensors to the local data server and on to the cloud service.

In the next post we will take a look at the Production managment system.

The text in this posted is licensed under Creative Commons BY-NC-SA International.

Att bygga en akvaponi – del 4 – vattenkvalitet och näringstester

Also available in ENGLISH.

Del 1 – att starta, förkunskaper
Del 2 – design
Del 3 – bygglogg
Del 4 – Vattenkvalitet och näringstester (denna blogpost)
Del 5 – Produktionsspårning

Cultivation Management Platform

De digitala system vi byggt har grundats på den vision vi satte i början på projektet som vi kallar Cultivation Management Platform (CMP).

CMP kan delas upp i fyra delar:

I detta avsnitt beskriver vi arbetet med vattenkvalitets och näringstester samt vatten-, luft- och automationssensorer.

En akvaponi är ett ekosystem med många ”rörliga delar” och därför behöver man ha en noggrann och kontinuerlig övervakning av den med hjälp av både manuella och automatiska system. Därtill är det viktigt att vi lär oss så mycket som möjligt om hur akvaponin fungerar, vilka plantor som fungerar bäst att odla, hur lång tid det tar för olika växter att gå från frö till skörd, hur snabb tillväxt fisken har m.m. Vår CMP hjälper oss att nå dessa mål med hjälp av modern teknik och IT i kombination med vår kännedom om växt- och fiskodling.

Vattenkvalitet och näringstester

För att förstå en akvaponi och vara säker på att ”allt står rätt till” behöver man ta regelbundna prover på vattnet och på så vis både kunna upptäcka problem och analysera hur vattenkvaliteten påverkar systemet.

Under uppstarten av systemet, då bakteriekulturen för nitrifikationsprocessen odlas upp, mätte vi en gång om dagen för god kontroll och för att förstå tillväxtprocessen. När akvaponin nu är i drift och har varit det en längre tid behöver vi generellt inte mäta så ofta utan vi mäter de flesta indikatorerna en gång i veckan.

Från början hade vi tänkt använda ett system för datainsamling och analys av vattenkvalitet vi varit med och arbetat på tidigare: Akvo Flow, från Akvo Foundation. Akvo Flow består av: en app för Androidtelefoner för datainsamling med tillhörande webbaserade administrativa- och visualiseringsverktyg och en koppling till fotometriska- och andra vattensensorer som heter Akvo Caddisfly. Efter överväganden valde vi dock att använda andra verktyg. Anledningen var att det fotometriska sensorsystemet som Akvo Caddisfly är integrerat med, Lovibond 610 från Tintometer, använder större volymer reagenskemikalier än vad som var lämpligt att arbeta med på den plats där vi har i pilotanläggningen.

Vi valde istället att använda en kombination av fotometrar och andra sensorer från andra företag. Till skillnad från Akvo Caddisfly har dessa system dålig eller ingen digital integration, så data registreras manuellt i kalkylark under detta projekt. Följande indikatorer mäter vi manuellt:

Indikator	Sensor	Kommentar
Alkalinitet	eXact iDip, ITS
Ammonium	eXact iDip, ITS
Fosfat	eXact iDip, ITS; Checker, Hanna Instruments	eXact iDip kan bara användas upp till 3 ppm
Hårdhet	eXact iDip, ITS
Järn	Checker, Hanna Instruments
Kalium	Fotometer Potassium, Hanna Instruments
Löst syre	Handy Polaris 2, Oxyguard	Portabel referensmätare
Nitrat	eXact iDip, ITS
Nitrit	eXact iDip, ITS
pH	pH-Checker, Hanna Instruments	Portabel referensmätare

Vattenkvalitets- och näringstester.

Digital bevakning – Vatten-, luft- och automationssensorer

Systemet vi utvecklat för insamling, lagring och presentation av
realtidsdata består av två huvuddelar som vi kallar för Aquasensor och Aquadata för insamling respektive lagring och presentation av data.

En överblick över det digitala bevakningssystemet, Aquasensor och Aquadata

Kritiska indikatorer samt indikatorer som är förhållandevis lätta att mäta automatiskt mäts varje minut med vårt sensorsystem. Dessa sensorer är kopplade till Aquasensor som är ett skräddarsytt program skrivet i programmeringsspråket Python. Aquasensor kommunicerar med sensorerna och inhämtar rådata som omvandlas till mätvärden för att sedan, via ett buffertprogram, Grafsy, skicka denna data till lagringsdelen av systemet. Följande är de viktigaste indikatorerna vi mäter:

Indikator	Sensor	Kommentar/enhet
Elförbrukning	Elmätare med pulsutgång	1 puls/Wh (1000 pulser/kWh)
Ljus	TSL2561	Lux
Luft, temperatur	Sensirion SCD30	°C
Luft, fuktighet	Sensirion SCD30	%
Luft, koldioxid	Sensirion SCD30	ppm
Sensorhubb, CPU-last	Linux-operativsystemet
Sensorhubb, eltillgång	230-volts relä	på/av
Sensorhubb, nätverkspaket	Linux-operativsystemet
Sensorhubb, SMS signalstyrka	3G-modem, Huawei E303	% eller dBm
Vatten, elektrisk konduktivitet	Sensorex CS150TC	mS/cm
Vatten, flöde i systemet	XKC-Y25 induktiv detektor	på/av
Vatten, tillförsel av nytt vatten	Vattenmätare med pulsutgång	53 pulser/liter
Vatten, löst syre	Vernier Optical DO	mg/l
Vatten, nivå	Ultraljudsensor, JSN-SR04T och flottörbrytare i rostfritt	cm
Vatten, pH	Sensorex pH2000
Vatten, temperatur	Dallas DS18B20	°C
Trumfilter, spolning	230-volts relä	på/av
Väder, luftfuktighet	USB-ansluten väderstation	%
Väder, temperatur	USB-ansluten väderstation	°C
Väder, tryck	USB-ansluten väderstation	hPa

Indikatorer och utrustning för automatisk mätning

Lagringsdelen, Aquadata, är i huvudsak en kombination av mjukvarorna Graphite och Grafana.

Graphite är ursprungligen ett verktyg för övervakning av datorer. Det har en databas som är skräddarsydd för lagring av tidsserier och lämpar sig därför väl även för annan tidsorienterad data, såsom sensordata från vår akvaponi.

*Systemarkitektur för Aquasensor och Aquadata.*

Grafana är ett verktyg för att visualisera data, med enorm flexibilitet vad gäller möjligheterna att kombinera information till större enheter, “dashboards”. Flera grafer kan på så sätt samsas på en skärm och varje graf kan innehålla flera olika typer av data, kombinerad på ett logiskt sätt.

Grafana dashboard med data från Johannas pilotanläggning.

Implementation – Aquasensor

Aquasensor körs på RaspberryPi-datorer , vi kallar dom “Pajerna” eller sensorhubbarna. För närvarande har vi två stycken som samlar in data från olika delar av odlingen. Varje hel minut samlas data in från sensorerna. Aquasensor använder ett hjälpsystem, Grafsy, för att temporärt lagra den insamlade informationen. I sin tur sänder Grafsy data till lagringssystemet Aquadata. Grafsy försäkrar sig om att all information kommer fram och data från flera timmars mätningar kan hållas lagrad om kommunikationen med Aquadata blir tillfälligt avbruten. En sensorhubb kan också ha en underhubb som är en Arduino-dator med sensorer. Vissa sensorer är enklare att kommunicera med från en Arduino. Eftersom strömavbrott kan förekomma har Pajerna reservström i form av batteripackar. De är av samma typ som man kan använda för att ladda sin mobiltelefon. På så sätt kan Aquasensor fortsätta att övervaka odlingen även om strömmen går. Om reservkraft finns till routern kan Aquasensor fortsätta att sända data även under strömavbrott, om routern inte fungerar buffras informationen i Grafsy tills kommunikation upprättats igen.

Aquasensor uppkopplat till en väderstation (som pratar trådlöst med givare på taket på anläggningen).

Implementation – Aquadata

Aquadata är ett system byggt kring open source-mjukvarorna Graphite och Grafana. Graphite lagrar all information från sensorerna och Grafana presenterar data i grafer som kan samlas i “dashboards”. Med dessa två system som bas har vi byggt en molntjänst som möjliggör lagring av sensordata över internet och åtkomst av informationen samma väg.

Data och tidsserier

Data som samlas in av Aquasensor skickas till Aquadata. Där lagras den i Graphite, en databas som är skräddarsydd för lagring av s.k. tidsserier, d.v.s. data som innehåller en tidsstämpel. När Aquasensor skickar data från en sensor, är det på formen: “namn tidsstämpel data“.

Konfigureringen av lagringen är automatisk, när ett mätvärde kommer in till Aquadata läggs det automatiskt till den namngivna serien. Om namnet inte finns, skapas det i databasen och informationen läggs där som en första post.

Exempel

Från Aquasensor skickas följande data: johannas.husby1.sensor.luft.co2.stickling 2020-12-14T02:16:00+02:00 348

Namnet på mätvärdet, johannas.husby1.sensor.luft.co2.stickling, innehåller en mängd information som preciserar vilken data det handlar om. Namnet är är uppbyggt av delnamn i en hierarkisk struktur. Till att börja med två delnamn för anläggningen vi skickar data ifrån, johannas.husby1 . Sedan följer vilken typ av data det är, sensor.luft.co2 , dvs. koldioxid, och till sist namnet, stickling , på den sensor som mätvärdet kommer ifrån, i det här fallet sensorn i sticklingrummet. Med denna automatik kan man bygga upp logiska strukturer för sin data. När sedan informationen ska presenteras i grafer är det enkelt att med hjälp av de hierarkiska namnen hitta rätt information.

Nästa data-del är tidsstämpeln, 2020-12-14T02:16:00+02:00. De flesta mätningarna görs varje hel minut, med undantag för EC (konduktivitet; mäts genom att köra en svag ström genom vattnet) som görs på halvminuten för att inte interferera med pH som lätt påverkas av det.

Den sista delen i mätningen är mätvärdet, själva datan, 348. Enheten anges när man skapar visualiseringarna, den är inte en del av värdet, men är i de flesta fall uppenbar. I fallet med koldioxidhalt är det ppm, parts per million.

Grafer och dashboards

Den insamlade datan presenteras av Grafana, en open-source programvara för visualisering av data. Med Grafana har vi byggt “dashboards”, informationspaneler där vi samlar information som “passar ihop”. För närvarande har vi tre huvudsakliga paneler, Vatten, Odlingsrum och “Tech infra”, teknisk infrastruktur. Vatten- panelen visar värdena för temperatur, syrehalt, pH och elektrisk konduktivitet. På Tech infra har vi mera “fysiska” mätvärden såsom elförbrukning (och att vi har el alls!), systemets vattennivå (för att kunna larma om vi får ett större läckage) och övervakning av trumfiltret vars aktivitet indirekt är en indikation på att systemet “mår bra”. Panelen Odlingsrum visar bl.a. luftförhållandena i sticklingrummet, såsom temperatur, luftfuktighet och koldioxidhalt.

Grafana dashboards visualiserat på TV skärmar i pilotanläggningen.

Larm

Aquasensor och Aquadata har två integrerade larmsystem. Ett SMS-baserat larm som skickar ett SMS till en lista av telefonnummer vid ett larmtillstånd. Det andra systemet är en integration med molntjänsten PagerDuty, som kan konfigureras att skicka larm via: epost, SMS och telefonsamtal.

Digital säkerhet

Vårt övervakningssystem är uttryckligen inte till för att styra akvaponin. Vi är av den bestämda åsikten att det i framtiden så kommer det vara mycket svårt att skydda sig från externa aktörer som vill störa och/eller förstöra våra datasystem, eller utöva digital utpressning genom att till exempel bryta sig in i vårt system, kryptera datadiskarna och begära pengar för att låsa upp data igen. I system som driver kritisk infrastruktur, som vår fiskuppfödning, så ska detta inte vara möjligt och våra styrsystem är air-gapped, d.v.s har ingen digital åtkomst från internet eller andra externa nätverk. Det innebär att dataflödet i våra bevakningssystem endast går i en riktning: från sensorerna till den lokala dataservern och vidare till molntjänsten.

I nästa inlägg så tittar vi närmare på nästa del av det digitala systemet: Produktionsspårning.

Texten i detta inlägg är licensierad under Creative Commons BY-NC-SA International.