Computers and Electronics in Agriculture 158 (2019) 122–132

Contents lists available at ScienceDirect

Computers and Electronics in Agriculture

journal homepage: www.elsevier.com/locate/compag

Original papers

Continuous monitoring seed testing equipaments using internet of things T

a,⁎ a a
Rodrigo Santos de Souza , João Ladislau Barbará Lopes , Claudio Fernando Resin Geyer ,
Leonardo da Rosa Silveira Joãob, Anderson Afonso Cardozob, Adenauer Corrêa Yaminb,
Gizele Ingrid Gadottib, Jorge Luis Victoria Barbosac
a
Federal University of Rio Grande do Sul, PO Box 15064, Av. Bento Gonçalves, 9500, 91501-970 Porto Alegre, RS, Brazil
b
Federal University of Pelotas, R. Gomes Carneiro, 1, 96010-610 Pelotas, RS, Brazil
c
University of Vale do Rio dos Sinos, Av. Unisinos, 950, 93022-750 São Leopoldo, RS, Brazil

ARTICLE INFO ABSTRACT

Keywords: The lack of functional, calibrated equipment, along with using inconsistent testing method contribute to the
Seed analysis variable, unreliable results produced by seed laboratories. The objective of this article is present to presente the
Middleware development of an integrated system consisting of hardware, middleware, and application to continuously
Internet of things monitor and record the performance of seed testing equipment from the beginning to the completion of each test
Context awareness
in seed testing laboratories. The central element of the proposed system is the CoIoT middleware
(Context + IoT), which provides mechanisms for managing IoT devices and context awareness mechanisms to
monitor and record the equipment functions, throughout the seed testing processes. The developed system was
tested in the Official Seed Analysis Laboratory (OSTL) of the Brazilian Agricultural Research Corporation
(Embrapa). The proposed system was evaluated using the Technology Acceptance Model (TAM), which con-
siders aspects of ease of use and usefulness. To validate the results, a scale of 1 (user totally disagree) to 5 (user
totally agree) was used. For ease of use the average was of 4.7, and for usefulness, the average was of 4.4. The
results achieved are promising, which encourages the continuity of research to further optimize CoIoT.

1. Introduction perform the tests (Brasil, 2009).

The main purpose of seed testing is to determine the quality of the
seed and its value for planting. A Seed Testing Laboratory (STL) eval-
uated the end product of seed production systems including: planting,
harvesting, processing, treatment, storage. The central function of STL
is to standardize seed testing processes through the rules established by
the seed testing organizations. The results of seed testing are used to
issue reports or certificates stating the quality of seeds tested. These
reports are the bases for marketing, storage, distribution of seeds. Seed
testing is also used in research and the identification of quality pro-
blems (Tillmann and Menezes, 2012).
To perform seed testing accurately and uniformly, laboratories must
have appropriate equipment that is calibrated regularly and follows
uniform procedures. The Rules for Seed Testing (RAT) describe the
uniform procedures that standardize the analyses to 19 obtain con-
sistent, reliable results regardless of the analysts or the laboratories that
To meet the high demand of seed testing, the Official Seed Testing
Laboratory (OSTL) of Brazilian Agricultural Research Company
(Embrapa) has been established since 1960 to plan and supervise, co-
ordinate and control the activities related to the execut agricultural
research and establish agricultural policies.1
The research has developed by a consortium involving the Federal
University of Pelotas, the Federal University of Rio Grande do Sul and
Embrapa. This consortium is intended to develop Ubiquitous
Computing solutions (Ubicomp), which explore solutions that con-
tribute synergistically to agricultural research activities. In Ubicomp,
computational systems use different contextual variables collected from
widely distributed environments (Knappmeyer et al., 2013). Recent
technological advances in the Internet of Things (IoT) have provided
the use of large-scale sensors as sources of contextual information for
ubiquitous applications (Perera et al., 2014).
Many of the challenges related to using the IoT device in obtaining

Corresponding author.
⁎

E-mail addresses: rssouza@inf.ufrgs.br (R. Santos de Souza), jlblopes@inf.com.br (J.L. Barbará Lopes), geyer@inf.com.br (C.F. Resin Geyer),
ldrsjoao@inf.ufpel.edu.br (L. da Rosa Silveira João), adenauer@inf.ufpel.edu.br (A. Corrêa Yamin), gizele.gadotti@ufpel.edu.br (G.I. Gadotti),
jbarbosa@unisinos.br (J.L. Victoria Barbosa).
1
https://www.embrapa.br/.

