LATERAL.SYSTEMS AQUAPONICS EDGE PLATFORM

We are utilizing an open-source approach as a base for future Agricultural Technology (AgTech) innovations to enable an on-premise smart edge service for farming applications. The purpose of this research is to accelerate our software prototype design by advancing critical enabling features of our conceptual platform to the pilot phase. This Phase I feasibility study involves selecting an open-source "stack" (operating system, web server, database and program language) and designing a study to identify specific processes and functions that must be monitored to drive the development of the rules engine and eventually enabling predictive analytics functions. The research question is: What is the feasibility of extending an open-source software approach for productization of our "on-premise" edge solution that does not require internet services to bridge the digital divide for rural and urban farmers?Goal 1: Determine the feasibility of EdgeX as an effective approach for our product.Objective 1a: Leverage a standardized open interface to enable multiples device types to "bolt in to" the platform to achieve sensor fusion. Raw sensor data are essentially useless until organized for analysis. As is the case with humans that combine data points from multiple senses to determine if a substance is edible or rotten, data fusion involves sensor data integration followed by reduction into compiled datasets that can be classified and used as actionable data. The application program interface (API) for each sensor is different and different types of sensors are wired in various ways such as GPIO and I2C configurations. Thus, we will form a hybrid baseline sense of sensors to test with the goal of achieving data flow and data fusion.Objective 2a: Define the control logic in preparation to demonstrate controller functions.Objective 3a: Demonstrate the data flow of sensor data into the core services of the stack in preparation for applying control logic. To do this, we will program the device services for the stack. This involves programming the device profiles for a suite of baseline sensors and creating the device registry. The devices are sensor processing units (i.e., pH, dissolved oxygen, temperature); a device profile describes the set of attributes (services and/or features) and the value properties associated with a particular of sensor (i.e., the type of data the sensor collects like pH, temperature, etc.). A device registry is a container of devices with shared properties used to manage, monitor, and maintain registered device types. Each device managed by a device service has an association with a device profile, which defines that device type in terms of the operations it supports (i.e., in this case, the measurement it performs).Objective 4a: Determine if EdgeX will suit our needs.Goal 2: Lay the foundation for our Private Cloud design.Our second goal is to lay the foundation for moving our pilot design to commercialization by designing the architecture of the Private Cloud relational database. Data must be archived in a relational database to facilitate pulling useful data. In phase I, we will design this architecture and a decision tree to program the rules engine. This involves establishing a plan for which parameters will be included in the baseline sensor array model and creating tables that depict the range of tolerances for plants and fish typically grown in aquaponics farms. This table is necessary to create a decision-making tree (If/Then/ Else) for our control logic, a necessary first step for programming the rules engine that applies rules to make predictions, diagnose problems, and trigger actions.For instance, nutrient management is necessary to counteract imbalances and provide an optimum nutrient solution needed to maximize yield and prevent physiological plant disorders (Suhl et al., 2016). If any of the nutrient measurements approach the bottom or the top of the tolerance range for a specific crop, then the rules engine will interpret these readings to trigger the dashboard alert or alarm to warn the farmer that some action is needed before the crop ir fusg are stressed. Depending on the nature of the impending imbalance, the rules engine may trigger an injector to add the appropriate buffering regime (Rakocy et al., 2006) such as providing nutrient supplementation (e.g., adding chelated nutrient forms), (Roosta & Hamidpour, 2011). These triggers will occur at the edge (i.e., on-premises) rather than relying on internet connectivity to function. Objective 1b: Design a study to identify specific processes and functions that must be monitored to drive the development of the rules engine database, a foundation of the Private Cloud. We assume situating advanced analytics in the cloud may be more efficient to build more complex data models and enable sharing of data and data models with researchers and between farmers. Sending every data point to the cloud would result in prohibitively expensive cloud service fees, thus, we must strategically define the purpose and objectives of our relational database to reduce data at the edge and send only necessary data to a cloud for advanced analytics.