MODEL AND DESIGN OF DISTRIBUTED EMBEDDED SYSTEMS

____________________________________

A Thesis

Presented to the

Faculty of

California State University, Fullerton

____________________________________

In Partial Fulfillment

of the Requirements for the Degree

Master of Science

in

Computer Engineering
____________________________________

By

Thanga Nirmala Dasamoni

Thesis Committee Approval:

Michael Turi, Department of Computer Engineering, Chair

Kiran George, Department of Computer Engineering
Kenneth Faller, Department of Computer Engineering

Fall, 2016
 ABSTRACT

Many model-based approaches have been suggested to improve and accelerate the

development process of complex distributed embedded systems (DES) from design to

deployment. In this approach, abstract models of the system are created and then

transformed systematically into concrete implementations. Modeling focuses on

commands and information being distributed reliably throughout the system with

minimized latency to maintain acceptable QoS. In this research, an irrigation system is

developed. Model-based development was used to model the architecture and

communication of distributed nodes. However, the complexity of the Bluetooth Low

Energy (BLE) communications used by the irrigation system requires a model with very

high sophistication in the bottom-up modeling approach. A distributed irrigation system

is implemented as a proof of concept using an experimental Bluetooth Low Energy based

network topology and protocol, and the data was observed to verify the correct

operations.

ii
 TABLE OF CONTENTS

ABSTRACT ................................................................................................................... ii

LIST OF TABLES ......................................................................................................... v

LIST OF FIGURES ....................................................................................................... vi

ACKNOWLEDGMENTS ............................................................................................. viii

Chapter
1. INTRODUCTION ................................................................................................ 1

2. MODEL BASED DEVELOPEMENT ................................................................. 4

Modeling Basics ................................................................................................... 4

Modeling Languages: UML and SysML ....................................................... 6
Generation of Low Level Representation in Modeling ................................. 10
Evaluation of Model Based DES .......................................................................... 10
Evaluation Criteria ......................................................................................... 11
Evaluation Process ......................................................................................... 13

3. DESIGN OF A DISTRIBUTED EMBEDDED SYTEM FOR IRRIGATION

CONTROL............................................................................................................ 21

Distributed Embedded Systems ............................................................................ 21

Advantages of DES ........................................................................................ 22
Issues in DES ................................................................................................. 23
DES Models ................................................................................................... 23
Design and Development of Irrigation Controller: Proof of Concept .................. 24
Hardware Architecture .......................................................................................... 25
Soil Moisture Sensor...................................................................................... 27
Temperature and Relative Humidity Sensor .................................................. 28
Software Architecture ........................................................................................... 28
BLE Based Communication Protocol Layer ................................................. 28
The Communication Topology ...................................................................... 41
Spanning Tree Algorithm .............................................................................. 43
Application Layer .......................................................................................... 47
Development of Irrigation Controller ................................................................... 51
Implementation of Spanning Tree Protocol ................................................... 52

iii
 Implementation of Application Layer............................................................ 56
Testing ........................................................................................................... 67

4. CONCLUSION AND FUTURE WORK ............................................................. 59

Conclusion ............................................................................................................ 59
Future Work .......................................................................................................... 59

REFERENCES .............................................................................................................. 61

iv
 LIST OF TABLES

Table Page

1. Required Parameters for Calculating ET ............................................................. 49

2. Crop Water Use Table for Checkbook Method ................................................... 50

3. BLE Advertising PDU Structure ......................................................................... 55

4. Application Advertising PDU Structure .............................................................. 55

5. Application Layer Classes: WeatherSense and ValveController......................... 57

v
 LIST OF FIGURES

Figure Page

1. Metamodeling ..................................................................................................... 5

2. UML diagram types ............................................................................................. 7

3. SysML diagram types .......................................................................................... 9

4. Use Case diagram of the Irrigation Controller. .................................................... 16

5. Pinger and Ponger capsules and their interactions ............................................... 17

6. Pinger state machine ............................................................................................ 18

7. Ponger state machine ........................................................................................... 18

8. Organization of a distributed system ................................................................... 22

9. Hardware architecture of the Irrigation Control system. ..................................... 26

10. Soil moisture sensor output Vs VWC .................................................................. 27

11. BLE protocol stack components and layers for a single mode device ................ 31

12. BLE channel arrangements .................................................................................. 32

13. Advertising and scanning timings ........................................................................ 35

14. BLE over-the-air frame packet ............................................................................ 36

15. BLE topology ....................................................................................................... 38

16. GATT attribute table ............................................................................................ 39

17. Bluetooth piconet topology and Spanning Tree topology ................................... 42

18. BLE API interface................................................................................................ 53

vi
19. Classes used in communication layer .................................................................. 54

vii
 ACKNOWLEDGMENTS

It is with a deep sense of gratitude that I thank Dr. Mike Turi, Department of

Computer Engineering, for his inspiring guidance and constant encouragement

throughout the course of this work. I could not have asked for a better supervisor and a

mentor than Prof. Turi, who was not only my sounding board but also showed infinite

patience by allowing me to pursue my style of research.

My heartfelt thanks is also extended to my thesis committee: Dr. Kiran George

and Dr. Kenneth Faller for their insightful comments and encouragement.

To my mother, my siblings, my husband, my children, and the community I live

in, for their constant support and encouragement, I owe everything.

viii
 1

CHAPTER 1

INTRODUCTION

Designing and building Distributed Embedded Systems (DES) is a challenging

task. These systems are still developed in an ad-hoc manner as the block components and

middleware required for building such applications are hard to find in formally verifiable

and analyzable format [1]. Moreover, the design complexity of these systems increases

tremendously with the need to adapt to the new processes quickly and to develop highly

customizable applications that are mostly heterogeneous in specification and complexity.

Application developers use standards-based QoS enabled component based

middleware such as Common Object Request Broker Architecture (CORBA) to develop

individual components and later compose them in a plug and play manner to realize the

complete system. But this comes with significant challenges [1]: (1) a lack of tools to find

the right set of components to provide desired QoS to an application; (2) the need for

configuring many attributes and parameters of both middleware components and the

application at various stages of development; and (3) the ability to automate the

deployment of components onto heterogeneous target platforms before the application is

run.

On the other hand, embedded systems that make extensive use of digital signal

processing, require a language that supports dataflow model of computation (MoC),

while real-time applications use event-based models. Since these applications have real-
 2

time constraints, the designers must ensure that their software architecture meets their

functional requirements as well as performance requirements. It is difficult to check if the

functional and performance requirements are met just by examining the software

architecture design. In order to add a layer of confidence to their designs and to

significantly improve the quality and productivity of developing complex distributed

embedded systems, executable model-based techniques have been used.

These Model-Driven Development (MDD) techniques resolve the challenges in

the development of distributed embedded system by combining the following: unified

modeling language (UML) or domain-specific modeling languages (DSML) that provide

programming notations to specify application logic and QoS-related requirements;

metamodeling information that helps define the structure of the language to precisely

express key characteristics and constraints of a particular application domain; the model

transformation information that helps automate the process and also ensures the

consistency of implementations by checking the functional and QoS requirements

captured earlier[1]. MDD also increases the level of abstraction hence the design

becomes intuitive and accessible to non-experts in these technologies. To achieve this,

the interface between the components—a hardware and a software unit—should be fully

defined in value domain and in temporal domain [2].

The two architectural concepts that are used in these developments are event

triggered or time triggered. In the event triggered architecture, event messages contain

event information. They are usually queued and consumed by an external control that is

outside the communication system. In time triggered architecture, the state messages with

state information are sent periodically and the control exist within the communication
 3

system autonomously [2]. Some of the analysis techniques used in real-time embedded

systems design include executable simulation modeling [3] and real-time scheduling

approaches such as rate monotonic analysis (RMA) [4].

In this research, modeling and design of a distributed embedded system were

studied. First a brief overview of model based approach is described and then a model

was constructed and compared against a set of criteria. Following that, the detailed

description of both hardware and software architectures of the distributed embedded

system under design is given. This involves designing a prototype for an irrigation

controller that controls the irrigation of a vegetable in making decision as to when and

how much the crops need to irrigated. This DES setup has five nodes and each consists of

one Nordic Semiconductor nRF52 Development Kit(DK) board and with two different

types of sensors and a control output indication to indicate the irrigation related decision.

The final chapter details the conclusion of this research and future work that can be taken

up to make this design more efficient and user friendly.

 4

CHAPTER 2

MODEL BASED DEVELOPEMENT

Model based development is an alternative to document intensive development. It

helps design embedded systems with well-defined structure, well-defined abstraction, and

clear visualization of relationships between the components. It enables productive and

efficient designs. Modeling languages are derived using standard languages to express

structural and functional actors and their key relationships over time. Modeling languages

can be either graphical or textual. Graphical modeling languages use diagram techniques

such as symbols to represent concepts, lines connecting the symbols to represent

relationships, and other graphical notations to represent constraints. Textual modeling

languages use standardized keywords accompanied by parameters to make expressions

that are interpreted by computers. Special consideration should be taken when a modeling

language is developed for a specific domain.

Modeling Basics

As explained earlier, model is an abstraction of a system and it specifies the

system from a certain viewpoint at certain level of abstraction. In textual modeling

languages, data is modelled using metadata that forms a metamodel [5] as shown Figure

1.
 5

Figure 1. Metamodeling.

Generally, program execution operates on data while meta execution operates on

program execution. The metamodeling notations should not only offer facilities to

support primitive concepts such as entity, activity, and goal within the metamodel, but

also should support variable granularity descriptions and a variety of referential

relationships such as defines, denote, mentions and includes. It should also offer support

for modeling multiple, possibly contradictory perspectives.