https://doi.org/10.1016/j.compag.2019.01.024
Received 22 August 2017; Received in revised form 3 September 2018; Accepted 20 January 2019
0168-1699/ © 2019 Elsevier B.V. All rights reserved.
R. Santos de Souza et al.
contextual information associate with the difference between the ubi-
quitous high-level requirements of applications and the typical low-
level operational profile (Perera et al., 2014). Given the operational
demands of OSTL, the objective of this research is to propose an in-
tegrated solution to context aware monitoring of seed testing labora-
tories, consisting of hardware, middleware, and application. The out-
come of the proposed technology is to monitor and record seed testing
equipment and operations in seed testing laboratories using the pro-
posed middleware, called CoIoT (Context + IoT). The CoIoT provides
the middleware support to ubiquitous applications and mechanisms for
managing the IoT devices.
CoIoT is a middleware developed from EXEHDA (Execution
Environment for Highly Distributed Applications) (Lopes et al., 2014)
that aggregates the treatment of sensor and actuator devices and uses
the infrastructure resources of the ubiquitous environment provided by
EXEHDA. CoIoT is event-driven, managed by rules, with distributed
processing of the context. It acts proactively both in the acquisition of
contextual information from the physical environment and in remote
action on the environment. EXEHDA, in turn, provides a software ar-
chitecture that aims to create and manage a ubiquitous environment, as
well as promote the execution of ubiquitous applications under this
environment.
Many authors have been addressing context awareness in the per-
spective of IoT (LogMeIn, 2017; by Altair, 2017; Kostelník et al., 2011;
Pires et al., 2014), but the support offered to IoT application develop-
ment usually is limited. The context awareness mechanisms of these
projects do not provide support to collecting and processing of context
in a distributed way, through rules, as well as for acting in the en-
vironment. The differential of the CoIoT is the distributed processing of
the contextual information in which part of the processing takes place
near the edge of the environment, i.e., near the place where the in-
formation is produced. This approach enables reducing the volume of
data sent over the network, as well as the reliance on communication
infrastructures provided by third parties in handling critical events. In
addition, the context processing in CoIoT occurs through ECA (Event-
Condition-Action) rules that are triggered by environmental incidents.
The strategy based on events adopted in the design of the architecture
occurs both in the collection of the sensed information of the en-
vironment as in its processing. This method allows the processing of
contextual information at the time of its occurrence.
The CoIoT context awareness mechanisms allow the acquisition and
recording of OSTL equipment states throughout the procedures of seed
testing. After a processing step to identify critical situations are gen-
erated notifications to the users and actions are triggered when neces-
sary.
This study is structured as follows: Section 2, details the material
and methods, highlights research challenges, describes CoIoT features.
Section 3, outlines the application developed for seed testing labora-
tories. Section 4, presents the prototipation and evaluation of the pro-
posed technology. Finally, Section 5, concluding remarks.
2. Material and methods
2.1. Challenges in controlling seed testing environments
Seed testing procedures require accurate equipment. In the case of
germination tests, the process is carried out in BOD (Biochemical
Oxygen Demand), a germination chamber that creates a controlled
environment according to the Rules for Seed Testing (Brasil, 2009). The
main parameters that must manage are temperature, humidity, and
light.
All species require that temperature and humidity remain within
specific limits, while some species require temperature and lighting
alternation. Regardless of the testing requirements, temperature var-
iation should not be greater than 2 °C in each 24 h period according to
the Brazilian Seed testing rules. When alternating temperatures are
123
Computers and Electronics in Agriculture 158 (2019) 122–132
designated, the lower temperature should maintain for 16 h and the
higher temperature for 8 h. Light must be illuminated for at least 8 h
every 24-h cycle (Brasil, 2009; ISTA, 2016).
The equipment must maintain a uniform temperature throughout
the chamber, i.e., each shelf must have the same temperature. Requires
temperature monitoring at various points inside the chamber to detect a
change in temperatures to guarantee the quality of the results provided.
With the implementation of the quality system in STL, daily logs of
temperature readings require in chambers or germinators. Many la-
boratories still use paper spreadsheets that fill out manually. Other la-
boratories have data loggers. Although the data collected can be stored
digitally, automated data collection is rarely used, resulting in loss of
data, in some cases, due to delay in its detection, which leads to ger-
minator problems and delays in seed sales. In turn can result in delay in
sowing, reduced yield, profits.
The use of ubiquitous technology enables monitoring germination
equipment 24 h a day, 7 d a week, without human interference. The use
of context processing rules makes it possible to evaluate the data col-
lected, triggering notifications or actions, such as sending e-mail, text
messages, and/or activating lights.
Researchers, research support personnel, students in postgraduate
classes, and training courses often use OSTL facilities for seed testing
activities. Therefore, the generation of notifications must be persona-
lized and directed to the user who is using the equipment.
2.2. CoIoT: a middleware to IoT
CoIoT is a middleware that has different IOT devices, such as sen-
sors and heterogeneous actuators. In the CoIoT technology, the com-
putational environment consists of cells in which the computational
devices distribute as shown in Fig. 1.
The primary components of this environment are:
• EXEHDAbase the central element of the cell responsible for all es-
sential services and reference to the other elements;
• EXEHDAnode that corresponds to the computational devices in-
volved in the execution of the applications;
• mobile EXEHDAnode, a sub-case of the former, which corresponds
to typically mobile devices that can move between cells in the
ubiquitous environment, such as notebooks, tablets or smartphones;
• EXEHDAedge that consists of the edge element of the ubiquitous
environment, responsible for interoperating between the different
middleware modules and the IoT devices; and
• EXEHDAgateway that manages the inherent heterogeneous tech-
nological systems of sensors and actuators.
The proposed context-handling approach for CoIoT has its func-
tionality distributed between two types of servers: Context Server and
Edge Server. The Edge Server is designed to act primarily on managing
interactions with the physical environment, such as reading of tem-
perature, humidity, light or triggering an alarm. In turn, the Context
Server operates in the storage and processing of contextual information,
i.e., in interpretation of sensors data (Lopes et al., 2014).
The proposed architecture for CoIoT, presented in Fig. 2, allows
managing the collection and processing of contextual information as
well as the performance of the computational environment.
Context processing in CoIoT occurs in a distributed way between
Edge and Context Servers. The Rule Engine module is the first level of
processing, while the Context Processor (Context Server) is the second
level. The rules submitted to the Rule Engine must be elaborated to
attend, as a priority, the critical events. The treatment of the critical
events must be carried out in the shortest possible time and with
minimum failures. Because the Edge Server is generally allocated
physically close to the monitored environment, allowing an action
(alerts, activation/deactivation of electromechanical equipment, etc.)
regardless of any loss of communication with the Context Server caused
R. Santos de Souza et al.
Fig. 1. Cellular Organization of the Ubiquitous Environment.
by a network failure.
On the other hand, rules that need to include the handling of his-
torical information, access data collected from other Edge Servers, or
that involve other context processing models, must be processed in the
Context Server. Both of the context processing modules were designed
based on the ECA (Event-Condition-Action) type model of rules
(Terfloth, 2009), which are triggered by environmental events. In the
Internet of Things, environmental events occur when there is an im-
portant change in some context of interest, for example, a temperature
reaching a particular value or the identification of a user’s input in a
room, etc. The management system must intercept these events and,
through the applications, notify the operators, so that they can fix the
problem (Perera et al., 2014).
CoIoT provides support for both simple events and compound
events. A simple event refers to an instantaneous, atomic occurrence of
an event of interest at a given instant of time. Meanwhile, a compound
event consists of the combination of simple events occurring in a par-
ticular time interval (Terfloth, 2009).
The event handling model proposed for CoIoT considers a set of
simple events generated from the architecture because of: (i) changes of
state of the contexts of interest collected through sensors; (ii) temporal
occurrence; (iii) activation/deactivation of actuators; and (iv) changes
in the infrastructure of the computational environment. CoIoT provides
the support for compound events through the processing of rules, where
a treated condition for an event may have a “true” or “false” outcome
allowing the combination of these events to perform more complex
processing.
The structure of the rules designed for CoIoT have the following
elements:
• Rule Name: it identifies the rule and compound event produced
when processing the rule;
• Group: group to which the rule belongs;
• Event: event that triggers the rule, which can be simple or com-
pound;
• Condition: logical operation to be treated; and
• Action: action executed every time the condition is true.
Rules in CoIoT can organize into groups which may be active or
inactive for processing. A control group can be enabled or disabled from
124
Computers and Electronics in Agriculture 158 (2019) 122–132
an action triggered by a rule. This strategy was adopted to simplify the
implementation of time windows allowing rules to active, deactivate or
change these time window specifications dynamically (Cardozo et al.,
2016).
Although the ECA model is the core mechanism of contextual
treatment used, both the condition treated and the action to be per-
formed by the rule admit other processing models that can be invoked
by the rule, which is due to the type of domain application to be served
by CoIoT.
The Context Repository module uses a relational model for the
representation of contextual information, which provides a historical
record of this data. The structure of the Context Repository reflects the
architectural organization of the EXEHDA Middleware, thus con-
templating the relationship between applications, components, sensors,
environments and contexts of interest. Also, the repository module
stores the architecture configuration data and publications of existing
sensors in the ubiquitous environment. These data used by the Context
processor module to trigger the appropriate actions depending on the
contextual information.
Given the inherently distributed characteristic of ubiquitous appli-
cations, Interoperation Modules of CoIoT have been designed to
promote interoperability between the Edge Servers and Context Server,
as well as with other middleware services. The design of this module
based on the REST architectural style (Fielding, 2000).
The Notifier Module has the function of generating notifications
from the context processing results carried out by the Context
Processor. This module uses a reporting strategy based on the model
publisher/subscriber, which receives subscriptions for all services or
applications that require notifications regarding changes in the states of
context (Tanenbaum and Steen, 2007).
All the settings necessary for the operation of CoIoT managed
through a web interface provided by the Configurator Module. Some
of the features offered are: the configuration of sensors and actuators
(adding, removing and changing), the management of device drivers,
management of contextual processing rules, the configuration of access
to Context Server and Edge Server, Gateways management, among
others.
The Publisher Module has the function of firing the requests of
sending contextual information to the other layers of the middleware,
interoperating with Context Server via Interoperation Module. The
R. Santos de Souza et al.
Fig. 2. CoIot architecture.
publications organized in a FIFO (first in, first out) system and are
processed according to network availability. Considering the possible
miscommunications between the Edge Server and the Context Server as
well as any network delays, it has been designed a Local Persistence
Module for Edge Servers whose function is to perform temporary sto-
rage queue of contextual information until these propagated to the
context server.
With the purpose of ensuring interoperability with market tech-
nologies, and also enhance the distribution of gathering initiatives and/
or acting, two types of gateways were used: (i) Proprietary Gateway,
which has heterogeneous features varying according to its manu-
facturers; and (ii) Native Gateway, whose features are integrated into
the CoIoT architecture. The Virtual Gateway module acts as virtua-
lization of the Native Gateways and implements two basic types of
modules: Drivers and Triggers. Drivers are architectural modules re-
sponsible for the access to the real values captured by the sensors, as
well as the execution of commands sent to the actuators. Drivers en-
capsulate and control the sensors and actuators in an individualized
manner, preventing operational differences of these devices to propa-
gate to other components of the architecture. The sensor reading based
on events being managed by the architecture through the Trigger and
125
Computers and Electronics in Agriculture 158 (2019) 122–132
Scheduler modules. These modules are designed to handle the two main
types of acquisition events to be dealt with in IoT: time events and
environmental events (Perera et al., 2014). The Trigger Module
manages environment events. This module has been incorporated into
the gateways so that state changes of the contextual variables can be
monitored locally, thus reducing data traffic on the network. The
Scheduler Module manages temporal events. This module is located
on the Edge Server to deal with the temporal control in the architecture
at the time of the reading events, thus improving the CoIoT response
activity. Because the Edge Server runs in EXEHDAedge, the hardware
requirements of the device selected for this purpose ensure greater re-
liability in controlling over time events than the EXEHDAgateway.
The Communication Module and Resource Manager have been de-
signed to manage aspects associated with communication between the
gateways and the Edge Server. The Communication Module controls
the communications via REST API as the Resources Manager provides
a discovery engine that handles the connection and disconnection of
devices on the network, regular occurrences of IoT.
The Collector Module has the function of directing the gathering
requests to the respective gateways in agreement with instructions from
the Rules Engine, Context Server, or applications. Supervisor module
R. Santos de Souza et al. Computers and Electronics in Agriculture 158 (2019) 122–132

