**4. Components of an intelligent farming IoT model**

Before deciding to integrate IoT infrastructure in a given smart farming business model, it is first mandatory to understand the components of the IoT model, because this is the best way to analyze business technology compromises, and better define the requirements of the farming process system. **Figure 1** illustrates the five layers comprising of the smart farming IoT model, each layer is explained in greater detail below.

#### **4.1 Hardware sensor and actuator layer**

This component is located in the bottom layer of the IoT model, it can also be called the data collection and actuation layer, it is considered as the link between the farm physical world and virtual data management and decision making. Functionally, this layer is responsible for sensing capabilities to gather data about the physical farming variables that we want to measure, as well as take actions to change the environment depending on the scenario of the made decision. In this layer, it is recommended to take into account the hardware characteristics, such as size, cost, useful lifetime, reliability, performances, as well as the scenario of use. Physical sensors existed for a long time before even the emergence of IoT devices, the only difference is that their uses have become more sophisticated and they have been used more ubiquitously. The intelligent farming sensors can be manufactured separately or embedded in a specific

**Figure 1.** *The five layers of a smart farming IoT model.*

one board and dedicated to a particular application. The common applications of sensors are to measure temperature, humidity, geographical position, light and sound sense, and much more.

The farming actuators are the translators of the decision to comprehensive and useful energy capable to change the environment from one condition to another, such as guiding an agricultural engine, changing the temperature, making a movement, or enabling/disabling a pump. Operationally speaking, actuators can take three forms pneumatic using air pressure, electrical using electrical energy, and hydraulic based on the power of liquids.

#### **4.2 Software sensor layer**

This layer represents the point of connection between the physical world and the fog-cloud environment, it defines how an object can be smart by doing local analytics, take simple decisions, or control other devices. This layer enables the "softwaredefined hardware infrastructure (SDHI)" or "resource desegregation" [47] concept, which is one of the software-defined environment taxonomy. This concept is of great interest today because it considers physical hardware as a modular component offering more flexibility, agility, automation, and optimization in cloud resource allocation. It provides a new pool of resources-based vision and strategy to efficiently manage available hardware resources to serve multiple applications, this offers more programmability to the infrastructure. It exists in literature more similar concepts like virtualization technique [48, 49], Virtual Network Function (VNF) [50, 51], Software-defined cloud (SDCloud) [52, 53]. This layer is important and critical at the same time. Important because it can be used to minimize the hardware complexity, in other words, instead of being stuck in a fixed hardware architecture which is complex and expensive to build in most of the time, it is possible to design generic hardware like Field Programmable Gate Arrays (FPGA) and program it for various scenarios. And critical because it is the only gate through which the data flows from the physical world to cloud or fog environments, thus the definition of an OS (Operating System) that manages the hardware and the running applications is considered a critical task.

#### **4.3 Communication (network) layer**

In some contexts, this layer is called connectivity, it defines the manner of how data are sent and received between the cloud and the smart devices. The connectivity function has resulted from the combination of two essential elements—protocols and physical hardware used to transmit the signals. In the beginning, RFID is used by the objects to communicate with each other [54] without human intervention. With the emergence of 5G cellular network, a great opportunity is offered to accelerate the IoT systems' development, particularly with the emergence of the MTC (Machine Type Communication) concept, which is also called machine to machine communication, it refers to automated data communications among devices. According to the 3GPP (3rd Generation Partnership Project), it exists two modes of communications in MTC applications—the first mode can occur between an MTC device and a server, and the second can happen between a network of MTC devices [55]. Choosing the communication mode and protocol is a critical task for IoT project owners. This modeling step defines not only the communication with the cloud but also determines how IoT objects communicate with each other. Many communication technologies can be used, for instance, Bluetooth, ZigBee, Wi-Fi, and optical wireless communication

#### *Digital Agriculture and Intelligent Farming Business Using Information and Communication… DOI: http://dx.doi.org/10.5772/intechopen.102400*

for small coverage areas [56, 57]. Sigfox [58] and LoRa, LoRaWan (Long Range Wide Area Network) [59] have been conceived for a wide coverage area. Moreover, 5G is adopted to enhance all traditional mobile communication performances, and respond to multiple connectivity requirements of IoT applications, such as introducing low latency and reliability.

