Group Actions
Engagement
  • Author Author: RWReynolds
  • Date Created: Date Created
  • Views 1560 views
  • Likes 4 likes
  • Comments 5 comments
Related
Recommended

Stacked Container Hydroponics for Vertical Farming : Blog 6 Part 1 - SCADA

RWReynolds

In this blog post, I will present and explain the design and implementation of my vertical farming SCADA system. It will be presented in two parts with this post, Part 1, focused on system control.

 

So, what is SCADA?

SCADA (supervisory control and data acquisition) is a system operating with coded signals over communication channels so as to provide control of remote equipment (using typically one communication channel per remote station). The control system may be combined with a data acquisition system by adding the use of coded signals over communication channels to acquire data about the status of the remote equipment. This data can then be used as control feedback, for HMI display, and for system data logging.


SCADA can be best considered as a type of industrial control system. And based on my understanding of the nature of, and criteria for, this challenge it certainly seems to lend itself to being described as an industrial system requiring precise control. As my understanding of the challenge is to design, implement and present a proof of concept for a scalable vertical farming system.

 

With that understanding, I have attempted to design and implement a modular, easily reproducible and thus scalable, cultivation system. Please see details of the cultivation system in my previous blog posts.

 

I will now present what I believe is a fully scalable SCADA system. This system provides:

  • Localized and centralized control and data monitoring.
  • A centralized cloud-based IoT data logging system.
  • Full functionality for a single or multiple cultivation unit(s).

 

As can be seen in the image below, the proposed system consists of a single centralized SCADA system and a single or multiple localized SCADA system(s). These systems are connected via 802.15.4 sub-gigahertz radio equipped Silicon Labs EZR32WG MCUs. In the localized systems, these MCUs also act as the direct control and data acquisition component, with possible I/O expansion via an EFM32ZG. In the centralized system, the MCU is simply a bridge to the system's HMI, but could be also used for control and data acquisition for centralized HVAC systems, security sys, etc.. .

 

image

 

My proposed control system consists of two parts. These being the localized and centralized systems. These systems consist of the following individual components: NOTE: Currently I have only the EFM32ZG MCU available. I will annotate those areas where the EZR32WG MCU would be utilized.

  • Silicon Labs EFM32ZG low energy MCU- This MCU is currently being used to develop the control firmware.
  • EZR32WG(pair) low energy MCU(s). - One MCU will be located at the local cultivation unit site while the other will be located at the centralized control/monitoring/logging site. All cultivation site direct control firmware code is currently being developed using the EFM32ZG MCU. This code will, hopefully, be easily ported to the EZR32WG MCUs when they are made available. My concern at this point is implementing the radio link code. I am however developing a messaging protocol that will be usable regardless of the communications method. I am also curious as to how extensive the TCP/IP libraries, if available, will be for the EZR32WG. In the event that these MCUs are not ultimately available then I will use a Raspberry Pi SBC at both the local and central sites and use standard WiFi for communications.
  • Raspberry Pi model B+ single board computer. - Currently, the RPi is connected directly to the EFM32WG via UART pins on both. In the proposed system, however, there would be an RPi only at the centralized location and connectivity would be via Ethernet. The RPi in the proposed system would be used to provide an HMI for manual control and acquired data display. And as a bridge to the cloud-based IoT logging application.
  • Off-the-shelf Timer/Relay device - This is a device originally intended for use as a hot-water heater timer. I have hacked the device so as to provide control and monitoring from an MCU. The device will be used to control the nutrient feed system pump. The hacked output of device currently connects directly to an analog comparator pin on the MCU; as the output of the device is not standard TTL but instead 1.3VDC logic high.The hacked input of the device is connected to a standard GPIO pin on the MCU. This allows complete monitoring and control of the device and thus the nutrient feed pump. All of this to allow automatic and/or manual control and logging of the nutrient feed cycles.
  • Power Supply - At the local cultivation site I am using an Allied Model AL-A300ATX MAX 300W power supply. This will provide power for all local MCUs, lighting, and any required sensor power. This power supply could be used to power multiple cultivation units in close proximity. The nutrient feed pump, along with the timer/relay device, will be powered from a standard AC outlet. At the central site, the RPi will be powered from a 5V@2A "wall wart" type power supply. The central MCU will be powered from a USB port on the RPi.

 