Fig. 3. Temporal Windows - DT: Daytime temperature; NT: Nighttime Temperature; DTW: Daytime transition window; WD: daytime temporal window; NTW:
nighttime transition window; NW: Nighttime temporal window.

Table 1
Context processing rules of Edge Server to seed testing.
Rule name Group Event Condition Action

Published the temperature Default 30 min interval Condition is always true Publishes the temperature
Night temperature out of range NW Temperatute is readed Temperature < NT − 2 OU Send alert to usuer
Temperature > NT + 2 Action the BOD light
Action the center light
Change NW window NW Light is readed Light = = on Active the DTW group
Desactive the NW group
Publish the light
DTW window time exceeded DTW Temperature is readed Time of DTW window>30 Publish alert of user
Action the BOD ligth
Action the center ligth
Change N window DTW Temperature is readed Temperature > DT Activate WD group
Desativate DTW group
Day temperature out of range WD Temperature is readed Temperature < DT − 2 OU Send alert to user
Temperature > DT + 2 Action BOD light
Action central light
Change NW window WD Light is readed Light = = off Activate NTW group
Desactivate WD group
Publish light state
NTW window time exceeded NTW Temperature is readed Time NTW window > 30 Send alert to user
Action BOD light
Action center light
Change NTW window NTW Temperature is readed Temperature > NT Activate WD group
Desactive DTW group