The heterogeneity in communication protocols as well as the complexity of manufacturers' models lead us to think about solutions to ensure the interoperability between IoT platforms and services. Consequently, the IoT middleware concept is immerged and many solutions have been proposed. The propositions can be classified into three big families [60]: Actor-based IoT middleware, cloud-based IoT middleware, and service-based IoT middleware. The first proposition of the actor-based middleware project offers an easy deployment in the distributed environments since it uses actor or agent concept, this middleware plays the role of a bridge between IoT devices and cloud services, it first works presciently to correctly receive data from each IoT device. It next sends the collected data to the cloud using HTTP (Hypertext Transfer Protocol) over TCP/IP protocol. The second family enables the terminology of the cloud of things (CoT) that was introduced by Yuriyama et al. [61], it is an enabler that lets us exploit and manage wireless sensors homogeneously without worrying about the manufacturer's physical complexities. CoT uses cloud capabilities in terms of elasticity of resource provisioning as well as automation, scalability, and cost-effectiveness. Considering this family of IoT middleware, the access of IoT devices to the cloud resources is ensured by the Application Programming Interface (API) of the cloud service provider or through the product vendor's application, as shown in **Figure 2(a)**.

The last family of IoT middlewares refers generally to the open-source platform named OpenIoT project, the objective behind proposing the SaaS (Sensing as-a-Service) solution is to find an adequate way to extract data from virtual cloud sensors without worrying about the physical architecture of the sensor that was behind the collected data. The architecture of the service-based IoT middleware is given in **Figure 2(b)**.

The most common criteria that is recommended to put in mind while choosing the adequate IoT middleware are stability regarding the application, the deployment mode (open source or commercial), the payment model (by the number of device/ messages or using pay as you use mode), the level of security needed (depends on the criticality of the application and the managed data), the hardware compatibility

**Figure 2.** *Cloud-based and service-based IoT middleware.*

(some commercial IoT Middlewares support the integration of some kind of hardware devices like Arduino and Raspberry), the protocol that the application requires (since it exists multiple types of communication protocols, some of them are open and others are proprietary), and either the middleware platform supports the required analytics or not (it depends on the nature of data that the application need which can be in real-time or historic).

#### **4.4 Cloud (analytics) layer**

IoT applications produce periodically what we call big data and send them to the backbone to be managed. The challenge for an IoT project manager is to consider many critical factors to conceive the right cloud architecture. This layer should take into account the essential 5 V of big data from the beginning, the 5 V as mentioned in Ref. [62] includes volume, variety, velocity, veracity, and value. The designed cloud architectures for IoT applications take many models depending on the project manager's perspective.

The model can be SaaS (Software as a Service), the customer in this case, does not have any knowledge about the platform architecture, the client only has a web interface or an API to interact with the provider platform, this model, in general, requires additional fees and the client still stuck in "Vendor lock-in," this means that more complexity and costs will be charged by the client if for any reason, decides to switch to another service provider.

The second model is PaaS (Platform as a Service), the client in this case has multiple choices of software bricks that can be used on-demand to build IoT applications without worrying about server management. This model provides many bricks for IoT solutions such as device management, storage, connectivity with other IoT fleets, collection, and transmission, as well as some machine learning options for decisionmaking support. The advantage of this model is the great ability offered by the vendor to the client to customize the IoT applications based on the offered software catalogs. But unfortunately, this can have some additional hidden costs.

The third kind of model is licensed or on-premise. Here, the vendor only makes support available to the client. The client buys software packages and the license, then installs them in his own managed infrastructure. All the maintenance tasks are under the client's responsibility. The open-source solutions are identical to the licensed model, the only difference is that the software packages are freely available, the solution maintenance is ensured by a community of volunteer developers. In some cases, the maintenance is performed by an enterprise and proposes the solution as a free package, while providing a paid version with other options. The tailor-made feature is another option adopted by many customers, it consists of engaging an external integrator to entirely conceive the IoT solution. In this case, the source code is owned by the application owner, he can use it subsequently to achieve the project evolutivity.

#### **4.5 Application (user) layer**

This layer is the most closer to the customer, it is generally used to ensure usermachine interaction, it defines how data is presented to the end-user depending on the user's requirements. In most cases, this layer is a web-based application. Some users require desktop, mobile, or wearable applications. Practically, the application layer is hosted somewhere in the provider's cloud to ensure the AAA

*Digital Agriculture and Intelligent Farming Business Using Information and Communication… DOI: http://dx.doi.org/10.5772/intechopen.102400*

(Anytime, Anywhere, Application) capability. The most important thing that the IoT solution designer should understand is what the final users attend from the solution, and how this job can be done.
