See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/335601989

Architecture framework of IoT-based food and farm systems: A multiple case

study

Article in Computers and Electronics in Agriculture · October 2019

DOI: 10.1016/j.compag.2019.104939

CITATIONS READS

35 692

5 authors, including:

Teodoro Montanaro Davide Conzon

Università del Salento LINKS Foundation
16 PUBLICATIONS 124 CITATIONS 24 PUBLICATIONS 308 CITATIONS

SEE PROFILE SEE PROFILE

Harald Sundmaeker Bedir Tekinerdogan

Institut für angewandte Systemtechnik Bremen GmbH Wageningen University & Research
47 PUBLICATIONS 2,059 CITATIONS 269 PUBLICATIONS 2,261 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Smart Cities View project

Brain-IoT - model-Based fRamework for dependable sensing and Actuation in INtelligent decentralized IoT systems View project

All content following this page was uploaded by Teodoro Montanaro on 04 September 2019.

The user has requested enhancement of the downloaded file.

 Computers and Electronics in Agriculture 165 (2019) 104939

Contents lists available at ScienceDirect

Computers and Electronics in Agriculture

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

Original papers

Architecture framework of IoT-based food and farm systems: A multiple case T

study
⁎
Cor Verdouwa,b, , Harald Sundmaekerc, Bedir Tekinerdogana, Davide Conzond,
Teodoro Montanarod
a
Information Technology Group, Wageningen University and Research, P.O. Box 35, 6700 AA Wageningen, the Netherlands
b
Mprise Agriware, P.O. Box 598, 3900 AN Veenendaal, the Netherlands
c
ATB – Institut für angewandte Systemtechnik Bremen GmbH, Wiener Straße 1, 28359 Bremen, Germany
d
LINKS Foundation, Via Pier Carlo Boggio, 61, 10138 Torino, Italy

A R T I C LE I N FO A B S T R A C T

Keywords: The Internet of Things (IoT) is expected to be a real game changer in food and farming. However, an important
Internet of Things challenge for large-scale uptake of IoT is to deal with the huge heterogeneity of this domain. This paper develops
Architecture and applies an architecture framework for modelling IoT-based systems in the agriculture and food domain. The
Architectural framework framework comprises a coherent set of architectural viewpoints and a guideline to use these viewpoints to model
System of systems
architectures of individual IoT-based systems. The framework is validated in a multiple case study of the
Smart farming
European IoF2020 project, including different agricultural sub sectors, conventional and organic farming, early
Food supply chains
adopters and early majority farmers, and different supply chain roles. The framework provides a valuable help to
model, in a timely, punctual and coherent way, the architecture of IoT-based systems of this diverse set of use
cases. Moreover, it serves as a common language for aligning system architectures and enabling reuse of ar-
chitectural knowledge among multiple autonomous IoT-based systems in agriculture and food.

1. Introduction ● Better sensing of farming and food processing operations, including

usage of inputs, crop growth, animal behaviour, food spoilage and
Agriculture has a vital role in feeding the world in a healthy way. In resource utilization;
recent decades, the agri-food sector has already realized big achieve- ● Improving quality management and traceability by remotely mon-
ments in meeting critical challenges concerning food security, food itoring the location and conditions of shipments and agricultural
safety, sustainability and health. These improvements mainly have been products;
accomplished with non-digital technologies, such as mechanisation of ● Better understanding of specific production circumstances, such as
field operations, animal and plant breeding and more eco-friendly climate conditions, animal welfare, microbiological quality, pest
farming methods. However, still a radical increase of productivity is pressure, and better knowledge about optimal interventions;
needed to feed the ever-growing world population and to deal with ● More advanced and remote control of operations, enabled by ac-
challenges such as climate change, resource efficiency, animal welfare, tuators and robotics, e.g., precise application of pesticides and fer-
waste reduction, food safety, and healthier consumer lifestyles. tilizers, autonomous harvesting, or adjusting ambient conditions of
The Internet of Things (IoT) is a very promising paradigm to dras- food during transportation;
tically improve productivity and sustainability because it has the po- ● Increasing consumer awareness of sustainability and health issues
tential to achieve new levels of control (Sundmaeker et al., 2010; Porter by personalised nutrition advices, health wearables and home au-
and Heppelmann, 2014; Sarni and Kaji, 2016). IoT comprises smart tomation.
webs of connected and context-sensitive objects that can be identified,
sensed and controlled remotely (Atzori et al., 2010; Kortuem et al., However, the application of IoT in agriculture is challenging,
2010; Porter and Heppelmann, 2014; Verdouw et al., 2016b). As such it especially because of a high uncertainty of business processes
enables (AIOTI, 2015; Jayaraman et al., 2016; Verdouw et al., 2016a; (Sundmaeker et al., 2016; Verdouw et al., 2016a). Agri-food products
Talavera et al., 2017): are living objects and farming is depending on natural conditions, such

⁎
Corresponding author at: Wageningen University and Research, Information Technology Group, Hollandseweg 1, 6706 KN Wageningen, the Netherlands.
E-mail address: [email protected] (C. Verdouw).

https://doi.org/10.1016/j.compag.2019.104939
Received 12 April 2019; Received in revised form 30 July 2019; Accepted 4 August 2019
0168-1699/ © 2019 Published by Elsevier B.V.
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

as climate, weather, and diseases. In addition, there are many different on culture and commerce, including the rise of near-instant commu-
types of production, e.g., arable farming, greenhouse cultivation or li- nication by electronic mail, instant messaging, Voice over Internet
vestock farming. Farms and food processors also have to deal with Protocol (VoIP) telephone calls, two-way interactive video calls, social
many interrelated objects such as: (i) farm inputs, including seeds, feed, networking, and online shopping sites. Moreover, Internet connectivity
fertilizers or pesticides, (ii) farm resources, including farm land, stables, became the norm for many business applications and is today integral
tractors and equipment, (iii) agricultural products including living an- part of many enterprise, industrial and consumer products to provide
imals, processed food and fresh produce; and (iv) logistic objects such access to information. However, the Internet usage still primarily fo-
as crates, containers and trucks. Moreover, IoT-based systems must not cuses on human interaction and monitoring through apps and inter-
only support farmers, but also various stakeholders around the farm, faces. IoT is a next stage of the Internet in which also physical things
including, e.g., contractors, agronomists, veterinarians, certification communicate.
and inspection companies, authorities, consumers and input suppliers. IoT combines two concepts “Internet” and “Thing” and can there-
Moreover, food supply chains are complex networks where many small fore semantically be defined as “a world-wide network of inter-
companies do business with large multinationals. connected objects uniquely addressable, based on standard commu-
This high variety and variability of processes, objects and stake- nication protocols” (Infso and EPoSS, 2008). The concept was first
holders result in a large heterogeneity of IoT applications, which introduced by Massachusetts Institute of Technology (MIT) Auto-ID
hampers a large-scale uptake of IoT in the agri-food domain. IoT-based Center to label the development towards a world where all physical
systems are often fragmented, use different data platforms with limited objects can be traced via the internet by tagging them with RFID
interoperability and in particular more advanced applications are still transponders (Schoenberger, 2002). In the meantime, its meaning is
in an early stage of development (Sundmaeker et al., 2016; Verdouw expanded towards a world-wide web of smart connected objects that
et al., 2017). are context-sensitive and can be identified, sensed and controlled re-
In order to overcome this situation, autonomous IoT systems should motely by using sensors and actuators (Atzori et al., 2010; Kortuem
function as interoperable nodes within a well-aligned software eco- et al., 2010; Porter and Heppelmann, 2014; Verdouw et al., 2017). In
system that maximizes reuse and synergies across multiple IoT systems. the IoT domain every ‘thing’ is uniquely identifiable, equipped with
In such an ecosystem, technology companies can concentrate on the sensors and connected in real-time to the Internet. As a result, Internet
development of components that fit best to their core competencies will be deeply embedded in the daily life of consumers and businesses.
(Manikas and Hansen, 2013; Kruize et al., 2016). Next, users can con- Invisible technology operates behind the scenes, dynamically re-
figure customized software systems from standardized components, sponding to how people want “things” to act. IoT is expected to be the
which are supplied by multiple vendors that interact via common next Internet revolution. To date, the world has deployed about 5 bil-
technological platforms (Verdouw et al., 2014). As such, IoT-based lion “smart” connected things. Predictions indicate that there will be up
systems are no longer isolated, but integrated in a coherent way, to 50 billion connected devices by 2020 and in our lifetime we will
leading to a System-of-Systems (SoSs) (Jamshidi, 2008; Nielsen et al., experience life with a trillion-node network (Castaneda, 2015).
2015; Tekinerdogan, 2017). In a SoSs, individual systems have man- The agri-food is a challenging domain for IoT from a technical and
agerial and operational independence, whereas the overall purpose of a organisational perspective (AIOTI, 2015; Jayaraman et al., 2016;
system is to provide a function or service that cannot be provided by Verdouw et al., 2016a; Talavera et al., 2017; Verdouw et al., 2017).
individual systems independently (Maier, 1998). Speaking the same ‘Things’ are often living and natural objects, such as plants, animals,
architectural language is a key starting point to adapt systems to the square meters of soil and perishable food products. This means that IoT
SoSs’ overall purpose (Fitzgerald et al., 2013; Nielsen et al., 2015). devices (e.g., microprocessors, sensors, antennas) cannot be easily
This paper proposes such a common language for aligning system embedded in products themselves. Furthermore, agricultural produc-
architectures and for enabling reuse of architectural knowledge among tion is depending on natural conditions, such as climate (day length and
multiple autonomous IoT systems in agriculture and food. The objective temperature), soil, pests and diseases and weather. This results in a
is to develop and apply an architecture framework for modelling IoT- large variety and variability of agricultural things. Moreover, IoT de-
based systems in the agri-food domain. More specially, the paper will vices have to operate in harsh environments (open air, cold storage, hot
define a coherent set of architecture viewpoints and a guideline to use cleaning treatments, etc.) and remote areas (fields, stables, etc.). As a
these viewpoints to model the architecture of individual IoT-based consequence, they need to be energy-autonomous and able to deal with
systems. The framework is validated in a multiple case study of the Internet connectivity problems in rural areas. There is also a temporal
European IoF2020 project. The case study includes a diverse and co- IoT challenge, because the growth of food products is a relatively slow,
herent set of 19 IoT-based use cases that each provides a dedicated seasonal process with many uncertainties (e.g., weather conditions) on
solution for a specific domain challenge. the one hand, while at the other hand consumers ask for safe, healthy
The paper is structured as follows. Section 2 first provides some and fresh food, a whole year round and just-in-time delivery, mini-
background information of IoT and software architecture, while Section mizing waste and long best-before dates. A major organisational issue is
3 describes the research methodology. Section 4 introduces the de- the high number of small and medium sized enterprises, especially at
signed framework, including a definition of the architecture viewpoints agricultural production, trade and food industry, resulting in a lack of
addressed and a guideline to apply the framework. Section 5 subse- (financial) resources, technical expertise and management skills to in-
quently summarizes the application of the framework to the use cases vest successfully in IoT solutions. It also impacts user concerns among
by presenting the architectures of three representative systems into other about data ownership, privacy and security.
more detail. Finally, the main findings are summarized and discussed in Consequently, current IoT applications and technologies in the agri-
Section 6. food domain are still fragmentary, lack seamless integration and espe-
cially more advanced solutions are in an experimental stage of devel-
2. Background opment (Sundmaeker et al., 2016; Verdouw et al., 2017). Operational
applications are mainly used by a small group of innovators and still
2.1. IoT for food and farming focus on basic functionalities at a high granularity level. A large-scale
uptake of IoT in agriculture is prevented among others by a lack of
The Internet is a global system of interconnected computer networks interoperability, user concerns among others about data ownership,
that uses the Internet protocol suite (TCP/IP) to link billions of devices privacy and security, and appropriate business models that are also
worldwide. Nowadays, over 46% of the world population uses the suitable for (very) small companies.
Internet (InternetWorldStats, 2015). It has had a revolutionary impact