brings together the actuation commands, receiving the control para-
meters and resolving any conflicts between the requests from different
sources. The Actuator module has a similar function to the Collector
Module, receiving the actuation commands and the operating para-
meters (length, activation energy, etc.) and forwarding to the appro-
priate gateways for further processing.
3. SALApp: an application for Seed Analysis Laboratories
Considering the high sharing of the OSTL infrastructure among the
users and the operational needs of it, the Context awareness approach
designed for the laboratory contemplates contextual information of two
natures: (i) context of the environment and, (ii) context of the Users.
The context of the environment includes all the physical information
sensed by the internal environment of the laboratory and its equipment,
such as temperature and humidity. The user context, in turn, consists of
the specifications made by the user which stored in his profile, such as
address, telephone number and e-mail.
The OSTL operating scenario discussed in this paper presented in
Fig. 3 and involves monitoring the temperature and internal lighting of
each laboratory’s BODs, generate notifications and a historical log. The
temperature is collected and compared to the day and night standards
specified in the testing rules for the seed evaluated. Notifications gen-
erated to the users according to specified preferences (i.e., whenever
the temperature varies by more than 2 °C). Notifications also generated
when the transition time between day and night temperatures exceeds
the 30-min limit and when the light not activated in the period corre-
sponding to the day or deactivated before the expected 16 h have
elapsed.
The middleware support for the scenario considers the scheduling
settings of sensor readings at regular intervals and a set of context
processing rules. Users can adjust both according to operational needs
through the SALApp application interface.
The context processing rules used were organized between the Edge
and Context Servers to meet the proposed scenario. The criteria em-
ployed in the distribution of the rules were: (i) minimization of data
flow and (ii) continuity of monitoring even at times of loss of com-
munication between servers.
In the Edge Server, the rules used in the scenario organized into
groups, which control each of the time windows present in the scenario