Traditionally in the graphical approach, functional block modeling approach is

used by the control engineering communities for designing real-time embedded systems.

These are driven by extensive tools, such as Matlab/Simulink from Mathworks. But, with

Object Management Group (OMG)’s creation of the Unified Modeling Language (UML)

[6] in an effort to standardize the process of different object-oriented (OO) design

methodologies, UML has gained in popularity for deriving specification and designing

real-time embedded systems [7]. System Modeling Language(SysML), a dialect of UML,

was specified by members of The International Council on Systems Engineering

(INCOSE) working in conjunction with OMG is also a general-purpose language that is

being used diversely. They help represent the elements and relate them to each other
 6

graphically. The facilities provided by UML has real advantages over traditional

approach in many aspects like model readability, model validation, and model

implementability. Profile is a package that extends the UML in a consistent manner.

Customization of a metamodel is defined in a profile and is specific to a domain, whereas

stereotypes are specific metaclasses. Both UML and SysML have been added with

stereotypes, a UML extension mechanism, and tags, to serve some of the specific needs

in describing the model elements. This serves the need for specificity at the same time

accommodating general cases. For example, a stereotype can be created and given a

unique name for the users outside the system to identify and tag definitions are added to it

for the custom properties related to domain-specific attributes. When a stereotype is

applied to a model element, tag values that describe its characteristics are also added [8].

The following paragraphs describe the diagram structure of the modeling frameworks,

UML and SysML, and how they can be used in constructing a model.

Modeling Languages: UML and SysML

UML and SysML are very similar modeling languages. Both share similar

concepts but SysML uses slightly different terminology that is friendlier to systems

engineers.

UML is used in different phases of embedded system design. The current version

of UML, UML 2.0, supports thirteen different types of diagrams as shown in Figure 2

and are mainly classified under structure diagrams and behavior diagrams. The Class

diagram, Object diagram, Component diagram, Composite Structure diagram, Package

diagram, and Deployment diagram are structure diagrams used to represent the static

structure of the design. The Use Case diagram, Activity diagram, and State Machine
 7

diagram fall under the behavior diagram category. The four interaction diagrams,

Sequence diagram, Communication diagram, Timing diagram, and Interaction Overview

Diagram, show different aspects of interactions.

Figure 2. UML diagram types.

Class model is at the core of object-oriented development and design. Class

diagrams represent the classes of objects that will be used during the system execution,

including relationships between classes, like inheritance, aggregation and composition.

The relationship can be bidirectional or unidirectional, and a multiplicity can be indicated

for a relationship in order to indicate the number of objects that can be linked. Object

diagrams allow the representation of the relationship between instances of object classes.

These diagrams are available since the initial version of UML. The Component diagram

allows one to represent the software components that will be used to build the
 8

system, focusing on the representation of the physical implementation of the application

components that perform and provide the required functionality. The Composite diagram

is proposed in UML 2.0, and shows the internal structure (including parts and connectors)

of a structured classifier or collaboration. The Package diagram describes the

organization of packages and its elements, while the Deployment diagram represents the

necessary environment for the components to execute in.

In the behavior diagram category, a Use Case diagram provides high-level

descriptions of the functionality that is achieved through interaction among systems or

system parts. It also describes the system boundary and the interaction with users and

other systems. While Activity diagram represents the flow of data and control between

activities, State Machine diagram describes the state transitions and actions that a system

or its parts perform in response to events. This diagram also represents the states that an

object may be in and the transitions between those states. An object’s state is determined

by the value of its attributes, and transitions are the result of a method invocation that

causes an important change in the state. Sequence diagram is used in representing the

interaction between the collaborating objects. This diagram is used to model usage

scenarios, the logic of methods, and logic of services by a sequence of method calls or

messages in a natural or logical way. The Communication diagram shows the interaction

by means of relationship between objects and association between the classes required for

exchanging messages. The Timing diagram and the Interaction Overview diagram are

new to UML 2.0. The Timing diagram is used to represent how one or more objects

behave in a given period of time. When the Timing diagram is used to represent one

object then it is similar to the State Machine diagram. The Interaction Overview diagram
 9

is a variant of the Activity diagram, and its focus is on the control flow of the

interactions. Instead of activities, the nodes within the diagram are frames. In UML 2.0,

the concept of frame has been introduced to define a diagram. Frame encapsulates a

diagram and has a name, a type and parameters. Using the names, one diagram can be

nested inside another diagram. The Interaction Overview diagram uses the interaction

frames to depict the type of UML interaction diagram or interaction occurrence frames to

indicate which activity or operation needed to be invoked.

SysML reuses a subset of UML 2.0 and provides extensions that are used mainly

in system engineering designs. There are three categories of diagrams in SysML [9] as

shown in Figure 3. Structural diagrams that help show both logical and structural

elements of the system and their connections and relationships between them--for

example, logical decomposition of a system into subsystems; Behavioral diagrams that

show the dynamic view of the system using state charts, and conditions and events that

cause state to change; cross-cutting diagrams help model relationships between both

structural and behavioral elements and they are not commonly used.

Figure 3. SysML diagram types.

 10

Generation of Low Level Representation in Modeling

After a model is constructed, some of the strategies used to generate the low level

representation of the models are executable models, code-generation models, and

interpretive models. An executable model generates executable code but the executability

of the code depends more on the execution tool that is used than that of the model itself.

Some strategies require a more complete and precise model specification while others

may be able to fill in the gap and execute more incomplete models. The most well-known

family of executable models are the executable UML. Executable UML models make

extensive use of Action Languages to precisely define the behavior of all class methods.

In code-generation models, model-to-text transformation is done using a model compiler

to generate a lower-level representation of the model using existing programming

languages and platforms. Instead, the model interpretation strategy relies on the existence

of a virtual machine’s ability to directly read and run the model. Earlier, many MDD

approaches opted for code-generation strategy but now model interpretation strategy is

being used.

Evaluation of Model Based DES

When a model-based approach is used in the development of embedded systems,

designing a high-level system model is the first step. It requires laying down both

requirements and functional specifications. In the requirements specification, desired

behavior or functionality of the system from the user point of view, quality-of-service

(QoS) requirements such as performance, timing and power usage, and problem domain

structure are specified. Development of formal solution for the above requirements

results in functional specification of the system. Modeling languages such as UML and
 11

SysML help express these requirements and specifications through different type of

diagrams. These high-level models should also reflect the nature of the application

domain. At this point the platform information is added to the model and this helps

translate the high-level model into an executable code. This above process can be

automatic but usually requires interaction from the designer at different degrees. The

executable code is usually of particular language, and the way it was obtained depends on

the specific modeling approach and the MoC used in the process. Further, design

exploration can be done by using the executable code as input for architectural

exploration process to find alternative software solutions that would still fulfill system

requirements.

Evaluation Criteria

First, I wanted to evaluate and compare some of the modeling tools available in

the marketplace to find one suitable for my development. They were compared both

qualitatively and quantitatively. The criteria for comparison is based on the work by

Ardis et al. [10], where a qualitative comparison of several design languages for reactive

systems has been done.

A. Requirements Specification This evaluates the capacity to express and document

user needs and system requirements;

1) Functional requirements: capability to express and document the problem

domain elements of the system that are to be designed with desired

functionalities to implement the desired feature.

2) QoS requirements: capability to express QoS requirements of the system

and/or restrictions.
 12

B. Functional Specification: This evaluates the model for its abstraction level and

expressiveness by describing the problem domain and behavior/functionalities of

a system in a natural and straightforward manner;

1) Applicability: capability of representing system behavior orfunctionality

by using different MoCs according to system’s nature. An MoC details

how components of a given system interact and how they exchange data,

control and notions of time. Some of the commonly used MoCs are:

Discrete Event (DE), Continuous Time (CT) and Finite State Machine

(FSM). The use of these three MoCs have been detailed in [11].

2) Modularity/Hierarchy: capability of dividing a large specification into

independent modules, which in turn could be decomposed into smaller

parts;

3) Breadth of Expressiveness: capability of the modeling language primitives

to describe the specification; This is expressed by three main aspects: (a)

Number of modeling primitives; (b) Number of different modeling

primitives in use; (c) Number of lines of code programmed by the

designer.

C. Domain specificity of a tool: This evaluates the suitability of the tool for the

application domain such as, industrial automation, avionics, automotive for which

it is being designed

D. Verification/Validation: This evaluates if the specification can be verified and

validated before its implementation.

 13

1) Verifiability (qualitative): capability of demonstrating formally that the

specification fulfils the requirements.

2) Validation: Ability to validate the implementation.

E. Implementability: This evaluates if the specification can be easily translated into

implementation that is compatible with the rest of the system:

1) Code generation (qualitative): capability of generating an executable

application from the model.

F. Design space exploration: This evaluates if a model incorporates facilities that can

be used for design space exploration:

1) Synthesis (qualitative): This assesses the capability of synthesizing a

model into hardware or generate a program.

2) System tuning (qualitative): This assesses the capability of adjusting the

generated model by fine tuning the parameters such as performance and

power.

G. Ability to check the models for inconsistencies and completeness.

H. The support offered for Reverse engineering and Roundtrip engineering.

I. Composability of the architecture. Composability is defined as the ability to

maintain a particular property of the subsystem even after integrating it into a

system.

Evaluation Process

Now to evaluate, I selected the following Model-based software from the

marketplace as I have mentioned in my proposal:

 14

1. IBM Rational Rhapsody [12] for System Engineers provides design, development

and test environment for developing real-time distributed systems through

modeling. This supports both Unified Modeling Language (UML) and System

Modeling Language (SysML). But for my evaluation I used the capabilities that

are offered by SysML soley. It is a trial copy that is good for 90 days and can be