2
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

2.2. Software architecture and Ebert, 2016). The Internet of Things—Architecture (IoT-A) pro-
vides a detailed view of IoT’s information technology aspects (Carrez
Designing software architecture is a key activity in developing et al., 2013; Gubbi et al., 2013). The International Telecoms Unions
software-intensive systems. In fact, every software-intensive system has (ITU) has developed an IoT Reference Model which provides a high
a software architecture, whether it is complex or simple. A software level capability view of an IoT infrastructure (ITU-T, 2016). The Alli-
architecture describes the components of a system, interactions among ance for IoT Innovation (AIOTI) has defined a High Level IoT Archi-
components, and the interaction of a system as a whole with its en- tecture to achieve IoT semantic interoperability (AIOTI, 2018).
vironment (Tekinerdogan, 2014). A software architecture is an abstract The focus of these IoT reference architectures is on technical aspects
representation that identifies the higher-level structure of a system and of IoT. They include viewpoints to visualize how objects are sensed and
is important for supporting communication among stakeholders, for controlled by IoT technologies, but do not sufficiently cover a complete
guiding design decisions, for supporting the subsequent development information modelling process from requirements definition and busi-
process, and for analysis of an overall system. ness modelling to detailed implementation models. The framework
In this study the authors adopt the recommended practice for ar- presented in this paper will add these viewpoints to address the com-
chitecture description of ISO/IEC 42010 that defines concepts for pleteness required for IoT-based systems in the agriculture and food
modelling software architectures (ISO/IEC/IEEE, 2011). In this context, domain.
software architecture is assumed to meet specific stakeholder concerns.
A stakeholder is defined as an individual, team, or organization with 3. Methodology
interests in, or concerns relative to, a system. A concern is defined as a
matter of interest in the system that could be functional or related to 3.1. Case study setup
quality issues.
Modelling architecture has been initially done in an informal The development of reference architectures is typically design-or-
manner, which often led to ambiguous representations of a system. It is iented research that aims at solving a certain problem by constructing a
now common practice to model software architecture using proper new artefact (Hevner et al., 2004; Van Aken, 2004; March and Storey,
well-defined modelling approaches, which provide either visual nota- 2008). Artefacts for real-life problems are influenced by many factors.
tions or textual descriptions to represent an architecture in a precise Case studies can deal with such complex phenomena, which cannot be
unambiguous manner. studied outside their rich, real-world context (Benbasat et al., 1987;
The architecture, is usually not drawn in one diagram but separated Eisenhardt, 1989; Yin, 2002).
in multiple so-called architecture views each of which describes an The present research has conducted a developing multiple-case
architecture according to specific stakeholders’ concerns (Clements study, which is a type of action research that develops and tests tech-
et al., 2010). An architecture view is a representation of a set of system nological rules in close collaboration with people in the field (Van
elements and relations associated with them to support a particular Aken, 2004). In such research, an individual case is primarily oriented
concern. Having multiple views helps to separate concerns and as such at solving a local problem. Following a reflective cycle, after each case a
support modelling, understanding, communication and analysis of researcher develops knowledge that can be transferred to similar con-
software architecture and the business processes to be supported for texts on basis of reflection and cross-case analyses (Eisenhardt, 1989;
different stakeholders. Architecture views are defined for a particular Hevner et al., 2004; Van Aken, 2004). To this aim, the present study has
system and need to conform to viewpoints that represent the conven- defined architecture viewpoints based on literature regarding existing
tions for constructing and using a view. An Architecture Framework is architectural frameworks. These viewpoints served as a theoretical
defined as a coordinated set of viewpoints that are used to define views. basis for abstracting replicable knowledge from case study findings
A more precise definition of architecture framework is given in the ISO (Yin, 2002).
standard: “Conventions, principles and practices for the description of For the purposes of this paper, the cases were selected to reflect the
architectures established within a specific domain of application and/or diversity of the food and farming domain, i.e. an heterogeneous selec-
community of stakeholders” (ISO/IEC/IEEE, 2011). tion based on theoretical replication logic (Eisenhardt, 1989; Yin,
Different architecture frameworks have been proposed in literature 2002). In total 19 cases were selected as being representative for dif-
(Clements et al., 2010). Well-known examples include the Zachman ferent agricultural sub sectors, conventional and organic farming, early
framework (Sowa and Zachman, 1992), Kruchten’s 4 + 1 view model adopters and early majority farmers, and different supply chain roles,
(Kruchten, 1995), the Views and Beyond approach (Clements et al., including farming, processing, logistics and consumption. The approach
2010), the Reference Model of Open Distributed Processing (RM-ODP; for the cases is a combination of a lean start-up methodology that fo-
ISO/IEC/IEEE, 2009) and the Open Group Architecture Framework cuses on the development of Minimal Viable Products (MVPs) in short
TOGAF (Josey, 2018). Furthermore, several reference architectures iterations and a multi-actor approach that stresses an active involve-
have been developed for industrial automation, including ISA-95 (ISA, ment of various stakeholders. Each case focused on the development of
2010a) and OPC Unified Architecture (OPC, 2017). IoT-based solutions for specific business needs, done by a dedicated
Initially, architectural frameworks were proposed with a fixed set of team of agri-food users (e.g. farmers, processing companies, or logistic
viewpoints. Because of different concerns that need to be addressed for service providers) and IoT companies (integrators, app/service devel-
different systems, it is currently widely recognized that a set of views opers, infrastructure/technology providers) with a clear commercial
should not be fixed but multiple viewpoints might be introduced in- drive, supported by R&D organisations.
stead. As such recent architectural frameworks, such as the Views and
Beyond approach, provide mechanisms to adapt existing viewpoints, or 3.2. Overview of the cases
to add new viewpoints.
The case study was carried out as part of the European IoF2020
2.3. Architecture of IoT-based systems project in close interaction with the involved business partners [www.
iof2020.eu]. It included 19 use cases that are organized in 5 coherent
The architecture of IoT-based systems is similar to other information trials that aim to address the most relevant challenges for the concerned
systems, but with special requirements concerning the remote identi- sub sector.
fication, sensing and control of smart objects by using sensors and ac- The Internet of Arable Farming (trial 1) integrates operations across
tuators. There are several initiatives working toward standardized ar- the entire arable cropping cycle combining IoT technologies, data ac-
chitectures to overcome fragmentation in IoT development (Weyrich quisition (soil, crop, climate) in growing and storage of arable crops

3
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

(potatoes, wheat and soya beans). These are linked to existing sensor were identified and subsequently analysed through desk research of use
networks, earth observation systems, crop growth models and yield gap case documentation and semi-structured interviews with the lead ar-
analysis tools and external databases (e.g., economic/environmental chitect of every use case (thus involving 19 interviews). The interviews
impact) as well as translated into farm management systems. The trial were conducted based on a questionnaire with a mix of open and closed
aims to result in increasing yields, less environmental impact, easier questions. The most relevant questions were related to the core idea and
cross-compliance and product traceability and more use of technology objective of a use case, main business processes targeted, objects ad-
by farmers. dressed, main actors using the envisaged system, the main functional-
The Internet of Dairy Farming (trial 2) implements, experiences and ities/services to be provided to end-users, non-functional requirements,
demonstrates the use of real-time sensor data (e.g., neck collar) to- high-level technology components envisioned and available doc-
gether with Global Positioning System (GPS) location data to create umentation. The interviews and desk research resulted in a definition of
value in a chain from ‘grass to glass’, resulting in a more efficient use of requirements to be satisfied by the architectural models and an update
resources and production of quality foods, combined with a better an- of the viewpoints and guidelines. At this, it was necessary to balance the
imal health, welfare and environment implementation. The trial focuses expressiveness of analysis and the ease of interpretation by agri-food
on feeding and reproduction of cows through early warning systems experts with no strong background in IoT, and, more in general in
and quality data that can be used for remote calibration and validation system engineering.
of sensors. Thirdly, the architecture of each use case was modelled by analysts,
The Internet of Fruits (trial 3) demonstrates IoT technology that is who applied the viewpoints and guidelines to the cases based on in-
integrated throughout a whole supply chain from farm, logistics, pro- formation gathered in the previous phase. The resulting case-specific
cessing to retail. Sensors in orchards and vineyards (including weather models were reviewed by the use case teams and iteratively refined by
stations, multispectral/thermal cameras) are connected through the the use case analyst.
cloud and used for monitoring, early warning of pests and diseases and Finally, the team of system architects and information analysts
control (e.g., variable rate spraying, selective harvesting). Traceability conducted an overall analysis of the applied models to identify com-
devices (including Radio Frequency IDentification - RFID, multi- monalities and differences of use case architectures and to identify
dimensional barcodes) and smart packaging allows for condition lessons learned for the overall method. The results of this analysis were
monitoring during storage, processing, transportation and on shelves. evaluated by the use case teams in three project workshops and giving
Big data analysis will further optimize all processes in a whole chain. bilateral feedback. This evaluation resulted in the final version of the
This is intended to result in reduced pre- and post-harvest losses, less architectural method, which is described in the present paper.
inputs, higher (fresh) quality and better traceable products (including The remainder of this paper introduces the results following the
Protected Designation of Origin, PDO). research steps as described above.
The Internet of Vegetables (trial 4) focuses on a combination of en-
vironmental control levels: full-controlled indoor growing with an ar- 4. Design architecture framework
tificial lighting system, semi-controlled greenhouse production and
non-regulated ambient conditions in open-air cultivation of vegetables. 4.1. Viewpoint definition
It demonstrates the automatic execution of growth recipes by intelligent
combination of sensors that measure crop conditions and control pro- Before modelling software architecture, it is important to define an
cesses (including lighting, climate, irrigation and logistics) and analysis architectural framework of common conventions, principles and prac-
of big data that is collected through these sensors and advanced vi- tices for addressing specific concerns of the corresponding systems
sioning systems with location specification. This is intended to result in (ISO/IEC/IEEE, 2011). A framework comprises a coherent set of
improved production control and better communication throughout a viewpoints for its stakeholders and as such it serves as a common lan-
supply chain (including harvest prediction, consumer information). guage and a basis for software development. In this study, the following
The Internet of Meat (trial 5) demonstrates how animal growth (in- basic requirements for selection of viewpoints are identified:
dividual and group level) can be optimized and communication
throughout a whole supply chain can be improved, based on automated • R1: they must support a seamless translation of business process
monitoring and control of advanced sensor-actuator systems. The data design to detailed information engineering models;
generated by events is also be used for early warning (e.g., on health • R2: they must visualize how objects are sensed and controlled by IoT
status) and for improving the transparency and traceability of meat. technologies;
This will assure meat quality, reduce mortality, optimize labour and • R3: they must support interoperability and reuse of system compo-
improve animal health and welfare leading to reduction of antibiotics. nents;
Table 1 provides an overview of the use cases of each trial, classified • R4: they must provide insight in the essence of use case systems in a
according to the selection criteria for addressing the diversity of the consistent, concise but also simple way, not overcharging the use
food and agricultural domain. case owners.

3.3. Research phasing The authors have first analysed existing architecture frameworks
that fulfil the requirements of IoT-based systems in the agri-food do-
The research was organised in four steps: (A) definition of archi- main (see Section 2). It was concluded that none of the analysed ar-
tecture viewpoints and modelling guidelines (framework), (B) re- chitecture frameworks has a direct fit with the described scenario.
quirements definition and generic analysis of the use cases, (C) mod- Generic software architecture frameworks do provide a coherent set of
elling of the use case architectures and validation, and (D) overall viewpoints for business design to technical implementation (R1), but
analysis and update method. miss viewpoints for modelling the IoT dimension (R2). IoT-specific
Firstly, a review of literature on IoT in agri-food and software ar- frameworks focus on technical IoT aspects (R2), but lack especially
chitecture was performed and various existing software architecture business viewpoints (R1). Both types of architecture frameworks in-
frameworks and IoT reference models were investigated. Based on the clude useful views for interoperability and reuse (R3). Furthermore, for
literature review, the viewpoints and modelling guidelines were de- modelling the essence of use case systems, excluding details that are not
fined and validated by a team of 39 system architects and information important for the purpose of this research, a limited set of viewpoints
analysts. can be selected from both types of frameworks (R4).
Secondly, the general context and requirements of the use cases Based on this analysis, the following six viewpoints are defined:

4
 C. Verdouw, et al.

Table 1
Overview of the cases.
Trial/sector Case Challenge Focal Country Chain Role Adopter Type Conventional/Organic

Arable 1.1 Within-field management Defining specific field management zones by developing and linking sensing- and NL Farming, Logistics Early adopters and Both
zoning actuating devices with external data majority
Arable 1.2 Precision Crop Management Smart wheat crop management by sensors data embedded in a low-power, long- FR Farming Majority Conventional
range network infrastructure
Arable 1.3 Soya Protein Management Improving protein production by combining sensor data and translate them into AT, IT Farming EarlyAdopters Both
effective machine task operations
Arable 1.4 Farm Machine Interoperability Data exchange between field machinery and farm management information DK Farming Majority Conventional
systems for supporting cross-over pilot machine communication
Dairy 2.1 Grazing Cow Monitor Monitoring and managing the outdoor grazing of cows by GPS tracking within BE Farming Both Both
ultra-narrow band communication networks
Dairy 2.2 Happy Cow Improving dairy farm productivity through 3D cow activity sensing and cloud NL Farming EarlyAdopters Both
machine learning technologies
Dairy 2.3 Silent Herdsman Herd alert management by a high node count distributed sensor network and a UK Farming Majority Conventional
cloud-based platform for decision-making
Dairy 2.4 Remote Milk Quality Remote quality assurance of accurate instruments and analysis & pro-active NL Processing, Consumption Majority Both
control in a dairy chain

5
Fruit 3.1 Fresh table grapes chain Real-time monitoring and control of water supply and crop protection of table IT, GR Farming, Logistics Early Adopters Both
grapes and predicting shelf life
Fruit 3.2 Big wine optimization Optimizing cultivation and processing of wine by sensor-actuator networks and FR Farming, Processing Early Adopters Both
big data analysis within a cloud framework
Fruit 3.3 Automated olive chain: Automated field control, product segmentation, processing and commercialisation SP, IT Farming, Processing, Logistics Majority Conventional
of olives and olive oil
Fruit 3.4 Intelligent fruit logistics Fresh fruit logistics through virtualization of fruit products by intelligent trays GE Logistics, Consumption Majority Both
within a low-power long-range network infrastructure
Vegs 4.1 City farming Value chain innovation for leafy vegetables in convenience foods by integrated NL Farming, Logistics Early Adopters Conventional
indoor climate control and logistics
Vegs 4.2 Chain-integrated greenhouse Integrating the value chain and quality innovation by developing a full sensor- SP Farming, Logistics, Consumption Majority Both
production actuator-based system in tomato greenhouses
Vegs 4.3 Added value weeding data Boosting value chains by harvesting weeding data of organic vegetables obtained NL, AT Farming Majority Organic
by advanced visioning systems
Vegs 4.4 Enhanced quality certification Enhanced trust and simplification of quality certification systems by use of IT Farming, Logistics, Consumption Majority Both
system sensors, RFID tags and intelligent chain analyses
Meat 5.1 Pig farm management Optimise pig production management by interoperable on-farm sensors and BE, NL Farming, Processing, Both Both
slaughter house data Consumption
Meat 5.2 Poultry chain management Optimize production, transport and processing of poultry meat by automated SP Farming, Logistics, Processing Majority Conventional
ambient monitoring & control and data analyses
Meat 5.3 Meat Transparency and Enhancing transparency and traceability of meat based on an monitored chain GE, NL Farming, Logistics, Processing, Majority Both
Traceability event data in an EPCIS-infrastructure Consumption
Computers and Electronics in Agriculture 165 (2019) 104939
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

• Domain model viewpoint: general view of key functional aspects of an First, the viewpoint visualizes the physical product flow of input ma-
IoT-based system concerning the key actors, main physical entities terial to end products and the main objects (things) involved. Second,
(e.g., animals, goods, equipment), main IoT components and its the main business processes for planning and control of the physical
interactions, this viewpoint provides a common understanding and flow are placed in different layers, based on their position in the pro-
terminology for other views and is based on the logical view of the duction control hierarchy. These layers address different time horizons,
4 + 1 framework (Kruchten, 1995); ranging from operational control of physical objects to enterprise man-
• Business process hierarchy viewpoint: overview of business processes agement level. The levels are defined using a standard approach, defined
and their interrelations, including the physical product flow of input for the industrial domain, but also suitable for farming and food sys-
material to end products, the main objects (things) involved and the tems: the ISA-95 reference model (ISA, 2010a).
position of business processes in the production control hierarchy, ISA-95, formerly known as S95, is a framework that focuses on in-
ranging from operational control of physical objects to enterprise tegration of office automation and production automation and me-
management level, based on the ISA95 reference model (ISA, chanization (ISA, 2010a; Verdouw et al., 2015). It is widely adopted in
2010a); the international production industry, among others, in the pharma-
• IoT layer viewpoint: classifies IoT functionalities into different tech- ceutical, petrochemical and food processing sectors. ISA-95 consists of
nical layers ranging from device layer until application layer, as models and terminology about: (i) information exchange between en-
such it provides an overview of the technical architecture and allows terprise management systems and manufacturing operations systems;
to identify suitable technology providers; this viewpoint is based on (ii) activities in manufacturing operations systems; and (iii) exchanged
the ITU-T Y.2060 IoT Reference Model (ITU-T, 2016); information within manufacturing operations systems. More specifi-
• Deployment viewpoint: visualizes the location of hardware and soft- cally, ISA95 addresses four control levels, which are based on the
ware components and how they are deployed; as such it defines a Purdue Reference Model (Williams, 1994; ISA, 2010b):
detailed technical architecture, based on the physical view of the
4 + 1 framework (Kruchten, 1995); • Level 0 & 1: the actual physical processes and its sensing and ac-
• Information model viewpoint: depicts the data entities of an IoT-based tuation;
system, including data models of databases used, specifications of • Level 2: manufacturing operations management systems that su-
raw data collected by deployed IoT sensors, standard identification pervise, monitor and control physical processes, especially
schemas, data entities in communication protocols, etc.; this view- Supervisory Control and Data Acquisition systems (SCADA),
point is based on the RM-ODP framework (Raymond, 1994); Programmable Logic Controllers (PLC) and Distributed Control
• Interoperability endpoints viewpoint: defines main interfaces for in- Systems (DCS);
tegration with external systems including standards and protocols to • Level 3: systems, which manage the workflow of batch, continuous
be used, derived from the information model viewpoint; it helps to or discrete production operations, especially Manufacturing
identify potential technical synergies among IoT-based systems. Execution Systems (MES);
• Level 4: business planning & logistics systems that manage business-
These viewpoints will be described in the following subsections: related activities of production, including production planning and
domain model viewpoint (Section 4.2), business process hierarchy scheduling, material use, shipping and inventory management,
viewpoint (Section 4.3), IoT layer viewpoint (Section 4.4), deployment especially in Enterprise Resource Planning (ERP) systems.
viewpoint (Section 4.5), information model viewpoint (Section 4.6),
and interoperability endpoints viewpoint (Section 4.7). Moreover, a Fig. 1 shows the four layers of the Business Process Hierarchy View.
guideline to apply these viewpoints will be introduced in Section 4.8. The Management Information Layer contains processes related to the
control of an entire enterprise (e.g., a farm), on an aggregate level and
4.2. Domain model viewpoint with the longest time horizon (months, weeks, days). The Operations
Execution Layer contains processes related to the definition, control and
The domain model view is used to provide a general view of main performance of tasks, with an intermediate time horizon (days, hours,
concepts and relationships for the case being analysed. The naming and minutes). The Production Control Layer contains processes related to
identification of these concepts and relationships provide a common the execution of tasks by equipment and humans, with shortest time
understanding and terminology for other views. More specifically, this horizon (minutes, seconds, milliseconds). Finally, the Physical Object
viewpoint summarizes in one diagram the key functional aspects of the Layer shows the relation to objects in the physical world, eventually
cases concerning: the key actors, main objects and physical entities including IoT sensors and actuators. These objects can be fields, stables,
involved (e.g., animals, goods, equipment), the main IoT components, animals, plants, farm equipment, processing facilities, containers,
and how these entities interact with each other and to obtain what. For boxes, trucks, but also humans like employees or consumers.
example, such entities could be IoT architectural entities like the ones The business process hierarchy viewpoint is defined in Table 3.
described in the Architectural Reference Model IoT-A adopted by AIOTI
(Carrez et al., 2013; AIOTI, 2018) and ontologies for agriculture and 4.4. IoT layer viewpoint
farming (Roussey et al., 2019), as well as agricultural data dictionaries,
like the ISOBUS Data Dictionary (VDMA, 2019). The domain model is The IoT layer view is used to classify each component from a
an introductory viewpoint in many software architecture frameworks. technical IoT perspective. It supports categorizing each component of
In particular we adopted the logical view of the 4 + 1 architecture an use case in a way that allows to identify suitable providers of in-
framework (Kruchten, 1995), which uses UML class diagrams for re- frastructure or technology capable to offer such component. As such it
presentation (OMG, 2011). shows a concrete overview of the mapping between adopted compo-
The key aspects addressed by the domain model viewpoint are nents and common IoT functionalities, indicating to which layer of the
provided in Table 2. reference model, a particular component belongs to.
The IoT layer view is aligned with main on-going IoT trends and
4.3. Business process hierarchy viewpoint standardization efforts, like, for example, the recommendation by
AIOTI WG03 (AIOTI, 2018). To do this, the main features of an IoT-
The business process hierarchy view shows an overview of business based system are depicted inside the ITU-T Y.2060 IoT Reference Model
processes and their interrelations. Two dimensions are added to regular (ITU-T, 2016) (see Fig. 2).
business process models to adapt it to the specific characteristics of IoT. The viewpoint contains the following layers:

6
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Table 2
Summary of the domain model viewpoint.
Name Domain model

Concerns functionality, usage, system purposes, system features, system properties, structure, behaviour, modularity, control, inter-process communication, complexity
Stakeholders IoT related stakeholders: technology providers, infrastructure providers, integrators. Agri-food related stakeholders
Elements Agri-food Actor, Agri-food Good, Agri-food Data Entity, IoT Sensors, IoT System, IoT Data Entity
Relations Provides data to, aggregation, containment, inheritance
Constraints No constraints, every relationship can be used for every entity
Notation

Existing elements in gray, components and entities to be developed in green

• Application layer, which contains IoT applications; management;

• Service support and application support layer, which contains cap- • Security capabilities: cross-layer capabilities at application, network
abilities that can be used by several IoT applications; and device layer.
• Network layer, which provides control functions of network con-
nectivity and connectivity for transport of application-specific data; The IoT layer viewpoint is defined in Table 4.
• Device layer, subdivided in device capabilities, which are network
capabilities at device level, and gateway capabilities, which are 4.5. Deployment viewpoint
network capabilities at gateway level, e.g., multiple interfaces sup-
port, protocol conversion; The deployment view visualizes the physical deployment of an IoT-
• Management capabilities: cross-layer capabilities related to an IoT based system, i.e. location of hardware and software components and
network, e.g., device management, traffic and congestion how they are deployed. The view is used to show a concrete explanation

Fig. 1. Generic example of the process hierarchy view.

7
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Table 3
Summary of the business process hierarchy viewpoint.
Name Business Process Hierarchy

Concerns System purposes, control activities undertaken by a system, objects addressed by an IoT system
Stakeholders business decision-makers, product managers, business analysts, system architects, developers and integrators
Elements Objects, Business Processes, Control Layers
Relations Transformations, Information Flows, Object Control Relation (sense or actuate)
Constraints • Objects can only be defined in the physical object layer
• Transformations can only connect objects
• Business processes can only be defined in Control Layers
• Information Flows can only connect Business Processes

Notation
• Object Control Relations have to connect objects and business processes of the Production Control Layer

of the deployment of systems, their location and the way they are in- Furthermore, it indicates if data can be mapped using standard ontol-
tegrating in an use case scenario. Specifically, it depicts a list of the ogies or taxonomies, the relation among data entities of an use case and
components (hardware and software), indicating where they are in- finally how they are transcoded, converted, mapped and elaborated.
stalled (for example identifying the specific software that is deployed on The information model viewpoint is included in most software ar-
the related computer); and requirements in terms of connectivity for chitecture frameworks. The present framework in particular adopted
each component. the information view of RM-ODP framework (Raymond, 1994), which
The deployment viewpoint is included in most software architecture uses UML Entity Relationship Diagrams for its representation (OMG,
frameworks. The present framework in particular adopted the physical 2011).
view of the 4 + 1 architecture framework (Kruchten, 1995), which uses The information model viewpoint is defined in Table 6.
UML deployment diagrams for its representation (OMG, 2011).
The deployment viewpoint is defined in Table 5.
4.7. Interoperability endpoints viewpoint

4.6. Information model viewpoint This interoperability endpoints view indicates main endpoints that
can be leveraged for integration of different systems. The objective is to
The information model view (Lee, 1999) is used to model all data identify most suitable interfaces for interacting with legacy and IoT
entities of an IoT-based system, including data models representing systems deployed in each use case and at the same time the set of
used databases, specifications of raw data collected by deployed IoT standards and protocols to be used.
sensors, standard identification schemas, data entities in communica- This view is complementing the information model viewpoint, be-
tion protocols, etc. The view is used to show in a single diagram the cause information is usually distributed across other views. The inter-
basic data-related aspects of UCs, indicating data entities present in this operability endpoints allow for the identification of potential technical
use case, their format and from which systems they are handled. synergies.

Fig. 2. The ITU-T Y.2060 reference model.

8
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Table 4
Summary of the IoT layer viewpoint.
Name IoT layer

Concerns Map between adopted components and common IoT functionalities, system deployment, system localization, system integration
Stakeholders IoT related stakeholders: technology providers, infrastructure providers, integrators
Elements Management Capabilities, Application Layer, Service Support and Application Support Layer, Network Layer, Device Layer, Device Capabilities, Gateway
Capabilities, Security Capabilities
Relations n/a
Constraints Entities cannot overlap more layers
Notation

The interoperability endpoints viewpoint is defined in Table 7. model.

Subsequently, an IoT layer view is developed for addressing tech-
4.8. Guideline for applying the architecture framework nical IoT concerns. Again, this view must be consistent with the pre-
vious models. Especially, a modeller should check if the IoT elements of
In the previous subsections we have described six viewpoints that the domain model are addressed. Concerning the business process
together form an architecture framework for modelling IoT based agri- hierarchy view, all processes must be aligned with the application layer
food systems. In this section we introduce a guideline, i.e. a general components, while the sense and control processes should be addressed
method, for applying these viewpoints. in the device layer.
Fig. 3 shows the activities of this method in a Business Process The next view to be modelled is a deployment view for allocating
Modelling Notation (BPMN) diagram. The first step is identifying an software elements to hardware nodes, and in parallel the development
organization’s objectives and stakeholder concerns, followed by de- of an interoperability endpoint view for addressing interoperability
veloping a domain model view and a business process hierarchy view. concerns. The components of a deployment diagram should especially
The domain model addresses the objectives and concerns defined from be in accordance to the IoT system elements of a domain model and the
the corresponding application domain perspective, while the business IoT components of an IoT layer model. Interoperability endpoints
process hierarchy view represents its business and organizational con- should especially be aligned with the network layer of IoT layer views
cerns. The consistency of both models, including its ontology, must be and the components of deployment models.
checked carefully. For example: IoT sensors in a domain model should The final step is validation and a final consistency check of the
be compliant with sensing processes in a business process hierarchy developed views. This activity also checks if there are any updates in
model. the viewpoints as defined in the framework. In case of inconsistencies,
The subsequent step is the development of an information model missing issues and/or updates of the framework, the process iterates to
view that focuses on data aspects. Information models must be con- the first steps, which implies that the modelled views are improved.
sistent with domain and business process hierarchy models. Its elements The above represents a general method that is based on the COST-
should be compliant with the data entities included in a domain model WORTH approach (Kirchhoff et al., 2004) and that is further developed
and with the provide-data-to relations in a business process hierarchy from experiences in the project. For achieving this level, several

Table 5
Summary of the deployment viewpoint.
Name Deployment View

Concerns Functionality, usage, system features, structure, behaviour, resource utilization, reliability, complexity, evolvability, cost, flexibility, agility, modifiability,
modularity, control, inter-process communication, subsystem integration, data accessibility, maintainability
Stakeholders Technology providers, infrastructure providers, integrators, maintainers
Elements Node, Execution Environment, Component
Relations Connection, interface
Constraints Execution environments need to be indicated only if there are two or more of them in one node
Notation UML deployment Diagram (OMG, 2011)

9
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Table 6
Summary of the information model viewpoint.
Name Information Model

Concerns Usage, system properties, structure, complexity, modifiability, inter-process communication

Stakeholders Integrators, Developers, Maintainers
Elements Events, Data Packet, Data Entry
Relations Is derived from, aggregation, containment, inheritance
Constraints There are no constraints, each relation can be used by each entity
Notation UML diagram, accompanied by a descriptive table providing details about the most relevant data entities

Table 7
Summary of the interoperability endpoints viewpoint.
Name Interoperability Endpoints

Concerns Inter-process communication, data accessibility.

Stakeholders 3d party system Integrators
Elements n/a
Relations n/a
Constraints Each row of the table must contains a description of an interface and the associated protocol to be used.
Notation Table with a list of interfaces

iterations were made in practice. The use case teams were assisted in modelling the architectures of IoT-based systems in a large spectrum of
specifying envisaged IoT-based solutions. In an early phase, when different agricultural domains and applications. The following para-
aiming at the set-up of the overall consortium of over 70 partner or- graphs provide an overview of the application of the proposed archi-
ganisations, they were asked to prepare a basic use case description, tectural framework to the use cases of the present study.
outlining their underlying objectives and critical business processes to
be improved clearly identifying stakeholder concerns. Based on the 5.1. Overview use case architectures
motivation to install a continuous ICT-based business improvement
process, the modelling elements as described in the previous sections The framework is used to model use case architectures in the same
were selected and compiled to facilitate the realisation of a systematic way, resulting for every use case in a coherent set of standardized
and harmonised approach when describing all 19 use cases. views, i.e. applications of the viewpoints as defined in the framework.
The initial use case description was a reference document to analyse Table 8 summarizes how many elements are used within each view-
and design the future realisation of related business processes. point to indicate the level of detail of the applied use case architectures.
Specifically, the domain model and business process hierarchy view- Generally, the IoT-based solutions, realized in the use cases, are quite
points were used to understand the relation of different process and heterogeneous due to differences in the agri-food sectors and business
technical components that need to be reused, adapted, or developed. To challenges addressed. Therefore, the individual architectures are in-
ensure the relation of organisational objectives over different abstrac- cluding diverse sets of elements. For instance, a broad range of net-
tion layers, validation and consistency checks of views are essential as working technologies and a large number of different cloud platforms
well as facilitating an understanding of the relations between real, di- are employed within the different use cases. Use cases implement di-
gital and virtual world aspects of IoT-based solutions. The elaboration verse sensors and measure a vast array of data dimensions, including
of IoT layer and deployment views benefits from a realisation in dif- animal and crop features, outdoor and indoor conditions, as well as soil
ferent iterations, since each iteration cycle helps to also validate the characteristics. The majority of use cases moves beyond passive portals
technical feasibility and to plan specific iterations of envisaged with sensor data and introduce intelligent, task-specific decision sup-
minimum viable products (MVPs). port for agri-food professionals and/or fully autonomous control loops
Next section will describe the application of the proposed frame- that automatically trigger actuators based on sensor data and statistical
work to the cases. data processing. State of the art, IoT-specific networking protocols such
as Lora and Sigfox are deployed by a large number of use cases.
5. Application of the framework to IoF2020 use cases For the purpose of this paper and for brevity reasons, the remainder
of this section presents the architectures of three use cases (out of 19) to
The presented framework is applied to 19 use cases in different show the application of the modelling method for each addressed
regions of Europe (see Table 1) to demonstrate its effectiveness for viewpoint. We have chosen use cases that illustrate the diversity of the

10
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 3. Guideline for applying the Architecture Framework.

domain, especially concerning the subsectors, challenges and supply 5.2. Architecture use case ‘Added Value Weeding Data’
chain roles. The following Table 9 summarizes the three selected use
cases. For a description of all use case architectures we refer to (Tomasi With the growth of organic vegetables, weeding represents one of
et al., 2018). the most important and frequent activities to control both the quality of

11
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Table 8
Number of main elements addressed in each viewpoint.
Use case Domain: Layer: IoT Business Process Deployment: nodes/ Information: data Interoperability
concepts functions Hierarchy: Objects/ components elements Endpoints
Processes

1.1 Within-field management 15 14 9/16 7/16 N.A. 2

zoning
1.2 Precision Crop Management 16 19 5/12 16/38 25 13
1.3 Soya Protein Management 12 9 4/10 5/10 N.A. 3
1.4 Farm Machine Interoperability 19 23 5/15 5/16 19 4
2.1 Grazing Cow Monitor 12 8 6/11 3/6 9 2
2.2 Happy Cow 16 9 4/10 5/11 19 3
2.3 Silent Herdsman 8 8 5/15 5/9 8 4
2.4 Remote Milk Quality 17 13 7/16 6/15 14 5
3.1 Fresh table grapes chain 21 13 9/17 6/26 18 1
3.2 Big wine optimization 37 23 12/21 12/22 7 N.A.
3.3 Automated olive chain: 16 12 7/16 5/11 9 5
3.4 Intelligent fruit logistics 19 18 11/18 6/16 18 9
4.1 City farming 16 10 N.A. 5/9 7 4
4.2 Chain-integrated greenhouse 8 8 6/12 5/9 5 5
production
4.3 Added value weeding data 26 18 6/17 11/49 31 6
4.4 Enhanced quality certification 20 22 9/18 9/22 19 11
system
5.1 Pig farm management 23 12 7/17 8/17 25 12
5.2 Poultry chain management 20 10 8/15 15/31 19 10
5.3 Meat Transparency and 10 10 0/6 5/9 11 3
Traceability

a field and its produce. In recent years, automated intra-row weeding This model shows how sensing data of weed pressure, crop growth
machines have entered the market, greatly facilitating the weeding and harvest is used for precision weeding and farm management. In the
process. The most advanced weeding machines use machine vision Physical Object Layer, relevant objects of this case are depicted: weeds
applications to distinguish crops from weeds. As camera systems’ sensor and growing crops in the field. The weeding machine detects and re-
data is a valuable information source, this use case collects location- moves weeds. Once the crops are ready for consumption, they are
specific camera data to provide insights on the number of vegetables harvested with a harvest machine. The other layers include main farm
growing on the field, plants’ growth status and best harvesting moment, processes on different time horizons that are needed in this case to
weed prevalence, nutrient shortages and drought stress. sense and control the physical objects. The Production Control Layer
includes operational processes to (physically) sense and control the
5.2.1. Domain model view weeds, crops and harvest. The weed pressure and crop growth are
The domain model of the use case ‘Added Value Weeding Data’ is sensed by cameras and sensors in the weeding machine. The harvest
depicted in Fig. 4. machine includes a sensor for yield monitoring. This data is collected
The main components in the domain model are the Steketee weeder, and analysed in the Operations Execution Layer. Aggregated data are
a field, tractor and harvest machine. Besides, there are a few stand- used in the Management Information Layer to monitor crop growth and
alone elements, which are sources of information like a soil sensor or an weed pressure. Next, the location-specific weeding need is calculated
smartphone app. based on the weeding pressure monitoring and specific weeding tasks
In the Steketee weeder, images are processed to extract field in- are planned. Alongside, also expected yields are predicted, based on
formation like crop size, growing stage and weed pressure. The machine crop growth monitoring, and translated into a detailed harvest plan-
was developed to perform intra-row weeding. To extract more man- ning. Both weeding and harvesting plans may result in location-specific
agement information from fields, some elements are added to the farm operations. The farm control triggers the execution of these ac-
Steketee weeder component. With this information the development tions by sending the specific machine requirements and task definition
team can make a better Decision Support System (DSS) for farmers. to the Operations Execution Layer. In this layer the settings of weeding
The field component contains elements, which have direct influence and harvesting machines are defined, weeding or harvesting tasks are
on the total yield. Weed and crop images are used in the weeder as scheduled and machine-readable task instructions (precision task maps)
inputs to determine where to actuate the weeding elements. In the are sent to the Production Control Layer. The machine control process
harvest machine a yield monitor will be added to get feedback on the of the weeder or harvester, then, implements the specific machine
performance of crops. Crop yield is the result of all actions performed in settings and executes specific instructions.
the last year and years before. This information will be used to predict
an optimum harvesting date and the expected yield. 5.2.3. IoT layer view
The tractor component contains GPS information which is used to The IoT layer view of the use case ‘Added Value Weeding Data’ is
process information from the field in a spatial way. This gives the op- depicted in Fig. 6.
portunity to perform site-specific measures on the field. All these ele- The Application Layer includes an IoT dashboard for farmers and
ments will provide input for two Decision Support Systems (DSS)s, one the machine vendor (Steketee). The machine vendor’s dashboard is
DSS for the machine settings for the Steketee weeder and one DSS for used to setup machines, to optimize and update settings and for
field/crop management. maintenance purposes. The farmer’s dashboard is used for operational
sensing of weed pressure, crop growth and harvest, as well as for
5.2.2. Business process hierarchy view monitoring the execution of farming tasks. The AgLeader system sup-
The business process hierarchy model of the use case ‘Added Value ports usage of sensing data for farm management, including yield
Weeding Data’ is depicted in Fig. 5. prediction, planning of farm operations and triggering execution.

12
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

The Service and Application Support Services Layer comprises web

Conventional/Organic
services and cloud data management capabilities that are used by
dashboards and farm management systems in the Application Layer.
The Network Layer includes different kinds of wired and wireless in-
Organic terfaces for connecting the weeding machine, tractor and harvester and
Both

Both
for communication of machines and sensors with cloud systems. The
Device Layer includes generic Device Capabilities for the sensors and
Adopter Type

actuators that are embedded in the weeding and harvesting machines

and for soil sensors in the field. The terminals on the weeder and har-
Majority

Majority

vester are the main gateways that include local data processing and
Both

storage (e.g., of the images). The tractor terminal is used as a GPS

gateway.

5.2.4. Deployment view

Logistics, Consumption

The deployment view of the use case ‘Added Value Weeding Data’ is
Farming, Processing,

depicted in Fig. 7.
The main deployed components are machines on the field, i.e., a
Consumption
Chain Role

tractor, IC weeder and harvest implement, and components to store,

Farming

access, process, analyse and use the data generated, i.e., cloud plat-
forms, local PC and advisory services. For the weeding task, the pro-
cessing of camera images will be done offline in the IC weeder and the
Focal Country

processed information, like weed pressure and crop size, is directly

available after weeding. Other data that are generated during operation
NL, AT

BE, NL

are first logged on the machine. After operation they are transferred to
GE

cloud storage. Besides weed/crop data a settings file will be logged as

well. This will be used by Steketee to improve machine settings by
Fresh fruit logistics through virtualization of fruit products by intelligent trays within a low-power

Boosting the value chain by harvesting weeding data of organic vegetables obtained by advanced

Optimise pig production management by interoperable on-farm sensors and slaughter house data

learning from all types of weed/crop/field circumstances. Initially it

will be used for generating advised settings.
A cloud platform will be the storage for all data from the IC weeder,
harvester, Farm Management Information System (FMIS), machine
services from the vendor Steketee and advisory services from
Wageningen Research, e.g. about crop growth and yield prediction. All
nodes are in a way connected to the cloud to have one central data
storage point. Data from the cloud can be downloaded by Steketee or
Wageningen Research, processed and put back on the cloud to be used
by farmers. Data can be used directly in the IC weeder (e.g., settings
update) or via the FMIS for farmers to be used for decision support.

5.2.5. Information model view

The information model view of the use case ‘Added Value Weeding
Use cases of which the architectures are presented in the paper (subset of Table 1).

Data’ is depicted in Fig. 8.

The information model above is closely related to application
long-range network infrastructure

functionalities in the deployment view and the information exchanged

between them. It distinguishes: (i) operational data flows, i.e. com-
mands, responses and actuals; (ii) expert rules data, e.g. algorithms; (iii)
advice data, such as alerts and predictions; and (iv) management data,
including definitions, schedules, capabilities, and performance.
visioning systems

5.2.6. Interoperability endpoints view

Challenge

The interoperability endpoints of this use case, as listed in Appendix

A, are interfaces to access data on the weeding and harvest machines, a
GPS interface on the tractor to get position data and Application Pro-
4.3 Added value weeding data
3.4 Intelligent fruit logistics

gramming Interfaces (APIs) to communicate with the farm and machine

5.1 Pig farm management

vendor cloud platforms and the yield prediction service.

5.3. Architecture use case ‘Pig Farm Management’

This use case is related to the management of pig farms via optimal
Case

use of data throughout the chain. Through automated collection, pro-

cessing and sharing of crucial information it aims at providing feedback
Trial/sector

to farmers via an easy-to-use interface (a pig business intelligence

dashboard). In addition, the use case also fosters the reuse of collected
Table 9

Meat
Fruit

Vegs

data to enable information transfer to other relevant stakeholders

(breeders, food processors, feed suppliers, veterinarians, etc.).

13
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 4. Domain model view of the use case ‘Added Value Weeding Data’.

5.3.1. Domain model view water consumption, fattening performance and health parameters of
The domain model for the use case ‘Pig Farm Management’ is de- both individual and group of pigs. Different IoT sensors, already de-
picted in Fig. 9. ployed in the farm, will measure these parameters. Furthermore, a RFID
In this use case, a farmer is monitoring and optimizing feed and reader can read the unique identification (tag) of each individual pig to

Fig. 5. Business process hierarchy view of the use case ‘Added Value Weeding Data’.

14
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 6. IoT layer view of the use case ‘Added Value Weeding Data’.

track its movements in specific areas in which other sensors are active information required by this use case are depicted: fattening perfor-
and, consequently, associate other collected information to the right mance, eating behaviour, health behaviour, that are sensed with IoT
pig. For example: if a flow of water is revealed and only one pig is near sensors and batch data. Farmer are especially interested in monitoring
the tap, it is possible to deduce how much water was drunk by that and optimizing of the eating behaviour, fattening performance and
specific pig. This possibility is assured by physically attaching unique health of individual pigs. At the same time, experts are mainly inter-
RFID tags to the pigs’ ears. However, in some farms RFID tags are not ested in the detection of boar taint smell and slaughterhouse workers in
used and/or some local laws do not allow it. In these circumstances, data regarding carcass, boar taint, and transport.
group level information is collected without storing the association to The other layers include the main farm processes on different time
individual pigs. This group level monitoring is most commonly used in horizons that are needed in this case to sense and control physical
practice. objects. The starting point is sensing of pig fattening and growth in the
Other IoT sensors fostered in this use case are weight scales, water Production Control Layer based on IoT sensor data. This data is col-
and feed consumption sensors that allow to measure the weight and the lected and analysed in the Operations Execution Layer. Subsequently,
water and feed consumption for individual pigs. Moreover, tempera- aggregated data is used in the Management Information Layer to
ture, relative humidity and light intensity sensors can be used to monitor pig growth and fattening. Next, an overview of farm status and
monitor climate and light in barns. pig health is calculated based on pig growth and fattening monitoring,
In addition to the data collected through IoT sensors, some other providing information for farmers, experts and slaughterhouse workers.
input data can be provided by farmers and/or experts about barns and Finally, this analysis is used to update the planning and to control its
pens through a dedicated web-based dashboard. An example of this execution.
information is called ‘boar taint’, which is an unpleasant odour that can
occur in entire male carcasses and that can drastically negatively in- 5.3.3. IoT layer view
fluence the final price of the produced meat. Boar taint is currently only The IoT layer viewpoint of this use case (depicted in Fig. 11) is
detected by humans at the slaughter line. structured as follows:
All the described data is stored in a data storage system, which feeds
dedicated algorithms suitable to extract eating behaviour, fattening • Application layer: in this layer, a web-based dashboard is provided to
performance and pig health figures. Such extracted inferences are visualize collected IoT data.
shown to farmers through a dedicated web-based business intelligence • Service support and application support layer: both generic support
dashboard. capabilities and specific support capabilities are provided within
this use case. Specifically, a Business Intelligent Dashboard allows to
analyse data and provide an overview of farm status and warnings in
5.3.2. Business process hierarchy view
case status is not optimal, while the Fusion Engine Service allows to
The Business Process Hierarchy view for the use case ‘Pig Farm
elaborate the data. In addition, there are common capabilities,
Management’ is depicted in Fig. 10.
which can be used by different IoT applications, such as Cloud Data
The Business Process Hierarchy View comprises four layers:
Storage and Data & Context Broker.
Physical Object Layer, Production Control Layer, Operations Execution
Layer and Management Information Layer. • Network layer: in this layer both Networking Capabilities and
Transport Capabilities are provided. Respectively, the first provide
In the Physical Object Layer, the most relevant groups of

15
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 7. Deployment view of the use case ‘Added Value Weeding Data’.

relevant control functions of network connectivity while the second • Management capabilities: in this use case these capabilities are
focuses on providing connectivity for the transport of IoT service especially demanded for existing infrastructures and systems al-
and application specific data information. Network and transport ready installed in the farm.
connectivity are provided through specific technologies such as Wi- • Security capabilities: this use case mainly leverages security functions
Fi, GPRS, XMPP-IoT, and NGSI (Cantera et al., 2018). The same of specific technologies that are already present in the farms.
happens for Mobility Management Capabilities that use specific
protocols based on the used technology. 5.3.4. Deployment view
• Device layer: this UC includes general functions provided by existing The deployment view for the use case ‘Pig Farm Management’ is
devices and gateways. Specifically, Device Capabilities includes (a) depicted in Fig. 12.
sleeping and waking-up of devices to reduce energy consumption, Components in this use case are deployed either locally (i.e., in a
(b) the possibility of sensors and actuators to gather and upload farm and or slaughterhouse) or remotely (i.e., in the cloud or in a self-
information directly or indirectly to the communication network, (c) hosted cloud server).
the capacity of devices to construct networks in an ad-hoc net- In a farm, five different physicals dedicated sensor platforms are
working based on a specific technology. Gateway Capabilities in- deployed, namely a RFID reader platform, a water consumption plat-
clude supported devices that are connected through different kinds form, a feed sensor platform, a daily growth platform and a climate
of wired or wireless technologies (multiple interfaces) and protocol control platform. Each platform corresponds to a node composed by a
conversion. dedicated stand-alone PC installed in a protected location in the farm

16
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 8. Information model view of the use case ‘Added Value Weeding Data’.

that is connected to a local farm Local Area Network (LAN) used to components, one “Local IoT Middleware Component” and one “Local
inter-connect these nodes to a farm server. Data Storage” built upon a standard MongoDB installation.
The Farm Server is a general-purpose ruggedized x86-64 PC running The Farm Server is connected though the Internet to a global Virtual
Windows 10 IoT Enterprise, which hosts five dedicated “IoT Adapter” Private Network (VPN), which allows secure communications towards a

17
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 9. Domain Model of the use case ‘Pig Farm Management’.

private Cloud Service platform. The cloud platform runs: (a) a Cloud 5.3.5. Information model view
Data Storage service and a Data & Context Broker, which receive data The Information model for the use case ‘Pig Farm Management’ is
via XMPP-IoT or NGSI from farm servers; (b) a Business Intelligent depicted in Fig. 13.
Dashboard, accessible via HyperText Transfer Protocol over Secure On the left side, there are sensor data entities that have at least a
Socket Layer (HTTPS); and (c) a Fusion Engine Service running algo- unique identifier. Those data are classified as ‘raw sensor data’ and
rithms. include humidity, temperature, water consumption, feed consumption
and presence sensor data. The entity ‘drinking event’, which is derived
from water consumption and/or presence, also has a unique identifier.

Fig. 10. Business Process Hierarchy view of the use case ‘Pig Farm Management’.

18
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 11. IoT layer view of the use case ‘Pig Farm Management’.

The attribute ‘duration’ is used for describing the period of event and linked with farm and uniquely identified by a unique identifier.
‘timestamp_start’ shows the time when an event is started. The same
values are also collected for the ‘eating event’ that it is derived from
feed consumption and/or presence. 5.3.6. Interoperability endpoints view
An RFID tag, uniquely identified by a tag_id, is associated to each The interoperability endpoints of this use case, as defined in
pig. Every drinking event and eating event are in correlation with an Appendix A, are interfaces to access data collected and provided by the
RFID tag, so that it is possible to link each event to a pig. Furthermore, present use case. These data include water consumption, feed con-
daily growth, health and genetics data are batch data linked with the sumption, daily growth and climate control. Other sensor interfaces
pig. The climate entity is a batch data derived from humidity and provide data acquired through infrastructures already present in farms
temperature entities, linked to a specific barn or pen. that can be accessed through a farm server interface. The RFID reader
Other batch data, useful for the system, are boar taint, carcass and tag allow to uniquely identify each pig and to monitor its behaviour
parameters and transport & waiting time that are linked with slaughter. in the pens. The slaughterhouse database interface and the slaughter-
Finally, pen and barn characteristic and survey are batch data that are house server interface provide access to all data gathered in the
slaughterhouse. The cloud service database interface and the data &

Fig. 12. Deployment view of the use case ‘Pig Farm Management’.

19
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 13. Information model of the use case ‘Pig Farm Management’.

context broker expose all information collected in this use case. RTI pool. It is foreseen to use a long range low bandwidth commu-
nication protocol to maximize life-time of the IoT devices and possibly
5.4. Architecture use case ‘Intelligent Fruit Logistics’ to enable determination of the position. However, initial experiments
with this technology came to the conclusion that the accuracy of the
The strategic objective of this use case is to connect IoT-enabled geo-localisation is currently not yet precise enough for the requirements
Returnable Trade Items (RTIs) with smart applications, to open a new of this use case. Therefore, also a GPS chip is used to increase the ac-
dimension of added value services in multi-stakeholder fruit and ve- curacy of the RTI geo-localisation.
getable supply networks. The main stakeholder and use case leader is This real-time monitoring of RTIs is integrated with existing systems
Euro Pool System, a returnable packaging pool provider and European for monitoring and planning their usage as well as combined with the
market leader for returnable packaging in the fruit and vegetable classical RTI identification technologies. Furthermore, the current ERP
sector. Existing Euro Pool System RTIs are equipped with IoT devices to and External Places APIs can be used to identify locations and to
enable the RTIs to transmit information during their usage by Euro Pool manage Global Location Numbers (GLN)s in relation to the RTI users. In
System’s customers. a later phase, it could be foreseen to offer an EPCIS interface and ad-
The key stakeholders are located in Germany and the Netherlands. ditional customer services to enable RTI users to access event data that
GS1 Germany supports the use case realisation as expert regarding is relevant for their specific business processes.
identification and Electronic Product Code Information Services The domain model of the use case ‘Intelligent Fruit Logistics’ is
(EPCIS). From an IoT perspective, semiconductor manufacturer NXP depicted in Fig. 14.
facilitates the experimentation with advanced IoT technology. ATB
Bremen as research and innovation partner develops smart application 5.4.2. Business process hierarchy view
for different MVPs, while Mieloo & Alexander is customising diverse The main purpose of the solution is to facilitate a free circulation of
ICT solution components, bridging gaps between diverse systems when RTIs from the pool as well as to guarantee a proper operation of the
providing their expertise as system integrator. pool and avoid misuse. Therefore, the management information layer is
representing the key supportive activities when the RTIs are circulating
5.4.1. Domain model view from the depot to users and backwards to the depots for an appropriate
The main stakeholder is operating a pool of around 140 million RTIs cleaning. An example of a related customer chain are farmers providing
that are used by its customers to transport produce (i.e. fruit and ve- produce to traders, which are shipping produce to retailers. Those re-
getables), usually from farm to retail. Each RTI is uniquely identified by tailers are distributing the produce within the RTIs to their points of
a Global Returnable Asset Identifier (GRAI) number, which is re- sale (e.g. supermarket) and collect empty RTIs for being able to return
presented by a decimal number, a barcode and a QR-code on the RTI. them to a depot.
By equipping an amount of RTIs with IoT devices, the objective is to Therefore, on the operations execution layer, the pool operator is
turn passive boxes into active things. This shall facilitate RTI tracking taking care for a timely processing and shipment of customer orders. At
and tracing as well as an optimal usage and free circulation of RTIs. the same time, data is gathered to facilitate the operational preparation
This shall also help to guarantee a proper operation of the overall open and load balancing in the different depots.

20
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 14. Domain model view of the use case ‘Intelligent Fruit Logistics’.

The specific tasks are initiated on the production control layer, to between depots and RTI end-users. Each RTI is a unique and autono-
realise the cleaning process itself as well as to organize the shipment in mous object. They will communicate via a long range low bandwidth
between depots as well as to the customers, while this includes different communication protocol. At the current moment, Sigfox was selected,
interactions with customers as well as logistic service providers. At the due to its regional availability. The Sigfox service shall be used via a
same time, the equipment is operated for gathering all the required subscribe/call-back mechanism to regularly gather data sent by RTIs.
data. The IoT Platform will be installed on an external application server to
The physical object layer is presenting the circular process in rela- gather data as well as to facilitate the analysis of acquired position data,
tion to the RTI usage (i.e. from depot storage, over usage up to the providing customized reports. The specific interfaces to the RTI ex-
reception and cleaning of used RTI in the depots) as well as potential ception event app need to be agreed, while it will operate its own da-
exceptional situations that might cause issues and need to be handled. tabase to facilitate the analysis. The location and exception manage-
The business process hierarchy model of the use case ‘Intelligent ment will be realised on an application server, also facilitating the
Fruit Logistics’ is presented in Fig. 15. integrated usage of mobile apps, usually running on Android devices.
In a later phase, it could be foreseen to offer an EPCIS interface and
5.4.3. IoT layer view additional services to enable end-users to access event data that is re-
In the device layer, a prototype of the IoT device mounted on the levant for a specific purpose in their business processes. The CoatRack
RTI will include a module for GPS positioning. In a later version of the module, developed in the scope of IoF2020, could be used as infra-
device, additional capabilities/sensors could possibly be added. A structure to make these interfaces/services available to customers, fa-
Sigfox module will be included in the IoT device prototype, enabling it cilitating access control.
to directly interact with the communication network. The deployment model of the use case ‘Intelligent Fruit Logistics’ is
At a later point in time, it will be decided which sensors are finally depicted in Fig. 17.
required or how to possibly modularize the IoT device, enabling a later
selection of which data is required. This is also the base for making a
cost-benefit analysis as well as to balance battery capacity with re- 5.4.5. Information model view
quired energy for operational usage. Main elements of the information model are the unique identifica-
On the network layer, the Sigfox communication network will be tion of orders, pallets and RTIs as well as the geographical information
used for communication between the IoT device and the Sigfox cloud, that is required to identify the position of RTIs. The position is re-
while the Data Aggregation/Storage module in the EPS cloud will presented by geo-locations, geo-fences as well as places, while the latter
provide a call-back interface to get RTI position information from represents the position in relation to a stakeholder that is currently
Sigfox via the Internet. using, storing or handling the RTI (e.g., depot, farm, warehouse, retail
The service support and application support layer comprises ex- location). Relevant for the application will also be information about
ternal services to get data about positions/places and EPS services to places outside of RTI handlers’ sites, where RTIs sometimes stay for a
provide data to customers. The application layer comprises all appli- longer time. This is especially important when aiming at the provision
cations to be used by the end-users. of added-value services for being able to authorise the provision of
The IoT layer view of this use case is presented in Fig. 16. information.
The information model of the use case ‘Intelligent Fruit Logistics’ is
presented in Fig. 18.
5.4.4. Deployment view
The IoT devices are mounted on RTI’s that will freely circulate

21
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 15. Business process hierarchy view of the use case ‘Intelligent Fruit Logistics’.

5.4.6. Interoperability endpoints view viewpoints. For this reason, the framework combined viewpoints from
In Appendix A the interoperability endpoints of the Use case ‘In- different frameworks that together: (i) support a seamless translation of
telligent Fruit Logistics’ are listed. They are specifically related to the business design to detailed information engineering models, (ii) vi-
RTI and Sigfox usage as well as in relation to the event messaging with sualize how objects are sensed and controlled by IoT technologies, (iii)
the IoT platform and related systems to initiate actions in the business support the interoperability and reuse of system components and (iv)
processes. provide insight in the essence of the use case systems in a consistent,
concise but also simple way, not overcharging the use case owners.
Subsequently a guideline, i.e. a general method, for the application of
6. Discussion
these viewpoints has been introduced.
By using the guideline, the framework is applied to in total 19 use
This paper has developed an architecture framework for modelling
cases that reflect the diversity of the agri-food domain, including dif-
IoT-based systems in the agriculture and food domain. It was found that
ferent sub sectors, conventional and organic farming, early adopters
related existing frameworks either lack viewpoints for modelling the
and early majority farmers, and different supply chain roles, including
IoT dimension or have a too technical focus excluding business

Fig. 16. IoT layer view of the use case ‘Intelligent Fruit Logistics’.

22
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Fig. 17. Deployment view of the use case ‘Intelligent Fruit Logistics’.

farming, processing, logistics and consumption. It turned out that a systems. Such systems not only include technical capabilities for sen-
major advantage of the framework is that it helps to model, in a timely, sing and actuation, but also support the usage of operational sensing
punctual and coherent way, the architecture of IoT-based systems of data in the planning and control of business processes. Existing generic
this diverse set of use cases. Moreover, it serves as a common language frameworks however miss viewpoints for modelling IoT capabilities,
for aligning the system architectures and enabling the reuse of archi- while IoT-specific frameworks focus on technical IoT aspects, but lack
tectural knowledge among multiple autonomous IoT systems in agri- especially business viewpoints. Our framework combines the strengths
culture and food. of both worlds since it includes both business and technical viewpoints.
A main theoretical novelty of the framework is that it combines Furthermore, the framework goes beyond the selection of view-
viewpoints of several generic software architecture frameworks and points from existing frameworks, but also adapted viewpoints for the
specific IoT frameworks in order to support the modelling of IoT-based making it appropriate for the purpose of the research. At this, we found

Fig. 18. Information model view of the use case ‘Intelligent Fruit Logistics’.

23
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

the industrial ISA95 reference architecture very beneficial. Especially research is needed to abstract reference architectures from the use case-
the classification of control layers based on time horizon is not only specific architectures.
important for industrial automation, but also for IoT-based farming Second, as stated before, our framework focuses on a limited set of
systems. However, this perspective is lacking in existing IoT archi- key viewpoints for the purpose of the present research. We expect that
tecture frameworks. For this reason, we translated the industrial control additional viewpoints will be needed to support the complete software
layers (i.e. ERP, MES, SCADA and PLC) into our business process lifecycle. In case other viewpoints are needed, they can be borrowed
hierarchy viewpoint. Moreover, we have added a layer for physical from existing architecture frameworks or novel viewpoints can be
objects and transformations, as well as the object control relations added. Hereby it should be noted that a new viewpoint should be
(sense or actuate) with the production control layer, in order to ex- consistently integrated in the current architecture framework to ensure
plicitly address the ‘things’-dimension of IoT. As a result of these that it will remain a coherent set of viewpoints for the defined scope
changes, our framework is appropriate for modelling complete IoT- and goals, that is, an architecture modelling approach for the agri-food
based systems, including monitoring, decision making, planning and domain.
execution control. Finally, in the introduction it was argued that IoT-based systems
Another important scientific contribution is the application of our should function as interoperable but autonomous nodes within a system
framework to the agri-food domain in a large-scale multiple-case study. of systems. We envision that our framework could serve as a common
As such, the paper provides unique and in-depth descriptive knowledge language for aligning the individual architectures and enabling the
of a broad and diverse set of IoT-based systems for smart farming and reuse of architectural knowledge within a system of IoT-based systems.
food supply chains. Also other sectors can gain from our framework and However, we did not yet explicitly address the system of systems ap-
learn from how it is applied in agri-food. They can use it as a basis to proach in our research. It should be further researched how architecture
develop a reference architecture for their own domain or they can adopt frameworks and reference architectures can effectively enhance a
specific viewpoints to complement existing sector-specific archi- system of IoT-based systems in the agricultural and food domain.
tectures. For example, to the best of our knowledge many IoT reference
architectures for Smart Cities focus on technical aspects and could use 7. Conclusion
our framework to strengthen its business views.
Considering the current literature on architecture viewpoints the This paper has provided an architecture framework consisting of a
question could raise whether other viewpoints could have been in- coherent set of viewpoints for modelling IoT-based systems in the agri-
troduced and are needed in the framework. Obviously, the framework food domain. In addition, it developed a guideline, i.e. a general
has been derived from a real practical setting in which both the selec- method, for applying the architecture framework. The framework has
tion and the specific implementation of viewpoints have been shaped been applied and validated by 19 use cases within the large-scale in-
by practical constraints. An important requirement was that the view- dustrial context of the European IoF2020 project. The framework has
points must provide insight in the essence of use case systems in a been directly used by practitioners while it has elaborated on the cur-
consistent, concise but also simple way, not overcharging the use case rent state of the art on architecture modelling within the context of IoT.
owners. For this reason a limited set of key viewpoints was identified From this perspective both the architecture framework and the ex-
that provides just enough representation power to model the essence of periences from this large scale project in architecting IoT-based systems
the use case systems. As such, the research is an illustration of the trade- can be considered as unique. The architecture framework with its set of
off between complexity of an architecture framework and its usefulness viewpoints aims to support communication among stakeholders, to
for a particular practical objective. A drawback of this approach is that guide design decisions and to evaluate designed architectures. Within
the framework might be not sufficient for other purposes. For example, all cases considered in our study, we could indeed observe a practical
we expect that for software programming the framework is still too need and necessity of a proper architecture framework. The set of ar-
generic and it is also lacks viewpoints for modelling the (commercial) chitecture viewpoints, together with the method, directly supported the
business model of an IoT system. development of IoT systems for the corresponding case studies. Besides
In our future work, we intend to apply the framework to other agri- of the end-results, that is, the architecture views, we can state that also
food cases, to further enrich it with more detailed architectural mod- the process of documenting the architecture helped to understand the
elling knowledge and to extend its scope. More specifically, three systems, to make explicit and discuss the design decisions, to evaluate
challenges are addressed. the fitness of the architectures for stakeholder needs, and subsequently
First, the present research has designed and applied an architecture to guide the development of the IoT systems.
framework and consequently it is limited to architecture viewpoints. It
has not yet developed reference architectures, i.e. concrete archi- Acknowledgements
tectures that formalise recommended practices (i.e. standardized
models) for a certain domain. Such a reference architecture can be an This work was supported by the European Union’s Horizon 2020
application of our framework, not for a particular use case, but for a research and innovation programme under grant agreement no.
class of IoT-based systems. The broad application of the framework 731884. The authors greatly acknowledge the valuable contributions
provides an excellent basis for such a reference architecture, but future from colleagues of the IoF2020 consortium.

Appendix A. Interoperability endpoint views of the use cases

Interoperability endpoints of the use case ‘Added Value Weeding Data’:

Interface name Exposed by Protocol Notes

Weeding Machine inter- Steketee Weeding ma- WLAN, 3G/4G and manual Interface to get image data of the weeding machine and to control machine setting and task
face chine (SSD) instructions
Harvest Machine inter- Harvest machine csv Interface to get harvest data of the harvesting machine
face
GPS Tractor NMEA GPS interface on the tractor to get position data

24
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

Farm Cloud Data inter- Farm cloud data platform To be specified API to access farm cloud platform for camera and sensor data, machine settings and task
face instructions
Weeder Cloud Data inter- Steketee Cloud data plat- To be specified API to access weeder cloud for maintenance and optimisation of machine settings
face form
Yield prediction interface Yield prediction service To be specified API to access app for yield prediction
WPR

Interoperability endpoints of the use case ‘Pig Farm Management’

Interface name Exposed by Protocol Notes

Water Consumption Se- Water Consumption Sensor GHM Meettechniek Flowmeter MID1-008AP001E with It will probably be a wired sensor
nsor Interface LABO-MID1-008UNS
Feed Consumption Sens- Feed Consumption Sensor to be specified It will probably be a wired sensor
or Interface
Daily Growth Sensor In- Daily Growth Sensor to be specified It will probably be a wired sensor
terface
Climate Control Interfa- Climate Control Monnit Wireless Temperature & Humidity Sensor - It will probably be a wireless sensor
ce Commercial Coin Cell Powered
Other sensors interface to be specified to be specified It will probably be a wired sensor
RFId Reader Interface RFId Reader LLRP (over IP, local) Global EPC Standard
RFID Tag interface RFID Tag UHF or HF (These Standards RFID radio protocols)
Slaughterhouse DB in- Slaughterhouse Local Data Standard SQL End-point (over IP) Only available on local network.
terface Storage
Slaughterhouse Server i- Slaughterhouse Middleware XMPP/Virtus or MQTT/Linksmart Application-level profiles to be further specified during devel-
nterface Component opments
Farm Server interface Farm Server XMPP/Virtus or MQTT/Linksmart + ICE 2 Application-level profiles to be further specified during devel-
opments
Cloud Service DB Interf- Cloud Data Storage XMPP/Virtus or HTTP/Virtus Application-level profiles to be further specified during devel-
ace opments
Data & Context Broker Cloud Service Platform NGSI Connection between Farm Platforms and Porphyrio Platform
through FIWARÉs context Broker

Interoperability endpoints of the use case ‘Intelligent Fruit Logistics’:

Interface name Exposed by Protocol Notes

Sigfox callback interface Sigfox Sigfox HTTP URL call- Service provided by Sigfox to get device information via a callback URL
back
Order/Places and RTI posi- Data Aggregation/Storage to be specified Aggregation of all RTI positions and RTI scans as well as geofences to make them available
tion data Module for diverse systems
IoT Platform IoT Event System to be specified Interface to get exception information (location, place, # of RTIs, customer, flows and
other??)
RTI_TT RTI tracking & tracing To be agreed Interface to provide information about discovered RTIs
Application
Places and Geofences Location/GLN Management EPCIS messages via Provision of all locations of current and potential customers as well as other places
HTTP
RTI Device ID Device Management To be agreed Providing the mapping of IoT device ID to the GRAI of the related RTI
EPCIS events (t.b.d.) EPCIS database? To be agreed EPCIS events about RTI movements/exceptions
RTI GRAI scans Mobile Barcode Reader To be agreed Scan of GRAIs that were acquired in combination with an order, shipment and/or customer
ID
Customer Interface (t.b.d.) EPS customer service To be agreed Provide information about RTI movements/exceptions to EPS customers

References Service. http://ww2.frost.com/news/press-releases/internet-things-

becomecornerstone-excellent-customer-service-finds-frost-sullivan/.
Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Merson, P., Nord, R.,
AIOTI, 2015. Smart Farming and Food Safety Internet of Things Applications – Challenges Stafford, J., 2010. Documenting Software Architectures: Views and Beyond, second
for Large Scale Implementations. Alliance of IoT Innovation WG06, pp. 49. https:// ed. Addison-Wesley.
aioti.eu/wp-content/uploads/2017/03/AIOTIWG06Report2015-Farming-and-Food- Eisenhardt, K.M., 1989. Building theories from case-study research. Acad. Manage. Rev.
Safety.pdf. 14 (4), 532–550.
AIOTI, 2018. High Level Architecture (HLA) Release 2.1. Alliance for Internet of Things Fitzgerald, J., Larsen, P.G., Woodcock, J., 2013. Foundations for model-based engineering
Innovation WG03, pp. 20. https://aioti.eu/wp-content/uploads/2017/03/AIOTI- of systems of systems. In: Fourth International Conference on Complex Systems
WG3-IoT-High-Level-Architecture-Release_2_1.pdf. Design & Management, pp. 1–19.
Atzori, L., Iera, A., Morabito, G., 2010. The Internet of Things: a survey. Comput. Netw. Gubbi, J., Buyya, R., Marusic, S., Palaniswami, M., 2013. Internet of Things (IoT): a vi-
54 (15), 2787–2805. sion, architectural elements, and future directions. Future Gener. Comput. Syst. 29
Benbasat, I., Goldstein, D.K., Mead, M., 1987. The case research stratey in studies of (7), 1645–1660.
information systems. MIS Quart. 11 (3), 369–385. Hevner, A.R., March, S.T., Park, J., Ram, S., 2004. Design science in Information Systems
Cantera, J.M., Issa, J.S., Vlugt, P.v.d., Klaeser, S., Bartram, T., Kassahun, A., Neira, I., research. MIS Quart. 28 (1), 75–105.
Milin, T., 2018. IoF2020 D3.3 Opportunities and Barriers in the Present Regulatory Infso, EPoSS, 2008. Internet of Things in 2020: A roadmap for the future. European
Situation for System Development. https://www.iof2020.eu/deliverables/d3.3- Commission DG Infso & European Technology Platform on Smart Systems
opportunities-and-barriers-in-the-present-regulatory-situation-for-system- Integration, pp. 32.
development-v1.2.pdf. InternetWorldStats, 2015. World Internet Usage and Population Statistics. http://www.
Carrez, F., Bauer, M., Boussard, M., Bui, N., Jardak, C., Loof, J.D., Magerkurth, C., internetworldstats.com/stats.htm.
Meissner, S., Nettsträter, A., Olivereau, A., Thoma, M., Walewski, J.W., Stefa, J., ISA, 2010. ANSI/ISA-95.00.01-2010 (IEC 62264-1 Mod) Enterprise-Control System
Salinas, A., 2013. Internet of Things – Architecture IoT-A, Deliverable D1.5 – Final Integration - Part 1: Models and Terminology.
Architectural Reference Model for the IoT v3.0. European Commission, pp. 482. ISA, 2010. ANSI/ISA-95.00.02-2010 (IEC 62264-2 Mod) Enterprise-Control System
https://iotforum.org/wp-content/uploads/2014/10/D1.5.pdf. Integration - Part 2: Object Model Attributes.
Castaneda, C., 2015. Internet of Things to Become Cornerstone of Excellent Customer

25
C. Verdouw, et al. Computers and Electronics in Agriculture 165 (2019) 104939

ISO/IEC/IEEE, 2009. ISO/IEC 10746-3:2009 Information technology – Open distributed Sarni, W.M., Kaji, J., 2016. From Dirt to Data, the second green revolution and the
processing – Reference model: Architecture. https://www.iso.org/standard/55724. Internet of Things. Deloitte Rev. 18, 4–19.
html. Schoenberger, C.R., 2002. The internet of things. Forbes, issue 3/18. https://www.forbes.
ISO/IEC/IEEE, 2011. ISO/IEC/IEEE 42010:2011 Systems and software engineering – com/forbes/2002/0318/155.html#8167674559d4.
Architecture description. https://www.iso.org/standard/50508.html. Sowa, J.F., Zachman, J.A., 1992. Extending and formalizing the framework for in-
ITU-T, 2016. Recommendation ITU-T Y.2060, IoT Reference Model, Overview of the formation-systems architecture. IBM Syst. J. 31 (3), 590–616.
Internet of Things. Telecommunication Standardization sector of ITU. http://www. Sundmaeker, H., Guillemin, P., Friess, P., Woelfflé, S., 2010. Vision and Challenges for
itu.int/itu-t/recommendations/rec.aspx?rec=Y.2060. Realising the Internet of Things. European Union, Brussels.
Jamshidi, M., 2008. System of Systems Engineering: Innovations for the Twenty-First Sundmaeker, H., Verdouw, C., Wolfert, S., Freire, L.P., 2016. Internet of Food and Farm
Century. Wiley, Hoboken, NJ. 2020. In: Vermesan, O., Friess, Peter (Eds.), Digitising the Industry. River Publishers,
Jayaraman, P.P., Yavari, A., Georgakopoulos, D., Morshed, A., Zaslavsky, A., 2016. pp. 129–150.
Internet of Things platform for smart farming: experiences and lessons learnt. Sensors Talavera, J.M., Tobón, L.E., Gómez, J.A., Culman, M.A., Aranda, J.M., Parra, D.T., Quiroz,
16 (1884), 1–17. L.A., Hoyos, A., Garreta, L.E., 2017. Review of IoT applications in agro-industrial and
Josey, A., 2018. An introduction to the TOGAF® Standard, Version 9.2 Overview The environmental fields. Comput. Electron. Agric. 142, 283–297.
Open Group, pp. 22. Tekinerdogan, B., 2014. Software architecture. In: Gonzalez, T., Díaz-Herrera, J.L. (Eds.),
Kirchhoff, U., Sundmaeker, H., San Martin, F., Wall, B., Campos, J., Xeromerites, S., Computer Science Handbook, second ed. Taylor and Francis.
Terziovski, M., 2004. How to Speed-up the IMSS Related Innovation in Tekinerdogan, B., 2017. Engineering Connected Intelligence: A Socio-Technical
Manufacturing SMEs. International IMS Forum, Como, Italy. Perspective, Inaugural lecture. Wageningen University.
Kortuem, G., Kawsar, F., Fitton, D., Sundramoorthy, V., 2010. Smart objects as building Tomasi, R., Sundmaeker, H., Rizzo, F., Conzon, D., Montanaro, T., Hovest, G.G., Vyas, A.,
blocks for the Internet of things. IEEE Inter. Comput. 14 (1), 44–51. Berg, J., Manoel, F., Campos, R., 2018. The IoF2020 Use Case Architectures and
Kruchten, P., 1995. Architectural blueprints — the “4+1” view model of software ar- Overview of the Related IoT Systems. IoF2020 WP3, pp. 221. https://www.iof2020.
chitecture. IEEE Softw. 12 (6), 42–50. eu/deliverables/d3.2-uc-architectures-v2-final-1.3.pdf.
Kruize, J.W., Wolfert, J., Scholten, H., Verdouw, C.N., Kassahun, A., Beulens, A.J.M., Van Aken, J.E., 2004. Management research based on the paradigm of the design sci-
2016. A reference architecture for Farm Software Ecosystems. Comput. Electron. ences: the quest for field-tested and grounded technological rules. J. Manage. Stud.
Agric. 125, 12–28. 41 (2), 219–246.
Lee, Y.T., 1999. Information modeling: from design to implementation. Second World VDMA, 2019. ISOBUS Data Dictionary according to ISO 11783-11. https://www.isobus.
Manufacturing Congress. net/isobus/.
Maier, M.W., 1998. Architecting Principles for Systems-of-Systems Systems Engineering 1 Verdouw, C., Robbemond, R., Kruize, J.W., 2015. Integration of production control and
(4), pp. 267–284. enterprise management systems in horticulture. In: 7th International Conference on
Manikas, K., Hansen, K.M., 2013. Software ecosystems – a systematic literature review. J. Information and Communication Technologies in Agriculture, Food and Environment
Syst. Softw. 86 (5), 1294–1306. (HAICTA 2015), Kavala, Greece, pp. 124–135.
March, S., Storey, V., 2008. Design science in the information systems discipline: an in- Verdouw, C., Wolfert, S., Tekinerdogan, B., 2016a. Internet of Things in agriculture. CAB
troduction to the special issue on design science research. MIS Quart. 32 (4), Rev. 11 (35), 1–12.
725–730. Verdouw, C.N., Beulens, A.J.M., Wolfert, J., 2014. Towards software mass customization
Nielsen, C.B., Larsen, P.G., Fitzgerald, J., Woodcock, J., Peleska, J., 2015. Systems of for business collaboration. In: Annual SRII Global Conference. IEEE, Silicon Valley,
systems engineering: basic concepts, model-based techniques, and research direc- San Jose, California, USA, pp. 106–115.
tions. ACM Comput. Surv. 48 (2), 1–41. Verdouw, C.N., Wolfert, J., Beulens, A.J.M., Rialland, A., 2016b. Virtualization of food
OMG, 2011. OMG Unified Modeling LanguageTM (OMG UML), Superstructure: Version 2. supply chains with the internet of things. J. Food Eng. 176, 128–136.
4.1. Object Management Group, pp. 732. Verdouw, C.N., Wolfert, J., Beers, G., Sundmaeker, H., Chatzikostas, G., 2017. Fostering
OPC, 2017. Unified Architecture, OPC 10000-1 - Part 1: Overview and Concepts, version business and software ecosystems for large-scale uptake of IoT in food and farming.
1.04. https://opcfoundation.org/developer-tools/specifications-unified-architecture/ In: PA17 - The International Tri-Conference for Precision Agriculture in 2017,
part-1-overview-and-concepts/. Hamilton, pp. 1–7.
Porter, M.E., Heppelmann, J.E., 2014. How smart connected objects are transforming Weyrich, M., Ebert, C., 2016. Reference architectures for the Internet of Things. IEEE
competition. Harvard Bus. Rev. (November), 65–88. Softw. 33 (1), 112–116.
Raymond, K., 1994. Reference model of open distributed processing (RM-ODP): in- Williams, T.J., 1994. The purdue enterprise reference architecture. Comput. Ind. 24
troduction, In: Raymond, K., Armstrong, L. (Eds.), Open Distributed Processing. (2–3), 141–158.
Roussey, C., Soulignac, V., Champomier, J.-C., Abt, V., Chanet, J.-P., 2019. Ontologies in Yin, R.K., 2002. Case Study Research: Design and Methods, third ed. Sage Publications,
Agriculture. https://liris.cnrs.fr/Documents/Liris-4759.pdf. Inc.

26

View publication stats