126
R. Santos de Souza et al.
Table 2
Context processing rules of Context Server to seed testing.
Rule name Group Event
Persist the temperature Default Temperature is published
Persist the light Default Light is publish
Alert the user Default User alert is published
(Fig. 3). These groups activated through rules triggered by events
produced by the environment. At each time window change, a rule
group activated while the other groups are disabled. The daytime
transition window (DTW) and the nighttime transition window (NTW)
activated when the light is turned on and off, respectively. Whereas, the
day temporal (WD) and night temporal (NW) windows indicate when
the set temperatures reached. The rules used in the scenario are pre-
sented in Tables 1 and 2.
Given the premise that information must be accessible regardless of
the computational device used, the technologies employed in IoT ap-
plications must have resources that allow self-adaptation when changes
occur in the execution environment. In the development of SALApp
responsive technologies were used in its layout. The layout is said to be
responsive when it adapts to the size of the device without impairing its
functionality. Therefore, the application can be accessed in the same
way, as much by desktops and notebooks as by tablets and/or smart-
phones. SALApp is also responsible for creating an intuitive interface so
that the user can manage the resources available in an easy way.
The application developer has two main modules that contemplate
the modes of operation, the Management Module, and the Visualization
Module.
The Management Module allows the management of the various
laboratory. These resources can be of administrative, such as the profile
of the users and the scheduling of the equipment for users, or these
resources can be of the context treatment, such as data collection
(sensing), its processing and actuation on the environment. This module
developed with the principle of support at different levels of access
according to the user’s profile.
The Visualization Module provides several visualization tools that
allow access to the history of contextual information in different ways.
SALApp is a valuable tool in evaluating the behavior of the physical
variables involved in the testing processes.
3.1. Management module
The Management Module of the SALApp application enables the
management of the OSTL infrastructure regarding the middleware
support provided by CoIoT which involves acquisition, actuation,
context processing, and notification. SALApp also contemplates the
management of aspects of the evaluated scenario, which are char-
acteristics of the operational profile of the laboratory.
Access to the Management Module is through login, each user being
Fig. 4. Acesso Interface to features offered through SALApp.
127
Computers and Electronics in Agriculture 158 (2019) 122–132
Condition Action
Condition is always true Persist the temperature in Context Repository
Condition is always true Persiste the light in Context Repository
Condition is always true Send alert to user
able to have a different access level to the menus according to the
permission granted. These menus allow access to the various func-
tionalities offered by SALApp and presented in Fig. 4.
The functionalities offered by the Management Module include the
manipulation of context processing rules, scheduling, and sensor
reading triggers, as well as the configuration of access to the acquisition
and actuation devices, such as Edge Servers, Gateways, sensors, and
actuators. These functions are made available through application in-
terfaces, some of which presented in Figs. 5 and 6.
The management of the acquisition and/or actuation devices,
adding or removing a device, can be performed either automatically, in
the case of devices that support the UPnP (Universal Plug and Play)
protocol, or manually. The automatic registration is only allowed once
approved by an authorized user, avoiding the registration of un-
recognized devices.
The SALApp application includes in its Management Module func-
tions, such as user registration, manufacturers, OSTL equipment man-
agement, and the scheduling of equipment to users to enable shared
use. The scheduling management interface has control buttons common
to the other interfaces, and an exclusive button. This button has the
function of graphically displaying the history of the contextual in-
formation of the equipment during the scheduling period, which
usually corresponds to the time window of an experiment (see Fig. 7).
The user, once registered, assumes a standard profile that can
change later. A key aspect of user profile settings is setting notification
preferences. This configuration reflects the behavior of the CoIoT con-
text processing rules depending on personal preferences.
3.2. Visualization module
The Visualization Module of the SALApp application allows the
selection of the context of interest to be displayed, which can be pre-
sented in the form of a textual report (Fig. 8) or through a graphic style
(Fig. 9). Through this module, the OSTL researcher can visually check
the physical quantities that monitored in the BOD during the periods of
the test, which directly influence the results of seed germination.
The developed graphical report allows visualizing the values of
different tests in OSTL. The selection of the sensors to be displayed
made from a menu with multiple selection support. Also, an inspection
feature is available that allows the comparison of the values at a certain
point in time. The user can define the time window of the data viewed
through the graphical interface that displays the sensed values.
R. Santos de Souza et al. Computers and Electronics in Agriculture 158 (2019) 122–132