used both on different versions of Linux and Windows platforms.

2. Papyrus-rt [13] is an open source project that provides an integrated environment

for editing real-time models cyber-physical systems (CPS), and takes advantage

of the profiles such as UML , SysML, and MARTE. Profiles help include

stereotypes of a particular domain in the existing environment. For my evaluation,

I used the capabilities of UML profile for the purpose of comparison. This can be

used on different versions of Linux and Windows platforms.

3. AF3[14] is a powerful open-source model based tool used in developing

distributed, reactive, embedded software systems from requirements to hardware

specification. It provides advanced feature support such as formal analyses,

synthesis methods, design space exploration, and visualization.

After the initial evaluation, I decided to compare only IBM® Rational Rhapsody

and Papyrus-rt, as AF3 offers domain specific model to cater automotive industry needs.

To evaluate further, I installed IBM® Rational Rhapsody for system engineers in the

windows environment and selected SysML as the modeling language of preference. I also

installed Papyrus-rt in the windows environment with UML as the modeling language of

preference with necessary profiles added.

 15

For designing a prototype for an Irrigation Controller system, I created a

requirement element using a Requirements diagram in Rational Rhapsody. The facilities

that are offered for creating one such diagram to express functional requirements, and the

ability to extend them with stereotypes and tags for non-functional requirements such as

QoS requirements and safety requirements such as reliability, dependability, security,

maintainability to express the constraint in the implementation, were quite useful. The

Verify Requirement Relation was also constructed in connecting to a particular test case

to validate the requirement.

The test cases can even be represented in number of different ways in Sequence

diagram and this helps in tracing the requirement for which test cases are written through

a verify relationship. The refine requirement relation can tell how a model element such

as a use case can be used to further refine a requirement. Another important requirement

relation is namespace containment. When a complex requirement is broken down into

smaller units of granularity, containment is important—the child requirements are

contained by the parent during the process of decomposition. This fine granularity is an

important feature that helps refine and validate requirements easily. These features

validate and verify the requirements and also help understand the requirements well to

remove of any ambiguity and to generate sub-requirements and derived requirements.

However, in Papyrus-rt, Requirements specification is expressed using the most

known diagram type, Use Case diagram. I created one as shown in Figure 4. This details

the expectations of the system from a user perspective and hence it links the requirements

and its interaction with the real-world. It also details the specific actions and capabilities

of the system and the valuable results that could be achieved for actors or stakeholder of
 16

the system. These are aspects of a Use Case diagram that are useful in traceability and

impact analysis.

Figure 4. Use Case diagram of the Irrigation Controller.

As far as the physical properties and constraints of the system are concerned, they

are not captured in traditional Use Case diagram. This leaves with some QoS

specification not being satisfied. However, my research suggests that Requirement

Management Framework (RMF) [15] can be coupled with Papyrus-rt and can be used for

textual requirements and other structured requirement models.

To evaluate the functional specifications criteria, I intended to analyse the

behavior of this system under design by representing them in behavioral diagrams such as

Activity diagram, Sequence diagram, and State Machine diagrams of SysML in Rational

Rhapsody and UML in Papyrus-rt. However, I could only evaluate the behavioral criteria
 17

of the ping-pong model I created in Papyrus-rt. To make use of the real-time features in

the ping-pong model, profiles such as UML real time profile, UML-RT state machine

profile, and UML-RT C++ property set profiles were added. The UML-RT runtime

services and UML-RT runtime library were also added for code generation.

In this model, a ping pong ball is the message that is exchanged between the

entities and the players are “Pinger” and “Ponger.” The protocol is governed by UML-RT

and it defines how the messages are sent and received between the nodal elements,

considered here as capsules as shown in Figure 5. The messages can be incoming,

outgoing, or both. The outgoing protocol message is called “ping” and the incoming

protocol message is called “pong.”

Figure 5. Pinger and Ponger Capsules and their interactions.

The “Pinger" action as shown in Figure 6 happens each time the "Playing" state is

entered. Whether transitioning into the "Playing" state from the "initial" state or, because

of the "OnPong" transition, the player either starts the game or keeps on playing, as per
 18

our requirements. This action also sends a "ping" message to the other player, represented

by the Ponger capsule.

Figure 6. Pinger state machine.

The “Ponger” state machine as in Figure 7 consists of only one state called

"Playing," that triggers a self-transition on receiving the "ping" message on the "ponger"

port from “Pinger.” In this case, "Ponger" will not initialize the game and the action here

is defined fully as part of an "onPing" transition and hence no entry action.

Figure 7. Ponger State Machine.

The behavioral abstraction is achieved here through State Machine diagram in

Rational Rhapsody and Papyrus-rt. The above example has demonstrated that clearly. In

addition, Rational Rhapsody has an extra feature in Activity Diagram that helps control
 19

the execution of an activity by disabling it. But, to stop a behavior without requiring it to

run until it is terminated externally, control operators--behaviors that produce an output—

can be used.

With this modeling background, the model for the system under design could

have been generated if a simple communication protocol as experimented above could be

used. However, my effort to extend the above facilities to the Irrigation controller design

was unsuccessful, as the complexities involved in handling all the BLE events of

Bluetooth Low Energy stack and the API calls of the SDK into communication and

application layer of the design that needed complex interactions proved difficult in this

bottom-up approach. With very little support available for this open source software, a

successful model could not be generated.

But, as far as the applicability of the model is concerned, MoC decides the

behavior of the model [15]. Here, both in Papyrus-rt and Rational Rhapsody, sufficiently

expressive MoCs with strong formal properties have been combined seamlessly to enable

systematic validation of designs and correct-by-construction synthesis of

implementations. This was observed in the C++ code generated by the Ping pong model.

As far as modularity/hierarchy is concerned, in Rational Rhapsody, SysML uses

Block Definition Diagram and Internal Block Diagram to describe the structure of an

element or a system with blocks, and their characteristics, properties, operations,

constraints and allocations. With the introduction of the concept of assembly in SysML, a

stereotyped class, a system is considered as a structure of interconnected parts. An

assembly provides a domain neutral modeling element that can be used to represent the

structure of any kind of system, regardless of the nature of its components. In composite
 20

structure diagrams of SysML, the parts of a system and their interconnections support

information flows between components. This feature is a more abstract form of

deployment allocation concept of UML. In UML, use of communication diagram

requires more domain specific information.

When it comes to domain specificity, both Rational Rhapsody and Papyrus-rt

provide many profile extensions and stereotype accommodations that help find suitable

features necessary for the application domain for which the system is to be designed.

For Verification/Validation, some degree of semantics for models is a prerequisite

for verification. The verification of behavior models in Papyrus-rt, and consequently

Rational Rhapsody, is done by focusing on State Machine Diagrams, Sequence Diagrams

and Activity Diagrams; nonetheless, a way to check the correctness of behavioral

representations is still not agreed. Rational Rhapsody supports traceability by linking

design elements to other designs and lifecycle artifacts such as architecture management,

change management and quality management through Open Services for Lifecycle

Collaboration (OSLC) that help plan, design, and document the system under

development.

As far as reverse engineering and roundtrip engineering support is concerned,

Rational Rhapsody provides this in C, C++, or Java, whereas Papyrus-rt does not provide

these facilities; it provides only code generation. Though, the model for the intended

system cannot be generated because of the reasons specified earlier, the evaluation of the

modeling software with the ping-pong model has provided knowledge and viewpoints

that helped design the irrigation system in this research.

 21

CHAPTER 3

DESIGN OF A DISTRIBUTED EMBEDDED SYTEM

FOR IRRIGATION CONTROL

A Distributed Embedded System (DES) is a computer system in which the

information processing is distributed over several intelligent units called nodes to achieve

a common goal. These individual nodes that form the architecture of the system have

dedicated hardware and software that help processes the information. The software

architecture describes how the functionality of an application is distributed over a number

of logical components and how these components are distributed across processors. The

communication between the nodes are generally through one or more networks, either

wired or wireless. In this chapter, DES is further discussed in detail and design of one

such system is also discussed.

Distributed Embedded Systems

Though DES system might appear to the user as one single coherent system, it is

in fact a complex multi-unit system. Some of the salient features of a distributed system

are resource sharing, concurrency, scalability, fault tolerance, and transparency. Figure 8

describes how a distributed system with three machines is organized in the middleware

layer.
 22

Figure 8. Organization of a distributed system.

The nodes in the distributed embedded system comprise of microcontroller based

hardware, application software that resides in flash memory, and real-time operating

system(RTOS) that resides in the ROM help supervise the application software and

distribute the system resources among the tasks by scheduling them according to their

priorities and timing constraints. The scheduling technique used in RTOS is either cyclic

time-table based or static or dynamic task priorities based. In a real-time system like this,

the stimuli are responded within the time limit. In addition to this, protocols are

implemented for communicating between the nodes and managing the shared hardware

and software resources which can be configured in many topologies.

Advantages of DES

With DES, the data processing is done closer to the source in the respective

nodes. Potential advantages that result from this are improved dependability with error

containment within the node, enhanced availability and reliability with dispersed

information processing and by exploiting redundancy, better composability with the

system constructed by integrating nodal subsystems, better scalability with the ease of
 23

adding new nodes for new or replicated functionality, facility for growth with the

enhancement in the system at the node level and good maintainability with the ease of

replacing node due to its inherent modularity. The need to segregate and

compartmentalize to accommodate Original Equipment Manufacturer (OEM) and

suppliers involved in the development process may dictate the need to have a distributed

system. At the hardware level, power, memory, and bandwidth requirements may

demand the need for a distributed system as well.

Issues in DES

Though there are many advantages in distribution, efficiency problems that could

