Model and Design of Distributed Embedded Systems ______

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

Computer Engineering ______

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.

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

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

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

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

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.

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

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.

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

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.

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.

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:

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.

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.

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.

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:

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

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.

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.

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).

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

“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.

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.

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

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

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.

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.

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.

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.

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

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 a Tmax A maximum temperature a Tmin A minimum temperature a RHmax Maximum relative humidity % a RHmin Minimum relative humidity % -2 -1 Rs Average solar radiation MJ m d -1 b U2 Average wind speed M s at h 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.

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

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

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.

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.

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.

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].

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.

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.

[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.

[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