Fig. 5. Configuration Interface of Edge Server.

Fig. 6. Configuration Interface of Sensors.

4. Prototipation and evaluation
This section presents the prototyping of CoIoT middleware, high-
lighting the technology and hardware employed, and the evaluation of
this solution through the Technology Acceptance Model.
4.1. Prototipation
In developing the prototyping of the CoIoT architecture, several
technological tools were used, based on the Python language. The use of
Phyton has been particularly helpful in the prototyping stage by sim-
plifying code adjustments during the early phases of architecture im-
plementation and its startup in OSTL.
The Interoperation and Communication Modules were implemented
using Django.2 Django is an MVC (Model-view-controller) framework
implemented in the Python language aimed at building Web applica-
tions which simplify the development of REST APIs. Using Django, re-
sources have been implemented, accessible through URIs, for the ma-
nipulation of several elements that make up the CoIoT architecture,
such as gateways, sensors, actuators, rules, among others. Also, all
operations performed on the Context Repository done through the REST
API. Access to resources made available by the API is accessible via a
user and password authentication. The data transmitted to and by the
REST API is standardized in a JSON format. The specification of the
main features implemented as well as the access URIs are presented in
Tables 3 and 4. Fig. 10 presents the example of a GET request made in
curl for collecting sensor identified as “ TemperatureBOD1 ” and its
structured response in JSON.
The Context Processor modules from both the Edge Server and the
Context Server were implemented from the Business Rules tool.3

2 3
https://www.djangoproject.com. https://github.com/venmo/business-rules.

128
R. Santos de Souza et al. Computers and Electronics in Agriculture 158 (2019) 122–132

Fig. 7. Scheduling Management Interface.

Fig. 8. Visualizations interface of textual report.

Business-Rules is an ECA rule engine, developed in Python, whose rules
structured in a JSON format. The use of JSON is pertinent in this case
because it simplifies the construction and distribution of the rules
through the distributed components of the CoIoT architecture since this
is the standard format adopted in structuring the data sent through the
REST API. The Context Repository, managed by the Context Server, was
implemented in a relational database and using the PostgreSQL man-
ager.
The Scheduler module implemented through the APScheduler
(Advanced Python Scheduler)4 to control the reading of the sensors
through time events. APScheduler consists of a tool implemented in the
4
https://apscheduler.readthedocs.io/.
Python language aimed at building applications that need to schedule
the execution of tasks. Scheduled tasks can be run only once or peri-
odically and can be added or removed dynamically.
According to the rules established for OSTL operation, the sensed
data are processed in a distributed manner and published periodically
in the Context Server for storage for later use. The processing performed
by the CoIoT architecture takes place independently of the applications
and remains operational even when these applications are not running.
Fig. 11 shows the distribution of the CoIoT architecture among the
devices used in OSTL, with emphasis on Edge and Context Servers,
gateways, actuators, and the different type of sensors.
The hardware used for hosting the Context Server was a desktop
with Intel Pentium E2160-1.8 GHz dual-core processor, with 3 Gb of
RAM and with the Ubuntu Server Operating System. For the Edge

129
R. Santos de Souza et al. Computers and Electronics in Agriculture 158 (2019) 122–132

Fig. 9. Visualizations interface of Graphical report.

Table 3 disseminated software platform. The criterion of using a disseminated

Resources of the API REST for managing sensors and actuators.
URI
/sensor or/actuator
/sensor or/actuator
/sensor/id or/actuator/id
/sensor/id or/actuator/id
/sensor/id or/actuator/id
/sensor/read/{id} or
/actuator/read/{id}
/actuator/write/{id}
Table 4
Resources of the API REST for managing the publication queue.
URI Action
software platform was to be able to support the greatest possible
Action Description number of sensing and actuation technologies.
After reviewing the literature, the NodeMCU6 microcomputer was
GET Returns a set of sensors or actuators with chosen. NodeMCU is an open source platform for IoT device develop-
all their information
ment based on the ESP82667 processor (Fig. 12(B)).
POST Registers a new sensor or actuator
GET Returns a sensor or actuator with all their
The sensors selected for the prototype OSTL based on 1-Wire tech-
information nologye8 which characterized as a data transmission network. It is
PUT Alters sensor or actuator configuration based on addressable electronic devices and stands out for its versatility
DELETE Removes a sensor or actuator and ease of implementation. The temperature sensors used can be seen
GET Returns a sensor or actuator value
in Fig. 12(D). This sensor is wrapped in an aluminum casing to give
PUT Sends an actuation request greater mechanical strength and to insulate from moisture. To exploit
the reactive feature of the architecture, actuators (light alert) were also
used based on 1-Wire technology. These actuators are triggered when
the attention of laboratory workers needed with some equipment.
4.2. Evaluation
Description