arise due to communication delays caused by heavy communication protocols should be

taken into account while designing one such system. Due to its inherent openness, they

are prone to security threats and failures. Some of the other issues identified in the

analysis done in this work [16] are identifying and naming nodes in the system for further

access, managing the resources effectively, synchronization of nodes, the difficulty in

testing and debugging during development and deployment, and heterogeneity of the

system. Some of the QoS issues such as performance, availability and reliability may also

be affected due to the allocation of processes to different processors in the system and the

distribution of resources across the system.

DES Models

In order to master the complexity of distributed systems, it is imperative that they are

properly organized for the design choices to be captured in one single model. Usually,

DES models can be categorized into three different types:

 24

1. Physical models that define the hardware composition of the system. The system

consists of computers, sensors, electromechanical devices, and their

interconnecting network.

2. Architecture models that define the roles played by the components of the system-

-the way responsibilities are distributed among them, and how they are deployed.

Peer to peer and client-server models come under this category.

3. Fundamental models that define the properties such as time that are common to

architecture models. This is further divided into interaction models, failure

models, and security models. Interaction model deals with issues related to the

processes such as timings of events, performance, and messages, coordination

(synchronization and ordering) and maintenance of global time. Synchronous

systems and asynchronous systems are the two variants of this model. Failure

model deals with failures that can occur during the processes and in the

communication channels. Security model defines and classifies security threat that

can occur in the system for it be resisted.

A separate classification of the DES can be based on the type of processors that

are part of the system. In homogeneous system, all processors are of the same type

whereas heterogeneous system has processors of different types.

Design and Development of Irrigation Controller: Proof of Concept

Irrigation is a method by which water is supplied to the crops in a controlled

manner. It has been around from the time humans have been cultivating plants to satisfy

their food needs. Though initial form of irrigation was to haul buckets of water and pour

on the plants, the present farm practices demand more efficient and mechanized forms of
 25

irrigation. Irrigation is necessary in the United States to supplement the water needs of

the crops as most farming is done in the arid regions where rainwater alone cannot

sustain the crop growth. Here, in an effort to find a solution to irrigate a vegetable farm

automatically, based on demand, and most importantly, to improve the water use

efficiency in a conscious way to conserve water and energy and to reduce nutrient

leaching, I am designing an Irrigation Controller. The system will use drip irrigation as

the mode of delivering water. The hardware architecture consists of sensor nodes and the

software architecture defines the topology and the protocol for the communication among

the nodes and also specify the application software that runs above it to process the data

acquired from the nodes. The sensor readings from the sensor nodes deployed in the farm

are used to make decision as to when and how much to irrigate. The sensor nodes used

here use Bluetooth Low Energy (BLE) to form a network and communicate among

themselves. These sensor nodes read the soil moisture content, atmospheric temperature

and relative humidity from the locations where they are deployed. The collected sensor

data is stored in the node and then on request sent to the valve node where further

processing is done to make irrigation related decision. The sensor nodes can be

configured as pure sensor node or a combination of sensor and valve node by a jumper

setting on the board.

This DES was designed as a proof of concept to implement the ideas learnt from

evaluating the modeling software packages as detailed in the previous chapter.

Hardware Architecture

The hardware architecture of the prototype consists of five nodes. Each node

consists of nRF52 DK board, a soil moisture sensor and a temperature and relative
 26

humidity sensor. Only one node should have the control to activate a solenoid valve in

addition to the sensors. Here, an LED is lit to indicate that the valve has been activated.

The communication among the nodes is purely BLE wireless. The Figure 9 shows the

hardware architecture of the prototype and the following paragraphs explain the

functioning of sensors used in this design.

Figure 9. Hardware architecture of the Irrigation Control system

 27

Soil Moisture Sensor

It is a simple breakout board for measuring the soil moisture and similar

materials. This sensor [16] works on the principle that the water content of the soil is a

simple first-order function of its dielectric permittivity. Therefore, instruments that

measure dielectric permittivity of media can be calibrated to read Volumetric Water

Content (VWC) of the soil which is the unit for soil moisture content. Here, the sensor

probe forms a large capacitor with the surrounding dielectric material, soil, and hence

electromagnetic (EM) field is produced between the positive and negative plates. This

charged capacitance is directly related to dielectric permittivity. The sensor circuitry

converts the charged capacitor into voltage which can be read at the analog output (AO)

of the sensor. This output can be calibrated for soil moisture content for different soil

types using the graph [17] shown in Figure 10. The operating voltage of the sensor is

3.3V-5V. This sensor also has a a digital output (DO) which is 1 when the soil moisture

content exceeds the set threshold voltage using a potentiometer on the board. I used the

AO of this sensor for my development to get a precise value.

.
Figure 10. Soil moisture sensor output vs VWC.
 28

Temperature and Relative Humidity Sensor

This highly accurate digital sensor [18] from Silicon labs, Si7021, has ± 3%

relative humidity measurement accuracy with a range of 0–80% RH, and ± 0.4 °C

temperature accuracy at a range of -10 to +85° C. It uses I2C communication for data

transfer so it works with a wide range of microcontrollers. This sensor is on a breakout

board with a 3.3 V regulator and level shifting so it can be used with 3.3 V or 5 V logic.

To keep the sensor clean, PTFE filter is used. This is connected to the DK board using

VCC, GND, and two data lines for I2C communication that are connected to a built-in

4.7 KΩ pullup resistor. The data values acquired from this are processed in the Sensor

node module.

Software Architecture

The software architecture consists of two layers: communication protocol layer

and application layer. While communication layer defines the topology and the protocol

of the network under design, application layer defines the how an irrigation event is

controlled.

BLE Based Communication Protocol Layer

To design a communication protocol that helps connect and maintain the network

of the BLE nodes in this setup, I decided to combine the network capability offered by

Bluetooth in its specifications and a Spanning Tree topology and come up with an

experimental setup that follows a loose mesh topology. This topology helps connect the

nodes in the farm for the intended purpose of irrigation. Before discussing the working of

this experimental protocol in detail, some of the essential details of the BLE is presented

here from the application point of view.

 29

Bluetooth Low Energy (BLE). With the advent of Wi-Fi connectivity, most

consumer products have local wireless connectivity. Bluetooth is one such wireless

technology, well known to the public as a provider of local connectivity between a phone

and a headset. The newer extension of Bluetooth, Bluetooth Low Energy (BLE) follows

the Bluetooth 4.2 standard and is a low energy protocol intended for energy-constrained

applications such as sensors. It was designed to enable wireless connectivity with small

devices running on a coin cell battery. This low power requirement for the battery

powered applications is attributed to low data transfer requirements—just a few bytes at

very low duty cycles. The Bluetooth Special Interest Group (SIG) manages the IEEE

802.15.1 standard which is used to create such networks. This standard, only defines

PHY/MAC layers, while actual network layers are determined independently by other

network protocols such as ZigBee, 6LoWPAN, RF4CE, and WirelessHART used for

different applications. In addition to this, proprietary wireless protocols such as Z-Wave

in home automation applications and ANT protocol in sports product applications use the

same low networks layers of this standard. BLE devices also come with a smaller price

due to inexpensive silicon, light computational requirements, and reduced memory

footprint.

The reasons for not considering ZigBee in this application are the average power

consumption of a Zigbee node is in the range of 30 mw whereas the requirement for the

nodes in this development should be around the capacity of a coin cell battery, and the

range between the nodes should be within 30 meters with matches specification of BLE.

BLE use-cases have a simple network organization of star-type connectivity. One key

point to be noted is that BLE is incompatible with standard Bluetooth so the nodes do not
 30

interoperate with classical Bluetooth devices. However, a dual-mode device can ensure

interoperability.

Another short range wireless standard, considered a competitor to BLE, is ANT

protocol. The ANT protocol operates within the required power budget, is less complex,

and can be used with nRF52 series boards. But, considering 128-bit AES security offered

by BLE and its availability in almost all cellphones make it a user-friendly interface and

it is considered a plus for the present and future needs of this development.

BLE Protocol Stack. The BLE stack used in this development is S132, a

Bluetooth 4.2 [19] compliant, concurrent multi-link SoftDevice from Nordic

Semiconductor for Central/Peripheral/Broadcaster/Observer roles in BLE applications.

The SoftDevice allows greater flexibility to create more complex network topologies for

BLE applications. This allows the applications to communicate with sensor nodes and

concurrently with BLE devices such as a smartphone or tablet. The salient feature of

S132 is that it supports Over-The-Air Device Firmware Upgrade (OTA-DFU).

The BLE protocol stack [20] or SoftDevice is split into several layers as shown in

Figure 11 to provide different functionalities. The Application is the highest layer and is

responsible for containing the logic, user interface, and data handling of everything

related to use-cases that the application implements. The architecture of an application is

highly dependent on implementation. The stack is further partitioned into Link Controller

(LC) and Host part. The host is abstracted from the Link controller. The LC, the lower

layer of the stack, handles both the Physical Layer (PHY) and Link Layer (LL).
 31

Figure 11. BLE protocol stack components and layers for a single mode device.

The Physical (PHY) Layer is where the actual analog communication circuitry

exists. It helps modulate and demodulate analog signals and transforms them into digital

symbols. BLE operates in ISM, license-free, 2.4 to 2.483-GHz frequency band and uses

frequency-hopping spread-spectrum (FHSS) that employs 40 2-MHz-wide channels to

ensure reliability over longer distances. Among the 40 channels, three are dedicated for

advertising functions [21] only for ease of discovering the devices available in the

vicinity as shown in Figure 12. Advertising channels are allocated in different parts of the

spectrum to provide immunity against interference from 802.11/Wi-Fi. It uses Gaussian