The picture below is a schematic diagram of the current local SCADA system. It is not meant as a proper schematic but more as a wiring reference for creating a finalized wiring harness. As the entire thing is wired together now using mostly breadboard jumper wire and clip leads.

image

 

Theory of Operation - Currently the control system is relatively simple. I am controlling a the following components in the describe fashion:

  • Cultivation unit rotator - A single stepper motor for rotation of the cultivation unit. As discussed in previous blog posts the rotator is used to provide equally distributed lighting to all plants. The implementation of the rotator system has very closely followed the original proposed design. The only modification is having implemented a direct as opposed to a belt driven system. The system consists of a step motor driving a turntable on which the stacked containers are placed. The stepper motor is a 4 phase type driven via an off-the-shelf controller circuit. See the Stepper Motor Controller section of the above schematic/wiring diagram. The stepper motor is currently being controlled by code implemented on the EFM32ZG. I have used 4 GPIO pins from the MCUs expansion header as input to the controller circuit. The code provides control of motor on/off, direction, speed and timed operation. These functions can also be controlled remotely via a simple messaging protocol. The proposed design will provide an RPi based HMI with an EZR32WG based radio link to the cultivation area for remote control. Currently, I have an EFM32ZG connected via UART to an RPi to simulate remote control functionality.
  • Nutrient feed system pump - The nutrient feed solution is delivered to the stacked cultivation unit by a single submersible pump. The pump resides in the nutrient feed solution reservoir, which also acts as the base for the cultivation unit. Currently, this pump is being controlled by code implemented on the EFM32ZG MCU. The MCU is connected to a timer/relay device. The device has been hacked to provide access to the control line of the device. The control input and output lines of the device are connected to the MCU via one standard GPIO pin and one analog comparator pin, respectively. As the device provides its own internal timer, code on the MCU has been implemented to monitor the output of the timer and echo the status of the timer circuit back to the device for controlling the internal relay. This allows the MCU to be aware of when the timer activates and deactivates the internal relay. This is useful for monitoring and logging nutrient feed times. Code has also been implemented that allows the MCU to bypass the device timer directly control the device's internal relay. Again, the device can be controlled remotely via the implemented messaging protocol. All of this to allow the greatest level of control over the nutrient feed system.
  • Lighting - Currently the plan is to keep the supplemental LED lighting on at all times. As I don't believe lettuce requires fruiting or blooming periods in the cultivation cycle I see no reason to control the lighting. However, I can see the possible benefit of having the ability to remotely control the lighting in some situations. So I may at some point  implement a simple driver/relay circuit to control the LED light bar. This would be interfaced to the MCU via a standard GPIO pin and code similar to the nutrient feed pump control code would be implemented for control of the lighting driver/relay circuit.

This covers the operation of all currently controlled devices in the system. I am considering adding nutrient feed replenishment control at some point in the future. But the required devices, that I am aware of, for this functionality, are cost prohibitive at this point. This process would require the ability to control up to 5 separate feed pumps of some sort. I am doing ongoing research at this time and may choose to design and build my own system.

 

My next blog post will be SCADA - Part 2 and will cover the Data Acquisition system design and implementation. I have not done much so far concerning sensors. I currently have a BlueGiga BLE dongle on the way so that I can hopefully utilize the SiLabs Sensor-Puck as one of my sensors. And I have lots of work to do on trying out some of the hacked sensors that have been presented by other challengers, mainly .

 

That's all for this blog post. Good luck to all the challengers and happy vertical farming! image

Rick