/publication GET Returns queue of unprocessed publications

/publication POST Registers a new publication containing one or
more sensors
/publication/ DELETE Clears the publication queue
/publication/{id} DELETE Removes a publication
Server, the Raspberry PI model B5 (Fig. 12(C)) with Raspbian Operating
System used. Raspberry Pi is a computer developed by the University of
Cambridge Computing Laboratory that is small, reasonably priced,
energy efficient, user-friendly, and hevea very active user community
that based on the principles of free software. All of these aspects were
instrumental in selecting Raspberry Pi as the Edge Server. Also, Rasp-
berry Pi provides enough processing power allowing the handling of
complex rules, management, and communication with different proto-
cols and sensing devices.
Gateways, represent IoT devices with reduced computing power
when compared to Edge Server, which introduces challenges when it
designed. The following aspects considered when selecting the Native
Gateway hardware (Fig. 12(A)): (i) low power consumption, (ii) the
possibility of wireless operation (Wi-Fi) and (iii) the use of a
5 8
http://www.raspberrypi.org.
This section presents an evaluation of the technology developed and
the results obtained from the study that conducted.
The evaluation involved OSTL volunteer users. Four types of re-
search, five students, and one technician participated in the study. Each
participant used a mobile device and a desktop. We performed basic
training on the application operation beforehand. Participants were
asked to respond to a questionnaire to evaluate their experience of
using the system.
The answers ranged from 1 point (totally disagree, negative ex-
perience) to 5 points (totally agree, positive experience). To evaluate
the model acceptability, checking the system usability, the questions
were defined based on the Technology Acceptance Model (TAM) (Yoon
and Kim, 2007). The TAM model considers the following main themes
for application acceptance: (i) Ease of use (user-friendly), and (ii)
Usefulness: Does the new technology improve accuracy and precision of
seed testing?.
Tables 5 and 6 contain the questions or statements included in the
questionnaire, the responses of the participants, and the average score.
The questions/statements were simple, short and direct to the point.
Both tables present the questions/statements in the first column and
6
http://nodemcu.com/.
7
https://espressif.com/.
http://www.maximintegrated.com.

130
R. Santos de Souza et al. Computers and Electronics in Agriculture 158 (2019) 122–132

Fig. 10. Example of using the REST API in requesting the value of a sensor.

Fig. 11. OSTL hardware allocation.

Fig. 12. Devices: (A) Native Gateway; (B) NodeMCU; (C) Raspberry PI; (D) Temperature Sensor DS18B20.

131
R. Santos de Souza et al. Computers and Electronics in Agriculture 158 (2019) 122–132

Table 5
Ease of use evaluation.
Question Totally disagree Partially disagree Neutral Partially agree Totally agree Average

1. The user interface is easy to understand. 0.0%(0) 0.0%(0) 0.0%(0) 40.0%(4) 60.0%(6) 4.6
2. The user interface is easy to use. 0.0%(0) 0.0%(0) 0.0%(0) 30.0%(3) 70.0%(7) 4.7
3. The option are clear and objectives 0.0%(0) 0.0%(0) 10.0%(1) 20.0%(2) 70.0%(7) 4.6
4. With little effort I can select a context of interest. 0.0%(0) 0.0%(0) 0.0%(0) 20.0%(2) 80.0%(8) 4.8
5. The user interface is properly adapted to the devices. 0.0%(0) 0.0%(0) 0.0%(0) 30.0%(3) 70.0%(7) 4.7

Table 6
Usefulness evaluation.
Question Totally disagree Partially disagree Neutral Partially agree Totally agree Average

1. The options presented are relevant. 0.0%(0) 0.0%(0) 0.0%(0) 30.0%(3) 70.0%(7) 4.7
2. The solution makes it easy to obtain contextual data from multiple sensors. 0.0%(0) 0.0%(0) 0.0%(0) 40.0%(4) 60.0%(6) 4.6
3. The solution facilitates immediate action from the issuance of an alert or message. 0.0%(0) 0.0%(0) 30.0%(3) 30.0%(3) 40.0%(4) 4.1
4. I would use this solution in my work? 0.0%(0) 0.0%(0) 30.0%(3) 20.0%(2) 50.0%(5) 4.2