frequency shift keying (GFSK) modulation [19] and the over the air data rate of this

protocol is 1Mbit/s. BLE uses frequency hopping to mitigate the interference in a

 32

crowded band and stays longer on the same channel to make the timing requirements

relaxed. Once discovered in an advertising channel, connection request is sent and initial

connection parameters are exchanged through the same channel. After the discovery and

connection initiation, regular data channels are used for further communication.

Figure 12. BLE channel arrangements.

Other important BLE features include 0-dBm (1 mw) power output, a typical

maximum range of 30 meters, and a latency of 6 ms. It uses a combination of adaptive

frequency-hopping technique to avoid interference, and a 24-bit cyclic redundancy check

(CRC) and a 32-bit message integrity check to improve link reliability. It also uses 128-

bit Advanced Encryption Standard (AES). Though it uses less complex radio than the

Direct Spread Spectrum (DSS) unitized in 802.15.4, it reuses the majority of existing

hardware of Bluetooth radio.

The Link Layer (LL), custom hardware and software, is the part that directly

interfaces with PHY. The bits are transmitted using PHY and Link Layer defines the

packet structure and controls the transmission of them by defining the sequence and

timing of the frames using Link Layer Protocol (LLP). It communicates with other

devices regarding connection parameters and data flow control. It also provides gate

keeping by limiting the exposure and data exchange with other devices by maintaining a
 33

“white list” of allowed devices. This is also the only hard real-time constrained layer of

the whole protocol stack, since it is responsible for complying with all of the timing

requirements defined by the specification. It is therefore usually kept isolated from the

higher layers of the protocol stack by means of a standard interface

The Link Layer defines roles that can be logically grouped into advertiser and

scanner (while not in active connection) and Peripheral and Central (while in a

connection). Advertiser device sends advertising packets while the Scanner device scans

for advertising packets. Central is the device that initiates a connection and manages it

later and Peripheral is the device that accepts a connection request and follows Central’s

timing.

The Host part, or the upper layer of the BLE stack as shown in Figure 12, has

Logical Link Control and an Adaptation Protocol (L2CAP) component that provides data

services to upper layer protocols such as Security Manager Protocol(SMP) and Attribute

protocol (ATT) by protocol multiplexing, and segmenting the data into smaller packets

for the LL, and de-multiplexing and reassembly operations on the other end. The L2CAP

also provides backend interface for Generic Access Profile (GAP) that defines the generic

procedures related to the discovery and connection of other BLE devices.

The security manager (SM) is responsible for device pairing and distribution of

the security key by encrypting data and providing data authentication. The SMP that

governs SM defines how a device’s SM communicates with its counterpart on other

devices. SM also provides additional cryptographic functions for other components of the

stack. It utilizes the standard AES-128-bit crypto engine.

 34

The Generic Access Profile (GAP) is the cornerstone that allows Bluetooth Low

Energy devices to interoperate with each other. It provides a framework that any BLE

implementation must follow to allow devices to discover each other, broadcast data,

establish secure connections, and perform many other fundamental operations in a

standard, universally understood manner.

It provides interface to the application for configuring and enabling different

modes of operation such as advertising and scanning, and to initiate, establish, and

manage connections with other devices. Certain roles are involved in creating and

maintaining a BLE link. A BLE device can either assume a Central role or a Peripheral

role. The device in the Central role always initiates a connection, while the Peripheral is

the device that is connected to. In addition to Central and Peripheral roles, there are

Observer and Broadcaster roles. In the Observer role, connection is not established but

the device either listens only to what is happening on the air and in the Broadcaster role,

the information is only sent.

Advertising and scanning. Advertising is nothing but broadcasting data with the

intent to form a connection. Advertising interval, as shown in Figure BLEAd, is the time

between two consecutive advertising packets. It ranges between 20 ms to 10 s.

Advertising is done sequentially on all the enabled channels. For a Central device to

connect, Peripheral device must advertise. It sends a 31-byte advertising packet with a

time interval, known as the advertising interval ranges between 20 ms and 10.24 s. The

scan interval and scan window parameters define how often and for how long a scanner

device will listen for potential advertising packets. These values impact the power

consumption largely because of their direct relation to the radio circuitry on time. There
 35

are two types of scanning procedures: Passive scanning in which the scanner simply

listens for advertising packets and Active scanning in which the scanner sends a Scan

Request packet and the advertiser responds with a Scan Response packet. The advertising

interval [22], as shown in Figure 13 affects how long it takes to initiate a connection. The

Central must receive an advertising packet before it can send a connection request to

initiate a connection. The Peripheral listens for connection requests for a short while after

sending an advertising packet. When a Central receives an advertising packet, it may

send a request for more advertising data, called a Scan Request, if it is configured as an

Active Scanner. A Peripheral responds to this request by sending a Scan Response packet

that can contain an additional 31 bytes.

Figure 13. Advertising and scanning timings.

The advertising packet contains a user readable name, information about the

device that is sending the packets and flags used for informing if a device is discoverable

or not. A BLE device uses the advertising and data channels to exchange these packets.

The format of an over-the-air packet is specified in Figure 14. A basic BLE over the air
 36

packet consists of 1 preamble byte, 4 access code bytes correlated with RF channel used

for advertising, a Protocol Data Unit(PDU) of 2 to 39 bytes, and 3 bytes of CRC. Hence,

the shortest packet would have 80 bits with transmission time of 80us and the longest

packet will be of 376 bits with the transmission time within 0.3 ms. This number is

important as the BLE single mode devices have a very strict power budget.

Figure 14. BLE over-the-air frame packet.

The PDU for the advertising channel consists of 16-bit header that defines the

type of advertising, 4-byte device address, and up to 37 bytes of information. Also, the

active scanner may request up to 37 bytes of additional information from the advertiser if

the advertising mode allows such an operation. It means that a sizable portion of data can

be received from the advertising device even without establishing a connection. The data

channel PDU consists of a data packet header and up to 37 bytes of payload trailed by 4

bytes of Message Integrity Check (MIC) data if the link layer connection is encrypted.
 37

The data channel payload, depending on the packet header, may carry link layer control

information or actual data for higher-level protocols.

The BLE device address is its identifier and is similar to Ethernet Media Access

Control (MAC) address. This 48-bit (6-byte) number uniquely identifies a device among

peers. The factory-programmed addresses must be registered with the IEEE Registration

Authority and will never change during life of the device whereas random addresses can

either be pre-programmed on the device or dynamically generated at runtime.

Initiating. This is the same procedure as that of scanning phase but Central has an

intention of forming a connection. After listening to the advertising packets, the Central

will send a connection request to the Peripheral as shown in Figure 15.

Connecting. The Central and Peripheral are said to be in a connection from the

first data exchange. The Central requests data from the Peripheral at specifically defined

intervals, connection interval, while in connection. The connection interval must be

between 7.5 ms and 4 s according to the Bluetooth Core Specification. Though this is

decided and applied to the link by Central, Peripheral can send Connection Parameter

Update Requests to the Central. If the Peripheral doesn’t respond to packages from the

Central within the time frame, called connection supervision timeout, the link is

considered lost. To achieve higher data throughput, multiple packets, each contains up to

20 bytes, can be transmitted at each connection interval. To conserve power, a Peripheral

can choose to ignore certain intervals, if it has no data to send. The number of ignored

intervals is called the slave latency. While in a connection, the devices hop through all

the channels in the frequency band, except for the advertising channels which is

completely transparent to the application

 38

Each communication event is started by the Central transmission and it serves as

an anchor point to calculate the time for the next event. During a communication event,

Peripheral and Central [23] alternate sending and receiving packets until either side stops

sending packets. The current event is considered closed and the data exchange is

suspended until the next communication event.

Figure 15. BLE topology.

In Generic Attribute Profile (GATT) of BLE, a new communication method

known as Attribute protocol (ATT) is optimized for small packet sizes. While GAP

defines the general topology of BLE network stack, GATT describes in detail how the

data is transferred once devices have a dedicated connection. The GATT layer gives the

ability to organize the data with much finer-grained control. This enables an attribute

server to expose a set of attributes and their associated values to be discovered, read, and
 39

written by an attribute client of peer devices. The Generic Attribute Profile (GATT)

describes a service framework using ATT for discovering services, and for reading and

writing characteristic values on peer devices. It uses application profiles to interfaces

with the applications. The application profile is a collection attributes and permission that

may be needed for them to be used in the communication.

This is the layer where the data is being exchanged between the devices. To

maintain the interoperability of BLE devices, GATT profiles are used as a bridge

between wireless protocol and the applications to guarantee the integrity not only at the

standardized protocol level, but also at the data representation level. This is done by

sending and receiving data in the same format for an intended functionality so that the

devices having the same profiles can understand each other. These GATT based profiles

as shown in Figure 16 help minimize the size of the data exchange between the devices

and hence keeps average power consumption down. GATT-based profiles are simple and

requires minimal code development. This is particularly important for single mode BLE

where resources are scarce.

Figure 16. GATT attribute table.

BLE also defines two roles for GATT, a GATT Server that is holding the data and

a GATT Client that is accessing the data. These two roles are completely independent of
 40

GAP roles. It is possible for a device to be both a GATT Server and GATT Client

simultaneously.

GATT hierarchy. GATT Server organizes data in what is called an attribute table

and it is the attributes that contain actual data. An attribute has a handle, a Universally

Unique Identifier (UUID), and a value. A handle is the index in the GATT table for the

attribute and is unique for each attribute in a device. The UUID contains information on

the type of data within the attribute, which is key information for understanding the bytes

that are contained in the value of the attribute. There may be many attributes in a GATT

table with the same UUID.

Characteristics. The data used in sending the information through GATT Service

must be mapped to a set of characteristics. Each characteristic is made of at least two

attributes. One declares the characteristic and the other is the value of the characteristic. It

is recommended that the data that changes together be bundled together in one

characteristic.

Descriptor. Any attribute that is not the characteristic value is a descriptor. It

provides more information about a characteristic.

Service. A service is a collection of one or more characteristics that are logically

or functionally related. One such example would be readings of a particular sensor and

related settings for the sensor inputs and outputs. In this way, clearer separation achieves

use-case defined boundaries to promote its reuse across different types of applications.

Profile. A profile is a collection of one or more services that can form a use case

description. A profile document describes the required and optional services that are

available through the profile and their interactions. It also includes GAP and GATT Roles
 41

the devices play during data exchange so it contains information on advertising,

connection intervals and security. The profiles do not have an attribute in the attribute

table as the service implementations are done at the application level, not at the stack

level. It is possible to create new custom services in the application.

UUID. A UUID is a 128-bit globally unique number and is used to identify an

attribute type. The BLE UUID has a common base UUID and a defined attribute 16-bit

UUID that completes the base UUID.

For my application, one GATT service and a custom characteristic were created

to implementing this design.

The Communication Topology

While Bluetooth Special Interest Group (SIG) is working on mesh networking

specification for BLE, here is an experimental algorithm that is based on piconet and

spanning tree protocols. Earlier, Bluetooth networks, commonly known as piconets, use a

master/slave model to send data to the required device in the network. In this model, a

master device coordinates the communication. It can send as well as receive data to any

of its slave devices. Slaves are only allowed to transmit to and receive from their master

and are not allowed to talk to other slaves in the piconet. Figure 17 shows a piconet and

Spanning Tree configurations.

 42

Figure 17. Bluetooth piconet topology and Spanning Tree topology

But, beginning with BLE version 4.1 specifications, any restrictions on role

combinations have been removed. The possible roles are a device can act as a central and

a peripheral at the same time, a central can be connected to multiple peripherals, and a

peripheral can be connected to multiple centrals. The Spanning Tree topology as shown

in Figure Piconet and the protocol are explained below.

Basic Concept. This topology is for connections made with BLE 4.1. This works

with the Nordic nRF51 and nRF52 chipsets in combination with S130/S132 SoftDevices.

Instead of just using the piconet topology, I intended to expand the network by

combining this with spanning tree topology. The neighboring nodes form a network

among themselves in a spanning tree fashion which could loosely represent a mesh. In

this network, the nodes can share information among each other even without direct radio

connection. This is a requirement for the irrigation controller distributed network as the
 43

sensor nodes are spread over a vast area and the nodes in a small area needed to connect

to form a group in order to process the data and take action to perform the irrigation

schedule for that particular area. This uses some of the ideas used in Nordic’s BLE Relay

example [24] design.

Spanning Tree Algorithm

This algorithm constructs a spanning tree with all the reachable nodes. Each node

can be configured to act in one Peripheral connection role and in two Central connection

roles. The nodes can be added to the network by powering them on even after initial route

setup has finished. Self-healing in case of node-failure is accommodated in this setup.

Security of the network is ensured by Network Encryption Key which can be embedded

in the nodes during their deployment in the network through various means to ensure the

validity of the origin of the key.

The Idea. The Idea behind the algorithm is that every node is part of a Group

whose Id is unique in a network. When a node is powered on, it assigns itself a default

Group Id, and Network Id that it would like to belong to, and then alternates between

advertising in a Peripheral role and scanning in a Central role with data containing all the

parameters that are necessary for forming a Spanning Tree network. The main constraint

that has to be exercised here is that the nodes should be from two different Groups can to

form a connection and exchange information. And, a node that is part of a bigger Group

gets to decide if it wants to make connections with other nodes from smaller Groups. If a

node disconnects from a Group voluntarily or because of timeout, Group Size must be

reduced according to the number nodes that were lost. This can only be done by keeping
 44

track of all the nodes that are connected to it directly and the total number of connections

made by all those connected nodes.

Initialization phase. In this phase, all the initialization needed for the network

formation is done.

1. Before a node can join to form a connection, following values are assigned to a

node.

a) The Node ID is the Nordic Semi’s chip ID and is a unique number within the

network.

b) The Network ID of the network it would like to be a part of.

c) The Group ID based on Node ID.

d) Group size is initialized as 1 when the node has no connections.

e) Connected Group size is initialized as 0 for each of the possible connections

from the maximum of 1 Peripheral and 2 Central connections possible.

f) Network encryption key in case of encrypted network.

2. Start advertising. Advertising packet has Node ID, Group ID, Group size and

attributes that other nodes that would like to form a connection can use in their

decision-making process.

Connection selection phase. In this phase, an eligible node is selected to form a

connection.

1. Scan all the advertising channels and collect advertising packets from surrounding

nodes.
 45

2. Buffer advertising packets from all the scanned nodes with a timestamp; discard

older advertising packets (if any) for the nodes just scanned to make sure there is

only one buffered advertising packet for a node.

3. Time-out at a predetermined time to process and form a connection.

Grouping phase. In this phase the connections are formed. The following tasks are

done during route setup.

1. Sort the collected advertising packets by Group Size and find a node with the

highest Group Size.

2. Find all qualified nodes who will take on the peripheral role in a connection using

outward connection.

3. Disqualify the nodes that are in the same Group to avoid redundant connections.

4. Send a Connection Request packet to Best Connection Partner node

Challenge Response phase. The node is authenticated in this phase using a

password that is known to both nodes that are forming a connection. No other packets are

sent until this phase is successful.

1. Send Challenge Response packet.

2. Receive Response packet back from that node and Authenticate

3. If authenticated, inform the change in Group size to all the existing connections in

that group.

Route Maintenance phase. Once the network is formed, advertising packets from

all the nodes have the same Group ID. The following actions are performed to maintain

the route.
 46

1. Send advertising packets less frequently on detecting all advertising packets

received have the same Group ID.

2. Send less frequent scans as well.

3. Go back to advertising with normal frequency if a node notices its connect partner

getting disconnected.

Random advertising phase When a node has exhausted all its connections, it can

switch to non-connectable advertising that is done at random times with very less

repetition. This state helps reduce energy consumption and has random timeout.

Self-healing phase. This phase helps repair the connection that is lost from a

Group. The small Group that is broken off does the following

1. Generate new Group ID for the smaller node with connection loss counter

together with node ID.

2. Send Group Update packet to inform the change Group size.

3. Make the node from which connection is lost enter into connection selection

phase for trying to reconnect.

4. Form alternative routes

Peripheral Connection Procedure. If the only reachable node is already exhausted

its peripheral connection, then this procedure has to be invoked.

1. Send a directed advertising message to the node with which peripheral connection

has to be formed.

2. On receiving the above message, that node may enter in to Grouping Phase and

connect as Central. That node may have to disconnect from the current Group if

necessary.
 47

Application Layer

Application layer in this design is mainly irrigation control algorithm that controls

the irrigation events by taking sensor values and weather data as it inputs. The Irrigation

Control algorithm is explained below in detail.

Irrigation control algorithm. Two aspects of irrigation that need to be determined

using this algorithm are when to irrigate and how much to irrigate.

To decide when to irrigate two methods are used. First, soil-water content is

calculated by estimation using an accounting method called checkbook method. This uses

atmospheric temperature and relative humidity values read from the sensors and other

values available through weather information websites for a particular geographical

location. But, in this setup, as the system do not have the ability to connect to the internet

yet, these values are given to the node when deployed. Once the estimated value is found,

it is further scrutinized by reading the soil moisture sensor values from the neighboring

nodes to get a better idea about the state of the crop stress.

Checkbook method. This pen and paper method is prevalently used in the farm

industry. It is an accounting approach similar to that of the account keeping in the bank,

by taking daily deposits and withdrawals into an account. This helps estimate the soil

moisture balance in the effective root zone of the crop and schedule the irrigation before

the crop is stressed. First, the soil moisture deficit (in the accounting metaphor: the

current checkbook balance) is found, and then daily adjustments are made to that value

by taking into account the crop water use by evapotranspiration of the crop (ETc)

(withdrawals) and rainfall and irrigation (deposits), as described in [30]. This is done

using Crop Water Use table as shown in Table 2. This procedure is repeated in a few
 48

more locations in the field to make the calculations precise, because several things

influence the soil moisture balance including soil type, crop type and growth stage, and

various weather factors [30]. “Since not all of these can be accounted for by using the

checkbook method, it is important to use some type of instrument to measure soil

moisture in the field,” [30, p. 3].

Calculation of evapotranspiration (ET). ET describes two different types of water

loss from the land surface, namely evaporation and transpiration. Through the process of

evaporation, water is converted into water vapor and thus removed from soil structure,

water bodies and wet vegetation. The loss of water through leaf stomata and other parts is

called transpiration. These two processes depend on solar radiation, air temperature,

relative humidity and wind speed. Rate of transpiration depends on many factors such as

crop characteristics which in turn depends on crop type and stage of the crop,

environmental aspects, and cultivation practices.

The reference evapotranspiration rate ETo is calculated using Penman-Monteith

FAO-56 Method [25] using Equation 1.

(1)

Table 1 shows the values required for calculating ETo. The values for the atmospheric

temperature and RH are acquired from the sensors and rest of the values are acquired

from the weather data information available online. Once the reference ETo is calculated

for a particular location, ET for a particular crop, ETc, is found using Equation 2, where
 49

Kc is Crop Coefficient. Kc values for different crops at different stages of growth can be

acquired from Table 12 from [26].

Table 1. Required Parameters for Calculating ET.

Symbol Parameter Unit