the answers in columns 2–6. The last column shows the average score of
all participants.
The answers of the participants showed that the approval rate was
generally high for both the ease of use and the usefulness of the system.
However, there was some “indifferent” response in the usefulness ca-
tegory. Interpreted as a concern for the quality control of experiments
developed in OSTL, which depends on the use of autonomic mechan-
isms, without human intervention for issuing alerts and quick response.
In this case, a strategy that can be adopted automation technologies in
seed testing and intensify the validation and improvement of new sys-
tems.
5. Conclusion
This article presents integrated hardware and software automated
system designed to use in continuous monitoring and recording op-
erations in seed testing laboratories. The CoIoT is an architecture de-
veloped for the context awareness treatment of the devices in the
Internet of Things. The CoIoT offers middleware support to the SALApp
application developed for seed testing laboratories.
CoIoT extends the EXEHDA Middleware with the potential to be
used in context-aware applications of various natures in the perspective
of IoT. The proposed CoIoT architecture is event-driven, rule-based, and
manages the acquisition and processing of contextual information as
well as performance in the distributed physical environment.
To evaluate the developed system used the model TAM that eval-
uates the experiences of users regarding ease of use and usefulness. For
ease of use the average was of 4.7, and for usefulness the average was of
4.4. The analysis of these results showed that the users approved the
system in the evaluated aspects.
Future research should include: (i) monitoring other laboratory
equipment and incorporate other types of sensors and actuators; and (ii)
expand the use of CoIoT and SALApp in Embrapa covering other re-
search environments.
Appendix A. Supplementary material
Supplementary data associated with this article can be found, in the
online version, at https://doi.org/10.1016/j.compag.2019.01.024.
References
by Altair, C., 2017. Carriots. < https://www.carriots.com/ > . (Retrieved May, 2017).
Brasil, 2009. Regras para análise de sementes. Ministério da Agricultura, Pecuária e
Abastecimento. Secretaria de Defesa Agropecuária, Brasília.
Cardozo, A., Yamin, A., Souza, R., Davet, P., Lopes, J., Geyer, C., 2016. Sensing and
actuation in iot: an autonomous rule based approach. In: 13th IEEE International
Conference on Mobile Ad Hoc and Sensor Systems (MASS). IEEE, pp. 355–360.
Fielding, R.T., 2000. Architectural Styles and the Design of Network-based Software
Architectures. Ph.D. thesis. University of California, Irvine.
ISTA, 2016. Seed Testing International. < http://www.seedtest.org/en/seed-testing-
international-_content-1-1085.html > . (Retrieved March, 2016).
Knappmeyer, M., Kiani, S.L., Reetz, E.S., Baker, N., Tonjes, R., 2013. Survey of Context
Provisioning Middleware. IEEE Commun. Surveys Ttorials 15, 1492–1519. https://
doi.org/10.1109/SURV.2013.010413.00207.
Kostelník, P., Sarnovský, M., Furdík, K., 2011. The semantic middleware for networked
embedded systems applied in the internet of things and services domain. Scalable
Comput. 12, 307–315. https://doi.org/10.12694/scpe.v12i3.726.
LogMeIn, I., 2017. Xively. < https://xively.com/ > . (Retrieved February, 2017).
Lopes, J., Souza, R., Geyer, C., Costa, C., Barbosa, J., Pernas, A., Yamin, A., 2014. A
middleware architecture for dynamic adaptation in ubiquitous computing. J. Univ.
Comput. Sci. 20, 1327–1351. https://doi.org/10.3217/jucs-020-09-1327.
Perera, C., Zaslavsky, A., Christen, P., Georgakopoulos, D., 2014. Context aware com-
puting for the internet of things: a survey. IEEE Commun. Surveys Tutorials 16,
414–454. https://doi.org/10.1109/SURV.2013.042313.00197.. arXiv:1305.0982.
Pires, P.F., Cavalcante, E., Barros, T., Delicato, F.C., Batista, T., Costa, B., 2014. A plat-
form for integrating physical devices in the internet of things. In: 2014 12th IEEE
International Conference on Embedded and Ubiquitous Computing, pp. 234–241.
https://doi.org/10.1109/EUC.2014.42.
Tanenbaum, A.S., Steen, M.V., 2007. Distributed Systems: Principles and Paradigms, 2nd
ed. Prentice Hall.
Terfloth, K., 2009. A Rule-Based Programming Model for Wireless Sensor Networks.
Ph.D. thesis. Freie Universität Berlin.
Tillmann, M.A.A., Menezes, N.L., 2012. Análise de Sementes. In: Sementes: Fundamentos
científicos e tecnológicos. Ed. Universitária/UFPel, Pelotas, pp. 138–198 (chapter 3).
Yoon, C., Kim, S., 2007. Convenience and TAM in a ubiquitous computing environment:
the case of wireless LAN. Electron. Commer. Res. Appl. 6, 102–112. https://doi.org/
10.1016/j.elerap.2006.06.009.

132