Tmaxa A maximum temperature
Tmina A minimum temperature
RHmaxa Maximum relative humidity %
RHmina Minimum relative humidity %
Rs Average solar radiation MJ m-2 d-1
U2 Average wind speed M s-1 at hb m
P Atmospheric pressure (barometric) kPa
Z Site elevation above sea level M
J Julian day —
LAT Latitude Degree
a
values obtained in the period of 24h (0:00:01 AM to 11:59:59 PM).
b
h = height of measurement above ground surface in meters.

To find when to irrigate, Plant Available Water (PAW) is needed for further

calculation. PAW is the amount of water in the soil that is potentially available for plant

uptake. Technically, it is calculated as the amount of soil water at matric potentials above

-1500 kPa. PAW for a particular soil type and can be acquired from Table 1 of the

Decagon manual [27]. Managed Allowed Depletion (MAD) is the maximum amount of

PAW allowed to be removed from the soil before irrigation refill occurs. It is best to

irrigate only when the root zone has reached MAD to conserve water. MAD value of

50% is reasonable overall value. This percentage should be around 30-50% for sensitive

plants.
 50

Further, daily soil moisture balance, the main indicator of the crop stress, is

calculated in this estimation method, by taking into account the rainfall and the amount of

water irrigated that day, if any. Then, the daily moisture balance, in terms of percentage

of PAW is calculated to see if MAD has reached. If it has, it is time to irrigate. These

values, as shown in Table 2, modeled using Table 2 of [28] as reference, are maintained

in a queried database structure in this application.

Table 2. Crop Water Use Table for Checkbook Method

Soil Soil
moisture moisture MAD
balance at ETc Effective Net Balance at reached?
start of day Evapotranspiration Rainfall in Irrigation end of day % of Time to
Date in inches in inches inches in inches in inches PAW irrigate

PAW = 1.44 inches

1 1.44 0.14 1.30 90

2 1.30 0.15 1.15 80

3 1.15 0.16 1.99 69

4 0.99 0.17 0.68 47

5 0.82 0.18 0.04 0.68 47 YES

6 0.68 0.19 0.04 0.72 1.25 83

7 1.25 0.20 0.15 1.20 69

9 1.20 0.21 0.01 1.00 61

9 1.00 0.22 0.88 46

10 0.88 0.22 0.66 80 YES

11 0.66 0.23 0.72 1.15 78

12 1.15 0.23 0.20 1.12 62

13 1.12 0.23 0.89 45

 51

Once the soil moisture balance is found, as a step to fine tune the process, the soil

moisture sensor readings are compared to decide if irrigation is required at this time or

not. Also, weather factors such as impending rain in a day or two is taken into account

before deciding to irrigate.

To determine how much to irrigate the factors such as area that needs to be

irrigated, the desired % PAW to reach after irrigation, and the application efficiency (Ea)

(which is the fraction of the amount of the water that is applied by the irrigation system)

which in turn will be available to the plant for use (usually 80% for drip irrigation).

The combination method implemented in this design is being used farms across

the United States to schedule irrigation to improve water and energy use efficiencies.

This white paper [28] acted as the main reference in designing the above method.

Development of Irrigation Controller

The development setup consists of five nRF52 DK boards from Nordic

Semiconductor. Each board can be connected to three different types of sensors that is

used in this design. I used the Software Development Kit (SDK) offered by Nordic

Semiconductor for this purpose. The boards can be configured to be a sensor node or

valve node depending on the jumper configuration on the board

For selecting the hardware for the nodes, I looked into development kits (DK)

with BLE capability. I evaluated STM32 Nucleo development boards from ST Micro and

nRF5 series SoC DK from Nordic Semiconductor for their hardware capabilities,

communication features and the availability of software development environment. I

decided to go with the nRF52 development kit (DK) [29] board to implement its

Bluetooth low energy wireless communication option, ability to work just with CR2032
 52

Lithium 3v battery without any external power source, low cost, and the ability to use the

Segger Embedded Studio development environment with it.

The nRF52 DK board is a versatile development kit based on ultra-low power

multiprotocol nRF52832 SoC suited for Bluetooth low energy, ANT and other

proprietary 2.4GHz applications. The nRF52832 SoC is built around a 32-bit ARM

Cortex™-M4F CPU with 512kB + 64kB RAM and an embedded 2.4GHz transceiver.

The kit gives access to all I/O and interfaces via connectors and has 4 LEDs and 4

buttons which are user-programmable. An NFC antenna can be connected to the kit to

enable NFC tag functionality. It supports the standard Nordic Software Development

Tool-chain using Keil, Segger, IAR and GCC. Program/Debug option offered for the DK

is Segger J-Link OB.

Implementation of Spanning Tree Protocol

Nordic Semiconductor provides BLE Stack in binary form under the name

SoftDevice. This is linked with the application code and loaded into SoC to implement a

BLE device. It also provides an extensive SDK that defines all the API calls to the

SoftDevice. The SoftDevice API provides accessibility to functions in the SoftDevice to

be called using supervisory software interrupt calls (SVC calls). As shown in Figure 18,

the API also enables the application to register callback functions to get notified of the

important events such as timer events, system events, BLE events, and error events. This

facility that makes use of callback events help implement the Spanning Tree network and

the irrigation controller algorithm.

 53

Figure 18. BLE API interface.

In the implementation, as a first step, Softdevice is initialized and then callbacks

are registered with the SoftDevice for BLE Events such as Timer events and Peer

Manager Events. This is followed by the initialization of GAP advertising structures and

scan structures. A timer is also initialized to periodically to raise events upon which all

the timed functions are done in the application. It also initializes the GATT service with

one custom characteristic with a custom UUID. After all the initializations, the

application alternates between advertising and scanning with predefined interval

generated with the help of Timer event callback. With BLE event call back, it collects

and stores all the Advertising packets that are gathered during Scanning phase and forms

connection to eligible nodes first using its central role connections (2x). Once all the

central role connections are exhausted, it uses its peripheral role connection (1x). This

way, each node can potentially connect to three other nodes with two Central role

connections and one peripheral role connection. The Figure 19 details the BLE events

and the classes used in implementing the communication layer.

 54

Figure 19. Classes used in communication layer

By preventing the nodes from the same Group from connecting to each other,

redundant connections are avoided. On forming a new connection in the network, Group

Size change event is triggered and a connection packet of broadcast events to update all

the other nodes with this change. Every GATT characteristic access in a node triggers

events that are propagated to the Application layer using callbacks registered to monitor

the BLE events. The structure of the advertising PDU used in this design is detailed

below.

Advertising data packet structure. BLE specifications allow a maximum of 31

bytes of data to be sent over advertising packets. The types of data that can be packed in

this is defined in BLE specifications. One such data is BLE_GAP_AD_TYPE_FLAGS,

the flags used for discoverability, and the other one is

BLE_GAP_AD_TYPE_MANUFACTURER_SPECIFIC_DATA, which specifies

 55

manufacturer specific data. I will be using only these two data types in my advertisement

and scan packets to pack all the necessary data needed to implement the Spanning Tree

algorithm.

The way in which different types of data are packed in these 31 bytes, is shown in

Table 3. Each type of data starts with the length of data in a single byte, followed by the

type of data in a single byte and then the data itself, which is of size one less than what is

defined in the length byte, since the length includes the data type, which is one byte.

Table 3. BLE Advertising PDU Structure.

Length - 1 Length - 1
1 Byte 1 Byte 1 Byte 1 Byte
Byte Byte

Length of Type of Length of Type of

Data1 Data2
Data1 Data1 Data2 Data2

Table 4. Application Advertising PDU Structure.

1 Byte 1 Byte 1 Byte 1 Byte 1 Byte 1 Byte 1 Byte

Type Type code

Length of Flags Length of Network Message
code for for Mfr Data
Flags 02h Data Mfr Data 15 ID Type
flags 01h FFh

No. Of free No. Of free GATT

Group
Node ID Group ID Peripher Central Write Ack
Size
Connect Connect Handle

The data packet shown in Table 3 is periodically sent out as Advertising packet

during the Peripheral role phase. Then the node switches over to Central role and scans

and collects advertising report packets from the neighboring nodes. It parses all the

collected advertising packets to find a suitable partner to connect. If a partner is found, it

 56

makes a connection. It advertises less frequently if no connection partner was found

within the predetermined for collecting and parsing the packets.

GATT characteristics implementation. The nodes in the Spanning Tree network

initialize a custom GATT service with a single characteristic enabled with read and write,

and uses it for transferring data between two connected nodes thereby providing a

mechanism for bidirectional data flow.

Data Propagation through Spanning Tree. Each node in the Spanning Tree has the

capability to relay information to a specific node by tagging the data with that particular

node ID as a receiver node ID. If the receiver node ID is set to 0, then the message is

regarded as broadcast message.

Implementation of Application Layer

Application layer of the Irrigation controller sits on top of the Spanning Tree

network layer and is implemented using two classes, namely, WeatherSense Controller

and Valve Controller. WeatherSense Controller class, uses Timer event and, generates

periodic readings of all the sensors that are connected to the node, processes them and

stores them future retrieval. The Valve Controller class also uses Timer events to

generate a periodic GATT characteristic reading of the neighboring nodes that are

configured to work as sensor nodes. Upon receiving the GATT read, sensor nodes return

the previously collected sensor data to the Valve node, where the data is processed using

the Irrigation Control algorithm to make the decision if the valve has to be turned on or

remain off. Figure 20 shows the class structures of the classes used in this

implementation.
 57

Table 5: Application Layer Classes: WeatherSense and ValveController

Class: WeatherSense Controller Class: ValveController

+Humidity
+Temperature +SensorLogData
+SoilMoisture

+GATTSDataRcvdHandl(Data,DataLen)
+TimerEvtHandl(): +GATTSDataRcvdHandl(Data,DataLen)
+GATTSDataWrite(Data) +TimerEvtHandl()
+ReadMoistureSensor() +GATTSDataWrite(Data)
+ReadTemperature() +CheckBookAlgo()
+ReadHumid()

Testing

To integrate the temperature and relative humidity sensor Si7021 with the nodes, I

decided to connect it using the two-wire interface (TWI) to the nRF52 board. I connected

the Si7021’s I2C pins to TWI port 0 of nRF52--SDA to pin 26 and SCL to pin 27, and

3.3V and GND. Using nRF5 SDK Version 11 TWI drivers, sensor read and write

functions help read and write the sensor. I used a logic analyzer to debug the functions

and found out that there is at least a delay of 25 ms needed between writing to a register

address to select it and reading contents of the register. Using the UART interface of the

board and a terminal program running on the PC, humidity and temperature readings

from the sensor were displayed on the computer and hence verified it by changing the

humidity and temperature around the sensor.

For the soil moisture sensor, analog output of the sensor was connected to the

analog input of channel 0 of nRF52 DK. Using SAADC drivers from SDK, read the

analog value of the sensor continuously and output it to through the UART interface and

monitored the values with the terminal program on the PC. Further, I calibrated the
 58

sensor by subjecting the sensor to total dryness, total wet conditions and varying moisture

conditions.

After the sensors were integrated, using the provided nRF SDK examples, I

created a simple BLE peripheral device with one BLE GATT service and one simple

GATTS characteristic. I used the PC tool nRFConnect provided by Nordic

Semiconductor to connect to the BLE device that I programmed and tested writing to the

GATTS characteristic of the BLE device.

To implement the checkbook algorithm, at present, each node is programmed

with the weather parameter values needed for calculating ET using Penman equation [25]

before they are deployed. The calculation of ET using penman equation is also further

simplified in the algorithm by pre-calculating Atmospheric Pressure (P) and

Psychrometric constant (γ) needed and storing them in the node as well. Table 1 used in

this algorithm as implemented as a structure in the application program to keep track of

the values.

With the extensive use of UART log and debug messages, I was able to monitor

and debug various aspects of network formations and connection formations among the

nodes.

Thus a distributed embedded system has been implemented to improve water and

energy use efficiencies as spelled in this white paper [28].

 59

CHAPTER 4

CONCLUSION AND FUTURE WORK

This chapter summarizes the thesis, discusses some of the findings and

limitations, and suggests future work that can be done to improve this system.

Conclusion

In this research, the design part of the research was very successful and it resulted

in a distributed embedded system for irrigation control. I successfully implemented the

hardware setup, experimental communication protocol that allows the sensor nodes to

turn on and off at will, and an irrigation control algorithm that is both energy and water

efficient. However, a working model for this design could not be completed and that can

be attributed to the unique complexity in integrating BLE stack and application layer in a

model, and the lack of support for the open source tools used in this development. Bigger

distributed systems such as aerospace systems and automotive systems use sophisticated

modeling tools with a vast knowledge base. Such a tool would have helped in designing a

working model in this research but the time and budget constraints made it difficult to

achieve the desired results.

Future Work

This working system designed in this research can be made user friendly and

more effective, by adding a gateway node with RESTful API to the existing setup. This

node acts an interface with the real world by acquiring weather data from the internet,
 60

instead of using the pre-programmed data in the nodes. This will not only improve the

accuracy of the system by taking into account the impending weather events such as rain,

but it will also enhance the capabilities of the system with a good user interface.

Interfacing with a cellphone will also make this setup interactive and less error prone.

Addition of high accuracy sensors will improve the reactivity of the system.
 61

REFERENCES

[1] D. C. Schmidt et al., Model-driven development of distributed real-time and

embedded systems. 2005. [Online] Available:
https://www.dre.vanderbilt.edu/~schmidt/PDF/mde-book.pdf

[2] H. Kopetz and T.U. Wien, Time-triggered architecture. 2000. [Online] Available:
http://www.dependability.org/wg10.4/timedepend/05-Kopet.pdf

[3] M. Naughton et al., “Real-time Software Modelling using Statecharts and Timed
Automata Approaches” in Irish Signals and Systems Conference (ISSC) 2006,
Dublin, Ireland, 2006.

[4] M. Klein et al., A Practitioner’s Handbook for Real-Time Analysis: Guide to Rate
Monotonic Analysis for Real-Time Systems, Eighth Printing. Boston,
Massachusetts: Kluwer Academic Publishers, 1993.

[5] J. Mylopoulos, Metamodeling. 2004. [Online]. Available:

http://www.cs.toronto.edu/~jm/2507S/Notes04/Meta.pdf.

[6] G. Booch et al., The Unified Modeling Language User Guide. Addison-Wesley, 1999

[7] B. Douglass. Real-Time UML: Developing Efficient Objects for Embedded Systems.
Addison-Wesley, 1998.

[8] Object Management Group (OMG). UML Profile for Schedulability, Performance,
and Time. 2002. OMG document number: ptc/02-03-02.

[9] S. Sanford Friedenthal, Systems modeling language (SysML) tutorial. 2009. [Online].
Available: http://www.omgsysml.org/INCOSE-OMGSysML-Tutorial-Final-
090901.pdf.

[10] M. Ardis et al., A Framework for Evaluating Specification Methods for Reactive
Systems. April 19,1996.

[11] C. Brooks et al., Heterogeneous Concurrent Modeling and Design in Java (Volume
3: Ptolemy II: Domains) EECS Department, University of California, Berkeley,
2008.

[12] Rational Rhapsody Developer, Visual development and validation of embedded

software. N.d. [Online]. Available: http://www-
03.ibm.com/software/products/en/ratirhap.
 62

[13] Eclipse, Papyrus modeling environment. 2015. [Online]. Available:

https://eclipse.org/papyrus/.

[14] AF3, Seamless model based environment. 2016. [Online]. Available:

http://af3.fortiss.org/.

[15] Eclipse, Requirements management for eclipse. 2014. [Online]. Available:

https://www.eclipse.org/rmf/.

[15] E. A. Lee and A. Sangiovanni-Vincentelli, “A framework for comparing models of

computation,” Computer-Aided Design of Integrated Circuits and Systems, IEEE
Transactions, vol. 17, no. 12, pp. 1217–1229, 1998.

[16] R. W. Watson “Distributed system architecture model,” in Distributed Systems,

Architecture and Implementation, Springer-Verlag, Berlin, 1981.

[16] Decagon Devices, Soil moisture sensors (volumetric water content). 2015. [Online].
Available: http://www.decagon.com/en/soils/volumetric-water-content-sensors/.

[17] C. Campbell, Getting to water content. N.d. [Online]. Available:

http://manuals.decagon.com/Presentations/SoilMoisture201.pdf.

[18] Silicon Labs, I2C Humidity and Temperature Sensor. 2014. [Online]. Available:
https://cdn.sparkfun.com/datasheets/Sensors/Weather/Si7021.pdf.

[19] Bluetooth Sig, Bluetooth core specification. N.d. [Online]. Available:

https://www.bluetooth.com/specifications/bluetooth-core-specification.

[20] Nordic Semiconductor, Bluetooth Low Energy protocol stack. 2015. [Online].
Available:
http://infocenter.nordicsemi.com/index.jsp?topic=/com.nordic.infocenter.s130.sds
/dita/softdevices/s130/ble_protocol_stack/ble_protocol_stack.html.

[21] Microchip. Frequency bands. [Online]. Available:

http://microchip.wikidot.com/wireless:ble-phy-layer.

[22] Nordic Semiconductor, Bluetooth Smart and the Nordic's Softdevices - Part 1 GAP
Advertising. [Online]. Available:
https://devzone.nordicsemi.com/blogs/782/bluetooth-smart-and-the-nordics-
softdevices-part-1/.

[23] Nordic Semiconductor, Topology. [Online]. Available:

https://devzone.nordicsemi.com/tutorials/37/introduction-to-bluetooth-low-
energy-and-ble-devel/.

[24] Nordic Semiconductor, Experimental: BLE relay example. [Online]. Available:

http://infocenter.nordicsemi.com/index.jsp?topic=/com.nordic.infocenter.sdk5.v1
1.0.0/index.html.
 63

[25] L. Zotarelli et al., Step by Step Calculation of the Penman-Monteith

Evapotranspiration (FAO-56 Method). 2010. [Online]. Available:
http://edis.ifas.ufl.edu/pdffiles/ae/ae45900.pdf.

[26] R. G. Allen, “Single crop coefficient (Kc).” In Crop Evapotranspiration - Guidelines

for Computing Crop Water Requirements - FAO Irrigation and Drainage Paper
56 [Online]. Available:
http://www.fao.org/docrep/x0490e/x0490e0b.htm#tabulatedkcvalues.

[27] G. Campbell, Modeling Available Soil Moisture. [Online]. Available:

http://manuals.decagon.com/Application Notes/13401_Modeling Available Soil
Moisture_Print.pdf.

[28] R. Evans, Irrigation scheduling to improve water—and energy—use efficiencies.

1996. [Online]. Available:
https://www.bae.ncsu.edu/programs/extension/evans/ag452-4.html.

[29] Nordic Semiconductor. nRF52 DK Development kit for nRF52832 SoC. N.d.
[Online]. Available: https://www.nordicsemi.com/eng/Products/Bluetooth-low-
energy/nRF52-DK.

[30] H. Werner. Checkbook irrigation scheduling: Irrigation management manual for

South Dakota. 1993. [Online]. Available:
http://pubstorage.sdstate.edu/AgBio_Publications/articles/EC897.pdf