SECURE FRAMEWORK FOR IMPLEMENTING DISTRIBUTED NETWORKED CONTROL SYSTEMS WITH MOBILE OBSERVERS USING HETEROGENEOUS CONTROLLERS BY JAVITT HIGMAR NAHITT PADILLA-FRANCO, B.S., M.S.
A dissertation submitted to the Graduate School in partial fulfillment of the requirements for the degree Doctor of Philosophy, Engineering Specialization in Electrical Engineering
New Mexico State University Las Cruces New Mexico December 2017 (c)2017 by Javitt Higmar Nahitt Padilla-Franco
ProQuest Number: 10759028
All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion.
ProQuest Que ProQuest 10759028 Published by ProQuest LLC(2018). Copyright of the Dissertation is held by the Author. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code. Microform Edition © ProQuest LLC. ProQuest LLC 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106-1346
“Secure Framework for Implementing Distributed Networked Control Systems W ith Mobile Observers Using Heterogeneous Controllers ” a dissertation prepared by Javitt Higmar N ahitt Padilla-Franco in partial fulfillment of the requirements for the degree, Doctor of Philosophy, Engineering, has been approved and accepted by y m e following:
(ftvt
A
I/Kts
Dr )r. Louf-Vicente Reyes Q Dean of the Graduate School
Dr. Nadipuram (Ram) Prasad Chair of the Examining Committee
Date
Committee in charge:
Dr. Nadipuram (Ram) Prasad, Chair Dr. Jeffrey Beasley Dr. Jaime Ramirez-Angulo Dr. Satishkumar J. Ranade
DEDICATION
I dedicate this work to my mother, Lucrecia.
ACKNOWLEDGMENTS
I would like to thank my advisor, Dr. Nadipuram (Ram) Prasad, for giving me the opportunity to work on his Energy Harvesting project, a true life-changing experience. Personally, I would like to thank him for sharing his knowledge which has enriched my study in philosophy. Additionally, I would like to give special thanks to the next professors of the Klipsch School of Electrical and Computer Engineering: Dr. Satish Randade, Charles (Chuck) Boehmer, Dr. Xenxin Liu (Lehigh University), Dr. Paul Furth, Dr. Jaime Ramirez-Angulo, and Dr. Robert Paz (RIP).
IV
VITA
Jan. 21, 1977 Born in Chihuahua, Chihuahua, Mexico 1994-1999
B.S. Computer Systems Engineering Chihuahua’s Technological Institute II. Chihuahua, Mexico
2000-2001
M.S. Electronics Engineering Chihuahua’s Technological Institute. Chihuahua, Mexico
2002-2003
M.S. Computer Engineering University of Texas at El Paso. El Paso, Texas
2002-2003
Assistant Instructor and Research Assistant University of Texas at El Paso. El Paso, Texas
2004-present
Researcher and Professor Autonomous University of Ciudad Juarez. Cd. Juarez, Mexico
2008-2010
M.S. Computer Science New Mexico State University. Las Cruces, New Mexico
2012-2015
Research Assistant and Teaching Assistant New Mexico State University. Las Cruces, New Mexico
2010-2017
Ph.D. Electrical and Computer Engineering New Mexico State University. Las Cruces, New Mexico
PROFESSIONAL AND HONORARY SOCIETIES Institute of Electrical and Electronics Engineers and Association for Computing Machinery
v
PUBLICATIONS - Javitt H.N. Padilla Franco, Jorge Perez et al. Control de altitud de un cuadricoptero utilizando logica difusa. CULCyT/Logica Difusa. 2016. - Sheret Tilvaldyev, Javitt H.N. Padilla Franco et al. Analysis of the aircraft coating innovations, improving aerodinamics parameters and reduciong sking friction. Academic Journal of Science. 2016. - Onofre Amador Morfin Garduno, Javitt H.N. Padilla Franco et al. Diseno de un sistema de control descentralizado de un sistema eolico emulado con un grupo motor CD-Generador CA. Coleccion de reportes tecnicos de investigacion. 2015. - Alejando Monroy Reyes, Javitt H.N. Padilla Franco et al. Sistema de monitoreo remoto con detecion de movimiento basado en vision por computadora. CU LCyT/Sistema de Vision. 2015. - Octavio Rodriguez, Javitt H.N. Padilla Franco et al. Rediseno, fabricacion e integration de un sistema de vision para mediciones. CULCyT/Metrologia. 2015. - Luis Alejandro Berumen Carlos, Javitt H.N. Padilla Franco et al. Diseno de herramienta para la fabricacion de terminales prototipo. CULCyT/Herramientas. 2015. - Jose Barajas, Javitt H.N. Padilla Franco et al. Sustainability Via Energy Har vesting and Scavenging. Journal of International Test and Evaluation Associ ation. 2011. - Rogelio Davila, Javitt H.N. Padilla Franco et a l, Constructive Analysis of Intensional Phenomena in Natural Language. Journal of Engineering Letters of IAENG. 2007. - Alberto Ochoa, Javitt H.N. Padilla Franco et al. Explain a Weblog Community. Advances in soft computing.2007 - Alberto Ochoa, Javitt H.N. Padilla Franco et al. Implementing D ata Mining to Improve a Game Board Based Cultural Algorithms. Advances in soft comput ing. 2007. - Alma Cota, Javitt H. N. Padilla Franco et al. Diseno , Construction y Operation de un Secador Solar de Lodos Generados en Plantas Tratadoras de Aguas. X X X Semana de Energia Solar. 2006.
VI
Javitt H. N. Padilla Franco, Amado Lara, Pedro Marquez. Sistema Descubridor de Conocimiento en Bases de Datos Distribuidas. X X II Congreso Internacional de Ingenieria Electronica “Electro 2001”. 2001. Javitt H. N. Padilla Franco, Amado Lara, Pedro Marquez. Sistema Inteligente para la Ensenanza de las Matematicas. X X II Congreso Internacional de Inge nieria Electronica “Electro 2001”. 2001.
FIELD OF STUDY Major Field: Instrumentation and Intelligent Networked Control Systems
ABSTRACT
SECURE FRAMEWORK FOR IMPLEMENTING DISTRIBUTED NETWORKED CONTROL SYSTEMS WITH MOBILE OBSERVERS USING HETEROGENEOUS CONTROLLERS BY JAVITT HIGMAR NAHITT PADILLA-FRANCO, B.S., M.S.
Doctor of Philosophy, Engineering Specialization in Electrical Engineering New Mexico State University Las Cruces, New Mexico, 2017 Dr. Nadipuram (Ram) Prasad, Chair
In this dissertation, a framework for the development and analysis of low-cost monitoring and control systems for a set of distributed nodes comprising of dissim ilar controllers is presented. The ability to connect multiple disparate processors, is possible due1to the use of a secure minimalistic custom communication proto col. This architecture allows the use of mobile devices to interact with the main
features of the system for monitoring and control. The server is at the core the overall framework, which enables the transparent development of data acquisition, processing and control models using a software interface. These models autom at ically translate to functional systems executed by all microprocessors available to the system. The framework contains software libraries th at allows the integration of neural networks and fuzzy logic th at permit the implementation of intelligent data acquisition and control systems. The random behavior of the underlying communication network is modeled in real-time to automatically compensate for the delays and lost packages in the execution of control actions. The framework enables a mapping of system inputs and outputs to state vari ables. These variables can then be used to form a system model to enable classical control theory analysis, such as controllability, observability and stability test.
ix
C ontents
LIST OF T A B L E S .......................................................................................... LIST OF F I G U R E S ....................................................................................... 1
INTRODUCTION
.................................................................
1.1
Initial D e s i g n ..........................................................................................
1.2
System R equirem ents.............................................................................
1.3
M otivation.................................................................................................
1.4
A n tec ed e n ts............................................................................................. 1.4.1
Sensor Networks
.......................................................................
1.4.2
Instrumentation of Generators, Hydro-machinery and Wa ter Flow M e asu re m e n t.............................................................
1.4.3
Gibson’s M e th o d .......................................................................
1.4.4
Wireless Sensor Networks
1.4.5
Security in Sensor N e tw o rk s....................................................
1.4.6
Sensor Networks for C o n tr o l....................................................
1.4.7
Frameworks for Sensor Networks
1.4.8
Energy Consumption in Sensor N etw orks.............................
1.4.9
Stability of Distributed S y ste m s.............................................
.......................................................
..........................................
1.4.10 Mobile Applications for C o n tr o l............................................. 1.4.11 Distributed Control Systems, Hybrid S y s te m s ...................
1.4.12 Networked Control S y s te m s ....................................................
11
1.4.13 Stability Analysis and Control of NetworkedControl Systems 12 1.4.14 Wireless Networked Control S y s te m s ....................................
13
....................................................................
13
1.5
Problem D e fin itio n ................................................................................
13
1.6
Objective
................................................................................................
14
1.7
H ypothesis................................................................................................
15
1.8
Ju stific a tio n .............................................................................................
15
1.9
Related W o r k ..........................................................................................
15
2
THEORETICAL F R A M E ...................................................................
17
2.1
Sensor N etw orks.......................................................................................
18
2.1.1
Instru m en tation ..........................................................................
19
2.1.1.1
Instrumentation of Energy Harvesters
................
20
2.1.1.2
Flow M easurem ent....................................................
22
2.1.1.3
Signal Conditioning and Sensors
..........................
23
2.1.2
Communication in Sensor N etw orks........................................
29
2.1.3
Wireless Sensor Networks and Mobile C o m p u tin g
32
2.2
Networked Control S y s te m s ................................................................
38
2.3
Intelligent Networked Control S y s te m s ............................................
42
2.4
Mathematical Modeling of Networked Control S y s te m s ................
47
2.5
Distributed Control in Networked Control Systems
51
1.4.15 Intelligent Control
XI
......................
3
DEV ELO PM EN T...................................................................................
54
3.1
System D esign.........................................................................................
56
3.1.1
Use Case D ia g ra m s....................................................................
56
3.1.2
Sequence D ia g ra m s
! . .
60
3.1.3
Class D ia g ra m s ..........................................................................
65
Im p lem en tatio n ......................................................................................
70
3.2.1
S e r v e r ..........................................................................................
71
3.2.2
Mobile Observer A pplication....................................................
83
3.2.3
Control N o d e .............................................................................
88
3.2.3.1
A rd u in o .......................................................................
92
3.2.3.2
Raspberry P i ......................................
95
3.2.3.3
National Instruments H ard w are.............................
98
3.3
Deployment and T e s tin g ......................................................................
102
4
R E S U L T S ................................................................................................
105
4.1
Deployment R esu lts................................................................................
108
5
CONCLUSIONS
...................................................................................
109
5.1
Future W o rk ............................................................................................
Ill
A P P E N D IC E S .................................................................................................
113
A
WATER FLOW M EA SU R EM EN T ...................................................
113
B
INSTRUMENTATION IMPLEMENTATION
...............................
125
C
EXTERNAL SOFTWARE L IB R A R IE S .........................................
134
3.2
xii
D
SYSTEM PERFORMANCE COMPARISON
REFERENCES ..........................................................
List o f Tables
1
Voltage Scale...............................................................................................
130
2
Simulation Results. [-5mm]
148
..................................................................
XIV
List o f Figures
1
10 KW Hydro Generator...........................................................................
2
2
Monitoring of Multiple Generators.........................................................
3
3
Sensor Network Architecture....................................................................
18
4
Knowledge Domain Areas Involved in the Project................................
19
5
Instrumentation Architecture...................................................................
21
6
Sensors with DAQ......................................................................................
23
7
Accelerometer..............................................................................................
24
8
Temperature Signal Conditioning Components....................................
24
9
W heatstone Bridge with Thermistor and Amplifier............................
25
10 Water Proof Pressure Sensor....................................................................
26
11 Hall Effect Sensor.......................................................................................
27
12 Current Sensor............................................................................................
28
13 Resistive Divider for Voltage Measurement...........................................
28
14 Instrumentation GUI.................................................................................
29
15 Communication Sequence.........................................................................
30
16 Communication Protocol..........................................................................
31
17 Distributed Monitoring..............................................................................
33
18 Wireless Sensor Network Implementation.............................................
34
19 Security and Multiple Clients...................................................................
35
i
xv
20
Communication Protocol with User Authentication..........................
36
21
Software Architecture...............................................................................
37
22
Mobile Application Graphical User Interface......................................
38
23
Elephant Butte Irrigation Channel Drop 8..........................................
39
24
Control Nodes with Communication.....................................................
40
25
Mathematical Model Incorporating Real Inputs and Outputs.
. .
41
26
Simple Mathematical Model of a Neuron.............................................
43
I
27
Simple Local Intelligent Control on Node a Based on Artificial Neu ral Networks...............................................................................................
44
28
Fuzzy Sets Representing a Particular Rule..........................................
45
29
Control Node Implementing a Fuzzy Controller.................................
46
30
Discrete and Continuous Elements of a Control Node......................
47
31
Hybrid System...........................................................................................
48
32
Simulation of the Hybrid system of Figure 31....................................
49
33
General Architecture................................................................................
55
34
UML Use Case Diagram for Control Node..........................................
57
35
UML, Use Case Diagram for the M ath Module...................................
58
36
UML Use Case Diagram for the Server................................................
60
37
UML Use Case Diagram for the Mobile Client...................................
61
38
UML, Sequence Diagram for Reading D ata from a Mobile Observer.
62
39
UML Sequence Diagram for Autonomous Control.............................
64
xvi
UML Class Diagram for the Control Node.
66
UML Class Diagram for the Math Package.
67
UML Class Diagram for the Server Package
69
UML Class Diagram for the Client Package.
70
Server Login GUI............................................
71
Server System Preview Login GUI..............
72
Screen Detail of the System Preview GUI.
74
Server D ata Layer Node Selection GUI. . .
76
D ata of Selected Node GUI...........................
77
Link Selection GUI.........................................
78
Network Analysis GUI...................................
79
Control Design GUI........................................
80
Stability Analysis GUI...................................
81
Custom Node Specification GUI..................
82
Login Activity..................................................
84
Application Main Activity.............................
85
Server Access Services Activities.................
86
Activity Node Observation and Control.
.
87
Instrumentation Activities............................
88
Manual Control Outputs.
..........................
89
Generic Control Node Algorithm.................
91
xvii
61
Arduino
93
62
Arduino implementation of Open CACE Protocol. . . .
94
63
Raspberry Pi 3 model B .......................................................
95
64
Raspberry Pi O utput Plate from PiPlates.......................
96
65
Raspberry Pi and Arduino..................................................
97
66
Wifi USB Dongle...................................................................
98
67
Python Implementation of Open CACE Protocol. . . .
99
68
NI USB Devices.....................................................................
100
69
NI CompactRIO....................................................................
101
70
Protocol Header in LabVIEW .............................................
102
71
Header TC P Transmission in LabVIEW..........................
103
72
Final Knowledge Domain Areas Involved in the Project
105
73
Gap Between Models and Implementations.....................
107
74
Contraction Coefficient.........................................................
119
75
Pipeline Cross Section..........................................................
122
76
Schematic Signal Conditioning PCB..................................
126
77
Final PCB for Signal Conditioning....................................
127
78
Linearized Pressure Sensor Response................................
128
79
Linearized Accelerometer Response...................................
129
80
Linearized Voltage Response Nom-High Swing...............
130
81
Linearized Voltage Response Nom-Low Swing................
131
xviii
82
Linearized Current Response..................................................................
132
83
LabVIEW Instrumentation Code...........................................................
133
84
Lighthouses in the East and West Coast..............................................
137
85
Control of Lighthouse Mirror Motor.....................................................
138
86
Simple Distributed Control.....................................................................
140
87
LabVIEW DCAF Configuration............................................................
142
88
DCAF Main Test Module....................... -...............................................
143
89
Mathematical Model of the Lighthouse Problem................................
144
90
Open CACE implementation of the Lighthouse Problem.................
145
91
LabVIEW Simulation of the Lighthouse Motor Distributed Control. 146
92
Open CACE Simulation of the Lighthouse Motor Distributed Control. 147
93
Test Execution Comparison....................................................................
xix
149
1
IN T R O D U C T IO N
Energy storage and electricity production stand out as the fundamental build ing block of today’s digitally oriented world. Coal, gas, solar cells or water turbines must be utilized to generate electrical power. During the spring of 2011 research was conducted by Dr. Nadipuram (Ram) Prasad to harvest energy from water flows. T hat work was funded by the Department of Energy[39] due to its origi nality and novel approach in using carbon composite materials such as Kevlar to fabricate the turbine components. The idea was to construct several low-cost, self-contained generators. An extra feature of these energy harvesters was to provide real-time data on their behavior. The research topic of this dissertation is the result of the author’s work on the instrumentation and control of the hydro generators. Figure l.a shows a diagram of the hydro generator’s modular architecture. Its two main components can be observed: generator housing and discharge elbow. The 10 KW generator resides inside a sealed submarine, which can maintain a water-tight environment. As Figure l.b shows, the submarine is attached to the venturi-shaped housing by the means of two hollow columns. The inside of the columns is designed to hold the instrumentation circuits. Also, the power and interface cables are directed to the exterior using the empty space in the columns. The power cable transm its the generated power to the load, and the interface
(a) M odular Design.
(b) Components.
(c) Impeller.
(d) Final Assembly.
Figure 1: 10 KW Hydro Generator.
cables carries all sensor signals to the monitoring console. Figure l.c shows how the aluminum impeller is mounted inside the turbine. After assembling the turbine on the top, and the discharge elbow on the bottom, the structure stands more than two meters tall, as illustrated in Figure l.d for an scale idea. An advantage of the modular design is the ease of deployment. The modular components can be transported to the installation site and assembled quickly. Also, the additive manufacturing process allows the construction, and installation of custom-made
2
housing suitable for site specific requirements. A team consisting of doctoral, master, and undergraduate students worked diligently under Dr. Prasad’s direction to achieve the system of Figure 1. A group of students worked on the development and integration of the technology required to measure and display the generator’s physical variables such as speed, vibration, temperature, water flow and generated power. One im portant characteristic of the design is the ability to deploy many units to generate additional combined power. Thereifore, the instrumentation must support the connection of multiple generators, see Figure 2. Monitoring and ■: Control : System
Generator
Generator,
Figure 2: Monitoring of Multiple Generators.
1.1
Initial D esign The instrumentation and control of two 10 KW hydropower generators is
a challenging task.
It involves: i) Establishing a communication network, ii)
Ensuring this network is secure, iii) Message coordination between components to achieve a global state, iv) Display measured values to the user, v) Enable the
easy adjustment of control outputs by the user. It is common in a rapid prototyping environment to select National Instru ments (NI) components due to its availability and reliability. However, such a decision makes it a high-cost implementation. The objective is to develop a low cost and reliable instrumentation of the system.
A low-cost structure can be
realized with the use of Arduino and Raspberry Pi micro-controllers. Arduino and Raspberry Pi can interact with different sensors. The instrumen tation was designed to measure water flow passing through the turbine, as well as the voltage and current generated. Those measurements could be used to monitor the system behavior or to control system state variables such as the water inlet gates or the angle position of the impeller. The next step after the selection of the acquisition devices is the communica tion with LabVIEW software. Communication is required to transm it the mea surements from the sensor nodes to the instrumentation Graphical User Interface (GUI) in order to be displayed. The first implementation of this GUI was pro grammed in the NI environment because of its multiple visualizing components. LabVIEW works flawlessly with NI devices, but for Arduino, and Raspberry Pi additional software must be used to enable interaction with the NI environment. Some libraries exist to communicate between Arduino, and Raspberry Pi with NI software. Unfortunately, they do not offer the simplicity required for efficient communication between microcontrollers. Thus, regular serial or socket commu-
nication was utilized to perform remote measurements and then send them to the monitor GUI.
1.2
S ystem R equirem ents Several requirements were imposed on the design. The main requirement
was th at the systems must be scalable. The plan was to have many generators interconnected, such th at every one of them can be monitored. In the first itera tion of the project, the measurement system was supposed to fulfill the following requirements:
• It shall measure and record generator’s running variables, such as inlet water pressure, outlet water pressure, generator vibration (in three axis), chassis vibration (in three axis), water temperature, generator temperature, gener ated voltage and current.
• It shall compute the water flow using the calculated water velocity from the differential water pressure measurements and the pipe diameter.
• It shall display the sensor readings on a monitor, in a user-friendly interface.
• It should be a low-cost reliable implementation. I • It shall provide an infrastructure to monitor several generators concurrently.
5
During the project evolution, additional requirements were added in response to the research maturation. Those additional system qualifications are:
• It shall be able to provide control outputs in each sensor node.
• It shall support Wireless communication using standard Internet Network Protocols.
• It shall allow the remote monitoring and control using mobile devices. I
• It shall offer a GUI th at allows the Control Engineer (CE), the user, to i
program and modify user-defined control mechanism easily.
• It shall be secure in its communications among components, i.e., no unau thorized people should monitor or control the system.
1.3
M otivation During the initial research for the design, no single tool that combines hard
ware and software able to cover the whole set of requirements was available. Such a system could be implemented using Lab VIEW but with considerable amount of effort. Even though this software tool in conjunction with its supporting hardware provide many of the features required for the implementation, it is very expensive, and it can not be called low-cost. Also, it lacks heterogeneous hardware support. Additionally, Lab VIEW does not consider the delays in the network for the design
6
of distributed control. This situation represents an excellent opportunity to fill this market-gap by creating a reusable framework th at allows the interaction of many heterogeneous components to form a networked control system. This dis sertation in addition to describing the design and implementation process of such system, also goes into the formal analysis of the networked control systems in order to create a theoretical model with attributes, such a network statistics and controller dynamics. This model is then implemented into a software tool which translates and executes its representation into a distributed environment made of heterogeneous components.
1.4
A n teced en ts Several research papers were analyzed during this project development, and
the main results are briefly presented and classified in the next section. Research topics are chronologically ordered according to the time they appeared on the project.
1.4.1
Sensor N etw orks
This project started as an instrumentation of hydro energy harvesters, in which every harvester will contain a set of sensors. Those harvesters are inter connected using a computer network. In the electrical engineering field, the area of “Sensor Networks” deals with the design and theoretical aspects of sensors in-
terconnected by a network topology. Some topics were considered relevant during the initial stages of the research like the ability of the sensing nodes to perform some distributed computation [120]. The design of sensor networks often uses a layered architecture [170] to achieve tasks such as data aggregation [76], real-time communication [150, 183], better querying [33] and ease of management [40].
1.4.2
Instru m en tation o f G enerators, H ydro-m achinery and W ater Flow M easurem ent i I
After defining the sensor network, it is necessary to establish how to measure the physical variables. The principal elements to instrument in the case of the hydro-generator are: water flow, voltage, generated current and vibration. Some authors address measurement techniques in hydroelectric generators like [153, 144, 100, 104, 72]; other authors do the same for wind and steam turbines [142, 176]. D ata obtained from the instrumentation is the used to mathematically model behavior of generators as in [167, 66, 151, 108, 123]. This data could also be used to present on-line monitored data to users [15]. Design Testing can be performed using real-time instrumentation [64]. One example of such testing is blade pressure analysis [8].
Some studies had been realized over the vibration of generators
[37, 32], One of the primary goals of generator instrumentation is to calculate its power efficiency [166, 111].
8
1.4.3
G ibson’s M eth od
Flow measurement is a key component in the instrumentation therefore it is widely studied [177], especially in the case of flow inside pipelines [3, 69, 2]. An integration technique called the Gibson’s Method is normally used [163, 70, 69, 2, 71] with differential pressure sensors on pipelines.
1.4.4
W ireless Sensor N etw orks
It is possible to extend the concept of a sensor network with the use of the wireless technology. Some issues are treated in the literature [184, 141, 96] as d ata aggregation of multiple nodes [1]. Several problems can be solved in wireless sensor networks by developing a custom protocol [31, 55]. Some mathematical models for the algorithms for wireless sensor networks [78] were studied. Multiple areas could be involved in sensor networks as explained by [155]. Other problems th at will arise are coordination [24], coverage [63], load repartition [95]. Some examples of other wireless sensor network projects were studied with application in different domains and environments [139, 116].
1.4.5
Security in Sensor N etw orks
Sensor data travels from node to node inside a network of sensors.
The
internetworking of its design, make sensor networks vulnerable to attacks. Thus,
9
security is an im portant aspect of communication design in sensor networks [172, 112]. Wireless sensor networks [35, 113] present different challenges.
1.4.6
Sensor N etw orks for Control
Sensor networks could perform some control actions at the node level [148, 90]. Some extrapolation of the classical control theory to sensor networks [94] is desir able. Artificial intelligence and intelligent control [51, 147] is used in conjunction with sensor networks, and even game theory [135] is applied.
1.4.7
Frameworks for Sensor N etw orks
One common design characteristic in sensor networks is the utilization of an extra layer [98] to mask heterogeneity [115]. Other aspects such as communication [159] or coordination aspects [20] inside sensor networks are implemented in th at additional layer. This extra layer is usually referred as “middle-ware” [58] or a “framework” [61, 73]. Those frameworks are used with wireless technologies as well [89, 117, 30],
1.4.8
Energy C onsum ption in Sensor N etw orks
From the design phase, the energy consumption of the sensing nodes on the sensor network is important. Protocols [121], frameworks [73], topologies [129, 88], power-aware algorithms [185], game theory [135] and, other techniques [5] are used
10
to achieve optimal power consumption.
1.4.9
S tability o f D istrib uted S ystem s
Research was conducted on the stability of distributed systems such as a Nyquist-type stability test for multi-variable distributed systems [92] and how to maintain stability in a distributed generation system [25].
1.4.10
M obile A pplications for Control
Mobile computing refers to the use of cellular telephones and the development of their applications. The use of mobile computing in automatic control [6, 19, 105] allows the ubiquitous access to system variables to change their values. i
1.4.11
D istrib u ted Control System s, H ybrid S ystem s
Distributed control is when components to be controlled reside in separate geographic locations. Therefore this project perfectly fits into the definition of a distributed control system [44, 161, 87, 9, 138]. A distributed control system can be mathematically modeled by a hybrid system [21, 93, 22].
1.4.12
N etw orked C ontrol S ystem s
The proper subset of distributed control systems th at represents the project is the “Networked Control Systems” [60]. These systems have their m athem ati
11
cal analysis and models [86], but are extremely dependent on the communication [109]. Implementations of classic Proportional-Integral-Derivative (PID) in wire less environments [162] and other aspects such as behavior algorithms [106] are examples of research in this area. Communication models [47] and communication logistics [181] are also studied. Security remains a central topic due to the nature of the system wireless construction [154, 190, 157, 156].
1.4.13
S tability A nalysis and Control of N etw orked C ontrol S ystem s
Some papers go a little bit deeper in the stability analysis and control of Net worked Control Systems [168]. Others use Markov models to model the random delays in the network [140]. State Feedback can be used [189, 186] to control the system. Others do a characterization of input-output stability [102], There are stochastic hybrid systems [10] also. Stabilization of a system when the packets can be dropped randomly [188, 178], random delays [46, 28] or random sampling periods [84] and their challenges were contemplated. Other stabilization topics th at were studied include adaptive stabilization [152], symbolic control design [18], Communication Constraints [57] and, optimal control under communication constraints [45]. Techniques such as event-triggering in Distributed Networked Control Systems [174] and its impact on bandwidth in a wireless network [173] were also examined.
12
1.4.14
W ireless N etw orked Control S ystem s
The logical research evolution is to include wireless into the game creating a Wireless Control Network [110].
Other authors considered and studied the
implementation requirements for wireless networked control systems [99] and their models [62].
1.4.15
Intelligent Control
Artificial Intelligence refers to the use of mathematical models th at resemble to some extent the abilities of the human mind. Computational intelligence could be used to achieve intelligent control of normal [192] and distributed systems [175, 179, 145, 191, 107],
1.5
P roblem D efinition In the course of research conducted for the development of the instrumen
tation system, numerous theoretical models were examined to describe the be havior of networked control systems. Also, various implementation frameworks were considered to build the actual system. However, no single approach allows the theoretical side advantages, such as the system’s proof of stability, and the pragmatical side advantages, like the ease of deployment or security. The central problem addressed by this dissertation is the necessity of merging
13
theory and practice into one suitable framework for the design, analysis, develop ment, and. deployment of networked control systems.
1.6
O bjective The main objective is to build a software infrastructure th at allows the con
trol and monitoring of multiple heterogeneous controllers distributed among the Internet. This infrastructure must have the following specific objectives:
• It shall provide a secure schema to ensure that only authorized users will monitor and control the nodes in the system. Also, the communication between nodes must remain private at all times.
• It shall allow the user to perform a static analysis on the system such as multi-variable Nyquist-type stability test.
• It shall allow dynamic analysis by recording activity of the system’s com munication. That information shall be used to model the random network behavior using a hidden Markov chain. This model shall be utilized by the framework to compensate for random delays on the communication.
• Given a 1mathematical model to the framework, this shall automatically generate a suitable mapping of the hardware components to implement the given architecture using the available components efficiently.
14
1.7
H yp oth esis The main hypothesis is th at by the creation of a robust enough infrastructure
the implementation, and analysis of distributed control systems will become a simple interaction with a programmers interface. Also, if the implementation supports the interaction with heterogeneous components then its cost could be reduced. Finally, if the infrastructure uses standard mathematical nomenclature for describing its inputs and outputs, then common mathematical procedures for control could be easily applied to the distributed system.
1.8
Justification It is im portant to have a software infrastructure that flawlessly mixes the
world of control system synthesis with the real world implementation. The work here presented fills this im portant gap in control engineering.
1.9
R elated W ork Many tools try to prove some mathematical properties out of hybrid systems.
Those conclusions mainly are if a particular state is reachable from an initial con dition. Some examples are mentioned next, but in no particular order. PH AVer is a Hybrid systems verifier [42]. The tool named d\dt was designed to perform reachability analysis of hybrid systems [11]. HyTech is used establish the condi
15
tions under a hybrid system satisfies a constraint [59]. CheckMate is a tool for modeling, simulating and verifying properties of hybrid dynamic systems [143]. Matisse is a verification and reachable set computation of linear systems [49]. Ellipsoids is a library in MATLAB that can be used for reachability calculations [80]. SpaceEx is a tool to verify, i.e., compute the sets of system’s reachable states given a mathematical model of a hybrid system [43].
UPPAAL, It can model
and validate real-time systems that have been described as networks of timed au tom ata [13]. HSolver is a verification tool for Nonlinear Hybrid Systems [124]. KeYmaera is a Hybrid verification and theorem Prover for Hybrid Systems [114]. PowerDEVS is a general-purpose software tool for Discrete Event System specifi cation modeling and simulation used to simulate hybrid systems [14]. HyEQ is a Hybrid System Solver for MATLAB [128]. HyCreate is a tool for approximating reachability of Hybrid A utom ata [12]. All these tools cover the mathematical modeling, simulation, and validation of hybrid systems. They are all related to this dissertation in their effort to compute trajectories of hybrid systems. Nevertheless, they do not allow the extrapolation of the models to the real world application. For the real world construction of networked control systems, LabVIEW reigns as one of the industry standards due to the ease of its visual programming environment.
16
2
TH E O R E T IC A L FR A M E
This chapter wili briefly cover the theoretical foundation studied to produce this dissertation. Topics are discussed as they appeared on the project.
The
approach of this section is to describe the application of the knowledge to the project itself. At first, when presented with the challenge of instrumenting and controlling a set of hydro harvesters, the first thought was about the sensor data commu nication to the monitor station, i.e., how the sensor data flows from the node to the terminal. Another crucial aspect to consider was th at the system had to be implemented in real life at a reasonable cost, i.e., research papers usually as sume theoretical situations th at tend to be hard or expensive to integrate, in a congruent manner and meeting the established requirements, using top-of-shelf components. Lastly, it was imperative to create a mathematical model from the deployed system. This model shall be used to characterize the system’s function ally, and then some stability could be proved. Additionally, the model shall allow the development of a global optimum controller. First its optimality should be theoretical established wit the help of the system’s mathematical libraries. This model is then translated automatically to be executed on the array of nodes. Communication seemed at the beginning to be the main issue, so we now introduce some concepts in the sensor networks.
17
2.1
Sensor N etw orks A sensor network consists of a set of sensors interconnected to a main ob
serving point. Figure 3 shows an architectonic view of a sensor network, many crucial aspects of the practical implementation are omitted in this diagram. The main topology could be observed, i.e., lines represent transmission media, but it is not clear how communication is achieved. During the initial design phase, one
Gateway Sensor Node
Sensor Node
Figure 3: Sensor Network Architecture.
clear pattern emerged in sensor networks: the academic papers differ extensively from the implemented technologies available commercially. Usually to construct a sensor network, a company is hired to provide all the infrastructure tailoring general products, like NI. On the other hand, research covers topics from physical layer protocols, moving upwards in complexity all the way to the user application. Research is seldom related to actual companies and its almost always independent
18
from particular devices. W ith this in consideration, the first design was exten sively based on commercial components. The knowledge domains involved in the initial design put the project at the intersection of computer networks and instru mentation, as represented in Figure 4. Computer networks were introduced to the game due to the fact th at remote monitoring, security and mobile computing were in the requirements. In a nutshell, the project was a sensor network that consists of instrumentation nodes interconnected through a network. U Sensor Networks
Computer /J
Instru
Networks 1
mentation
Figure 4: Knowledge Domain Areas Involved in the Project.
2.1.1
Instrum entation
This section briefly introduces the theoretical concepts used in the instrumen tation of the hydro energy harvesters. This instrumentation consists of a series of sensors monitoring the behavior of the different components installed on the 19
generator. Those sensors are then connected to a virtual instrument console that allows easy interaction with the user.
2.1.1.1
Instrum entation of Energy H arvesters
It is necessary to define which physical phenomena shall be measured, the most im portant variables to monitor from a hydropower generating system are:
• The flow of water through the generating module. Q usually represents flow 3
rate, and it is expressed in cubic meters per second
• Generated Voltage and Current (with their respective frequency). The volt age is proportional to the water flow passing through the generator.
• Water temperature. Different temperatures will affect the water density thus changing the system behavior.
• Generator temperature. This measurement is im portant to ensure the safe operation of the generator by avoiding overheating.
• Vibration. Unusual movement could be a sign of malfunction inside the i
generator.
• Shaft Speed.
In combination with the water flow, this value is used to
calculate the generator’s efficiency.
20
In Figure 5 the instrumentation architecture diagram shows th at in order to read the physical measurements, an interface is needed to acquire and communi cate data to the user. This real-world interface is called D ata Acquisition (DAQ)
\= (£ M S S
/—
\
Wh
Monitoring Console
DAQ
Hydro Generator/ Sensors
Figure 5: Instrumentation Architecture.
system. One big drawback of such devices is their high price. Following the de sign requirement of constructing a low-price device, the Arduino was selected as DAQ because; of its low price and twelve I/O analog channels, with 9615 Hz of maximum sampling speed. The selection of the sampling speed obeys some tech nical reasons related to the rate of the acquired signals such as: i) The expected maximum shaft speed is around 300 RPM. ii) The generated voltage shall have a frequency in the range of 60 Hz. Other signals, even though time-dependent, are not critical for the instrumentation; thus they can be monitored at any available sampling-rate.
21
2.1 .1 .2
F low M ea su rem en t
For the proper generator characterization, it is im portant to estimate how much water is flowing through the system and its response to the passing flow in terms of electrical generation. See Appendix A. 1 for a brief introduction to fluid dynamics. The water discharge Q over a pipeline with cross-sections areas of A \ and A 2 and at different heights hi and h2 is:
Q = C o A , A 2] f ^
A
f
(1)
where Cc represents the contraction coefficient. Many standard methods are applied to measure the volume of water passing a determined area. For this project, the differential-pressure flow meter was used, i.e., Q must be estimated using knowledge about the dimensions of the pipeline and the pressure the water is applying on the walls of the pipe. Consult Appendix A.2 for a brief explication of differential pressure flow-meters. Equation 1 can be computed using differential pressure as follows:
Qm
•1 P2
with /3 =
i 2 ■s / m
- P*)pi
(2)
^
Appendices A.3 and A.4 present a detailed derivation of Equations
1 and 2. The implication of Equation 2 for the instrumentation is th at water discharge 22
shall be computed using two pressure sensors placed on different segments of the pipeline feeding the generator. Additionally, other sensors are required to instru ment the generator. In Figure 6 a general architecture of the sensor connection is displayed.
-1. .. Sensorsa>n are mapped directly into state variables I \ ... /" and all actuators on the node, A ctuatorail . .. Actuator a_m, are mapped into state variables 0 * . . . 0™. One big challenge is to map external state variables, for this purpose every control node has a secure 40
communication module th at allows the transmission of data from other control nodes, this d ata then could be mapped into inputs state variables 1% or output state variables Oyx . This mapping make it possible to express the local controller dynamic as in the example of Figure 25. The expression describes the dynamics of a control node n with has two inputs and two outputs. Variables O nl and 0 \ represent the output state variables one and two of the node n. Each of this variables will be associated with an actuator. The input variables
and I'2 are associated with
sensors in our system. Note th at the expression can have feedback, transforming the outputs into inputs of our system.
Figure 25: Mathematical Model Incorporating Real Inputs and Outputs.
In the case th at the control dynamics uses a variable th at is sensed in an ex ternal node data must be received from another node. On the other hand, when
41
the output of the expression is an external node, actualization data is sent to the required node. Lines in Figure 25 also represents a communication channel between one or more external nodes. Every one of this channels has a set of prob abilistic distributions associated with it. Each distribution models randomness in transmission time, packet loss, noise, etc. These models will be used by the system to predict its running conditions. The use of external variables inside the node is the main characteristic of networked control systems. Some control applications only have a local effect, i.e., the only variables to control are the ones th at reside on the same DAQ device. This means th at no communication or coordination is necessary. Other control systems require a global effect on all the variables involved in the controller, for example, the combined frequency of all generators must have minimum harmonics, or the system must generate a combined constant power. This kind of operations is called distributed control, but its primary execution relies on local controllers.
2.3
Intelligent N etw orked Control System s To achieve the local desired behavior, standard control theory could be ap
plied. Other approach is intelligent control. Intelligent control uses techniques discovered in artificial intelligence to modify the state of a system using encoded knowledge or experience. The idea is that the control node has the ability to deal 1
with conventional control as in Figure 25 and additionally it is able to implement
more sophisticated control such as fuzzy or neural controllers. The neural controller is based on the artificial neuron model of Figure 26. This model is an abstraction of the biological neuron, in which it is believed that the input impulses of the neuron, in this case,
must pass through
a resistance denoted by the weights wi,W 2 ,W3 . The activation function / will be trigger only if the sum of the input impulses is bigger than the bias 9. This relation is shown in Equation 6 which assumes a direct output connected to an actuator x of node a. Bias
6
no
Activate function
Output
Ul2
Ho Weights
Figure 26: Simple Mathematical Model of a Neuron.
n
°'i = f
• “' < - * )
w
An artificial neural network is a collection of neurons interconnected in layers like in Figure 27, The input layer will receive the signals to be processed. The output layer will provide the desired response of the system. To achieve such
43
behavior, the neural network must be trained using one of many algorithms such as backpropagation [193, 65, 187].
Input layer
Hidden layer
O utput layer
Figure 27: Simple Local Intelligent Control on Node a Based on Artificial Neural Networks.
For its use in control, the neural network must take its role of a universal function approximation to relate the local sensor inputs to its outputs. In Figure 27, for example, the local input variables I\ ... 7® are used to generate the output signals to the actuators 01,0 1, and 0^. The inputs and outputs of the neural network could also include variables that are remote, using the mapping performed 44
by the communication module of the control node. A different approach in intelligent control is to use Fuzzy Logic. It is based on the principle th at linguistic variables could be modeled using fuzzy set. Such lin guistic variables then could be introduced in fuzzy rules to perform inference and relate inputs with outputs. For example in Figure 28 two linguistic variables are described using sets. The first one represents “Frequency” and has three possible values: low, acceptable and high. The fuzzification logic could be interpreted as one Hz is a 100% low frequency and, 100 Hz is 0 % low frequency. This model ing is shown On Figure 28 even though no scale was specified for the frequency. Another possible linguistic variable is “Water Flow” with similar modeling but different units and scale. low
0
acceptable
Frequency
high
low
Hz
norm al
high
Water Flow
rrv s
Figure 28: Fuzzy Sets Representing a Particular Rule.
Using these linguistic variables it is possible to specify control rules for the generator, for example:
45
Rule 1: IF
frequency is low
THEN
water flow is high
Rule 1 means th at if the generator is producing a voltage at low frequency, the system must increase the water flow to high to achieve the desired state.
A
full fuzzy inference system must have many rules to relate the input variables to the output variables of our system. In Figure 29 an example fuzzy controller is presented th at relates local inputs / * . . . I" and remote inputs and outputs, in this case, 01 to the local outputs O* . .. 0 ™ and remote outputs 0®
Fuzzy Inference Engine
Control Node a
Figure 29: Control Node Implementing a Fuzzy Controller.
46
Each node could also combine all technologies producing hybrid systems such as neuro-fuzzy controllers.
2.4
M athem atical M odeling of N etw orked Control System s The model of our networked control system must consider a peculiar charac
teristic of the architecture: the communication section work with bursts of data, i.e., data is not always available. On the other hand, the generator is constantly working. In Figure 30 a general separation of the discrete/continuous components is shown.
Control Server External Control Node Coordination Layer (Communication)
Discrete
Regulation Layer (Control) / Cont. Physical Layer (Generator)
Figure 30: Discrete and Continuous Elements of a Control Node.
47
This behavior could be modeled using an automaton like in Figure 31. Every transition of the autom aton represents a discrete state of the system. Each discrete state is governed by a different continuous dynamic. The example of Figure 31, shows two possible states of the system O N and OFF. In a networked control system, the state of the whole application depends on the discrete states of the transmission. The continuous state is O * € M, and the discrete states are q e {ON, O F F}. The change of 0* is described by the differential equation a — —aO} i
when in sta te 1q = OF F. The state q can not jump from O F F to O N unless 0} > 3. A simulation of this simple hybrid system can be seen in Figure 32. O la < 91 , O F F
O N
Figure 31: Hybrid System.
Formally a hybrid control system could be expressed using a Hybrid Automa ton which describes the evolution in time of the values of a discrete and continuous state variables: D e fin itio n 2.1. (H y b rid A u to m a to n ) A hybrid automaton H is an octuple H = (Q , X , f, Init, Dom, E, G, R ), where: • Q = {?i> 92, • ■•} is a finite set of discrete states; 48
• X = Rn is a set of continuous states;
• /(' ) ■) ■Q
is a vector field;
• I nit C Q x X is a set of initial states;
• Dom(-) : Q —>2X is a
domain;
• E C Q x Q is a set of edges;
• G(-): E -> 2X is a guard condition;
• R(-} •) : E x X -> 2X is a reset map. Recall th at 2X is the power set of X . On Definition 2.1, the function Dom maps a set of continuous states Dom(q) C Rn to each discrete state q £ Q. The 100
O
0
0.2 0.4 0.6 0.8 t
1
1.2
1.4
Figure 32: Simulation of the Hybrid system of Figure 31. 49
relation (q, x) € Q x X is referred a the state of H. The hybrid autom ata define the possible evolution of the state. In a nutshell, starting from an initial value (q0, x o) G I nit, the continuous state x changes according to the differential equation x — f(qo,x) with x(0) — x$, while the discrete state q remains constant, i.e. , q(t) — qo■ Continuous change remains as long as x remains in Dom(q0). If at a point the continuous state x reaches the guard G(qo, q±) C ]Rn of some edge (qQj q\) € E, the discrete state may change to q\. At the same time, the continuous state is reset to some value in R(q0i q\,x) C Rn. After this discrete transition, continuous changes resumes, and the whole process is repeated. Hybrid autom ata involve both continuous changes determined by differential equations and discrete transitions determined by a directed graph (like an au tomaton). The analysis of Hybrid autom ata implicates the computation of its trajectories, i.e., to check if the system can reach a state given a set of inputs. One big drawback of hybrid autom ata is the ability to produce models th at are unreasonable, either physically or mathematically. One remark to make about the networked control systems is th at the imple mentation is completely different from the theory, as a simple example, a state variable could be used as an input or output, while the implementation requires a distinction between inputs(sensors) and outputs(actuators).
50
2.5
D istrib u ted C ontrol in N etw orked Control S ystem s The ability to achieve a global state using all the variables of the networked
control system employing autonomous controllers is called Distributed control. Distributed Control Systems often have a central operator which also supervises the control status of all combined nodes. This is because most implementations of distributed control over networked control systems are in the manufacturing industry, this scheme is called hierarchical control. In hierarchical control, there is a bottom layer consisting of sensors and actuators. Then another layer with the micro-controllers required to acquire and process the inputs. Then a super visory layer with computers th at will condense all the information and present a console to the user. This hierarchy could have more supervisory layers to achieve different control projects. One drawback with the hierarchical control is th at the supervisory layers must receive the perceptions of the inferior layers and then communicate a proper control action back to all inferior nodes. In the case that the control must act fastly over the plant, there will not be time to transm it the inputs and wait for the response. The control node must be able to take some autonomous control decisions. Those decisions must be consistent with the general objective of the distributed control, i.e., every autonomous part must contribute to the general success of the control. One example of autonomous control is the “Subsumption architecture” [23], this method was a prevalent way
51
to implement behavior-based robotics in the eighties. A very especial case of distributed control is when the optimal state must be achieved by the combined dynamics of the nodes, i.e., optimal distributed control. This task is way much harder th at non-optimal control since the reachable state of the system must be a maximum or minimum. Other example of optimization is to minimize the response time of the system. In general, the system must complete the optimization task by taking in consideration restrictions inherent to the problem to solve. Some methods exist to find an optimal solution, in particular, the greedy algorithms have been used extensively in optimization, a pair of examples could be found in [119] and [83]. In a nutshell, a greedy algorithm always makes the “greedy choice” , i.e., it always selects the local minimum hoping to get the global one. E.g., the knapsack problem states th at if we have a set of elements with value and weight, which elements should choose to maximize the value of items th at we can carry in a limited weight knapsack. The greedy choice is to pick always the item th at weights the less and has more value. If the greedy choice is always applied, it is guaranteed th at the knapsack will be optimized for value and weight. The greedy approach works great in discrete cases, and the optimal value is sure to be found if the problem to optimize is reduced to a Matroid [36] or more general to a Greedoid [77]. The idea of the project is for each node to be able to implement a greedy choice, i.e., each node will optimize locally. In some
problems, this behavior will achieve the global optimum. Some other examples of greedy algorithms in control could be consulted in [82] and [118]. Unfortunately, most of the control situations are not discrete in nature, like the voltage. For these problems, Intelligent Optimization could be a viable alternative. Particularly one bio-inspired algorithm called Particle Swarm Optimization (PSO) can be used to solve more general optimization problems. The particle Swarm optimization works emulating a bird flock, i.e., a population of candidate solutions is given; these solutions then move into the search space according to a specific set of social rules. W ith no specific way to measure the quality of a solution, the optimum is obtained by the particles moving towards the solution. Some examples of particle Swarm optimization applied to control could be found in [53] and [91].
53
3
DEVELOPM ENT
This chapter presents the analysis, design, and implementation of the system proposed on previous sections. In a nutshell, the project represents a ComputerAided Control Engineering (CACE) tool. One early example of such tools is pre sented in [68]. Additionally, the project involves the implementation of a frame work [164], One main deviation is th at the CACE tool is designed to handle distributed control, and the framework is able to deal with security implementing also wireless communication and mobile devices. Also, the tool allows the cre ation of intelligent control scheme based on artificial neural networks and fuzzy logic. On top of all, the infrastructure implemented will provide an environment to implement optimization schemes like PSO and greedy over interconnected het erogeneous components. The system is divided into two sections: operation and analytics. The opera tion will deal with the functioning of the communication while the analytics part will deal with the model extraction and stability test. Both parts are required to work in harmony to achieve optimal distributed control. The programs will not provide this control, but rather it is a tool th at will provide an environment to design, test, implement and operate automatic control models which goal is to achieve a set of optimal conditions. All this functionally will be accomplished by configuring an interface th at will show different levels of granularity of the real
implementation of the networked control system. For this design, it is assumed th at the electronics part will be readily avail able, i.e., sensors and signal conditioning. W ith this consideration the rest of the components are software. Thus a software engineering methodology was used to construct the tool. The first step is to simplify the architecture of Figure 19 eliminating all the electronics in the node. Figure 33 shows the main components of the system. A set of wireless nodes connected to the server through the Internet. A set of mobile clients or observers is connected to the server. The server has a central monitoring system th at allows a Control Engineer to operate and adjust global I system properties.
(«.»)
Server Internet
Internet
(«.»)
Mobile Observers
Central Observer
Figure 33: General Architecture.
55
Control Nodes
3.1
S ystem D esign The Unified Modeling language (UML) was used to define the layout of the
software. UML is widely used in computer science and even in control engineering, see [134]. Also, has capabilities for describing distributed and real-time applica tions [50]. UML is furthermore suitable to design automatic control systems like in [158]. An excellent source is [17] in which UML is explained by its creators. For this project many UML models were produced, here a subset of the most critical components and scenarios will be presented. The design aims to translate the requirements established during the previous phases into a representation that could be easily converted into a computer program. The development order of UML models for this project is Use Case, Sequence and Class diagrams. W ith this subset of models, many of this software features I
could be explained. Several characteristics of the diagrams were omitted such as temporal variables, private internal methods, or nonrelevant messages in order to maintain clear readable figures.
3.1.1
U se Case Diagram s
The Use Case Diagram shows the way the system is used by internal and external entities. External entities are called Actors and are represented by stick persons inside use case diagrams. Every oval represents a way in which the sys-
56
tem is used. Use Case diagrams were established for each mayor architectonic component. Figure 34 shows the first Use Case of the system.
This use case describe
the uses of the node control. For the node, the server, actuators, and sensors all represent external components thus they are modeled as Actors. A verbal description of the diagram is th at the server uses a communication module to send and receive data to the actuators and from the sensors. C o n tr o l N o d e
.Q u
ltnta
M a th M o d u le
A c tu a to r
[C o m m u n i c a t io n l
S ensor
* S e rv e r
Figure 34: UML Use Case Diagram for Control Node.
As well, the server uses the communication module to send update orders to the autonomous control module. The Autonomous control logic uses the math 57
module, which is described later, to perform the mathematical operation required to adjust the system’s state. Sensors must use a DAQ module which has all scaling and transformations needed for each of the appropriate sensors. The Actuator uses the system by an output module which will have the necessary interaction logic for each particular actuator. The node itself becomes an external actor every time it uses the mathematical library module. Figure 35 shows this scenario. This mathematical module can solve symbolic m ath and linear algebra. The libraries must include functions to solve systems of differential equations numerically. M a th M o d u le
P .S O
E x te r n a l C a lle r
G reed y
n
C ontrol Running: a a L c s itiJ L
C o n tro l D e sig n GUI
z
C ontrol G raph • -
- N ode Specification: ■ S e le c te d N o d e :
o!,
| . f - T y p e : - ■............
i i 1;
z
(5) O u tp u t variable O In te g r a to r
; ;' O0erivator ;
O Sum m ation O S u b t r a c t io n
zj 5
6
O C o n s ta n t
I
O C u s to m
|
8
7
| ?i
9 I ! C ontrol Sc h e m as: - ....
| NwdO
G eo g ra p b c Geo| lo n g : ) , S y stem O p eratio n : S ta b S ty Analysis
B
1
{~
Run
:
j
O p tir r a
Figure 51: Control Design GUI.
resents graphically the relations established between the inputs and the outputs of the system. This graph is the model of the automatic control scheme running on the overall system. This control graph is fully editable. Details about the selected node could be obtained by clicking once on each node; this information is displayed on the node specification section. W ith a double-click on the node, the GUI of Figure 53 is displayed. That GUI allows the custom specification of each node mapping. This custom code could be Octave or Java based. The control scheme section allows the CE to add global neuro, fuzzy and hybrid control. Those control scheme could be combined with the control graph 80
to generate intelligent control modes. The system operation section is used to invocate the main operations on the system: Stability analysis, simulation, execution, and optimization. In the case the CE presses the stability analysis, the GUI of Figure 52 is shown.
fl> l S y s te m P re v ie w W in d o w File E dit §>j S ta b ility A n aly sis •-Plot:-----------*--------
Nyquist Diagram j j>i C o n tro l D e sig n GUI
OS
A
- C ontrol G ra p h -.....
■O1 A
/'
A
0 .4
0.0
Q.e
1.0
1.4
1.6
18
2.0
2 .2
2 .4
28
28
J
Analysts O p tions; G raph T yp e: m iy q iist Contour] v j p
G eographic G eo
E dit G raph O ptions
,
_ # 1 ®
Operate
_I|J[@_ ? S
Wq
Tools
Window
□
X
Help
15 p t A p p licatio n F o n t |- r
ga v
.pa T < 0 ^ [
I------ 1
P ro to co lF ra m e
jlo c a lh o stj
gTcP 11 P ro to co llex e r.lv p ro j/M y C o m p u te r
d but still the summation of its pressure, height and velocity must remain constant. This algebra is on the Appendix A.3, Combining this velocity with the pipe diameter the water flow, in m 3/ s could be then computed. The main drawback of differential-flow meters is th at they generate a change in pressure, in this particular application , this change is not a problem but a design feature used to increase the generator’s blade speed. Industrial applications reefer to this kind of application as Venturi Tube flow measurement
A .3
D ifferential Flow M eter Formula D erivation The first im portant relation to establish is the power generated given a flow
rate:
i j
D efinition A .l. (G enerated Power) Generated Power P by a water flowing I down from height h is defined a s P = p- h- Q- g - k , where • P is the power in watts,recall the definition of a w att W = j = S'5 = V ■A;5 • p is the density of water (~ 100 0 ^); • h is the height in meters; 116
=
• Q is the flow rate in cubic meters per second; • g is the acceleration due to gravity of « 9.8^ • k is the coefficient of efficiency ranging from 0 to 1. Other very im portant relation is the Pressure p defined as
P = l
W
Prom Newton’s second law F = m • g and knowing th at m = volumen • p Equation 9 becomes V — h ■p ■g Pa m=*
Pressure unit isPascal, 7
(10)
n -sz
Water discahrge Q is defined in m3/ s as Q = AV
(11)
where A is the cross-sectional area of the portion of the channel occupied by the flow m 2 and V is the average flow velocity m / s On on the basis th at the water is incompressible, the contiuity of water flow is stableshed as Q = AiVy = A 2V2 = ... = A nVn
(12)
Prom classicalmechanics, the kinetic energy ofa non-rotating object of mass m traveling at! a speed v is Ke = ^mv2 117
(13)
= N ■m = Pa - m 3 = W ■s = C - V
And its unit is the Joule defined as J =
Also Potential energy is the energy stored in an object due to its position U = m ■g ■h
(14)
if a point of equilibrium is assumed, i.e. where the potential energy is equal to the kinetic energy, from 13 and 14
and doing some manipulation v = y/2 ■g ■h
(15)
Then substitute 15 on 11 to obtain Q
= A y j2 ■g ■h
(16)
At the orifice Flow and due to the physical properties of water a reduction in the flow is noticed, see Figure 74. Introducing th at term to Equation 16 Q = CcA ^ J 2 - g - h
(17)
where Cc ss 0.61
To establish the energy balance flow relationships, from 10 the pressure energy head can written as h=
P P'9
118
(18)
0.61 A
(a) Orifice with a head of water 1
(b) Maximu area of flow
Figure 74: Contraction Coefficient. Retrieved June 9, 2016, from USBR, web site: h t t p : / /www. usbr.gov/pm ts/hydraulics_lab/pubs/w m m /
Similarly the potential energy head from 14 is ! h=
U m -g
(19)
and the velocity head from 15 is
h=
(20)
2g
All heads are in meters. The total energy head can be calculated as Hi pressure head + potential energy head + velocity head
Hi — hi + Y- 2-l 2g
119
+
Zi
(21)
Similarly at another downstream location
H2 —h,2 + YL + Z2
(2 2 )
29
Then the total energy balance is then
i Z2 hi + —-—b Z\ — h2 + Y —^—b 29
(23)
Application of energy equation to measure flow from the continuity equation it is concluded that V\A\ — V2-A2, and solving from V2
(24) Substituting 24 in 23, if Z\ — Z2
,
VI . V i ( Ai 1+ 2g ~ 2 + 2g \ A 2/
(25)
solving for the head difference 'A '
(26)
then we can express V2
2_
V,
1 ~ * 2)29
'4 i ^2 120
(27)
Taking the square root of both sides and multiplying by A\
(28) Rearranging and including the contraction coefficient
Q — Cc A i A 2
A .4
{hi - h 2 ) 2 g A f-A l
(29)
ISO 5 l6 7 D erivation The International Standard Organization standardized in 2003 in the ISO
5167 standard named “measurement of fluid flow by means of pressure differential devices inserted in circular cross-section conduits running full” the equation used in instrumenting venturi type tubes. Derivation of this formula is presented here to compare with Equation 29 used for this project. Bernoulli equation states:
Const = p- g- h + - p - v 2 + P
(30)
where p is the fluid density, v is the linear velocity of the fluid element and P is pressure. The first term p ■g ■h is the potential energy, If a constant height is assumed
121
this term can be discarded.
Cost = \ - p - v 2 + P
(31)
64
here the term | p- v 2 represents the kinetic energy with density replacing mass. Applying this equation to a circular cross-section pipe th at is reduced in di ameter as it goes downstream in horizontal direction, see Figure 75
Figure 75: Pipeline Cross Section.
- p i ■v\ + Pi — - p 2 ■vl + P2
(32)
Mass is conserved (nor created nor destroyed) as it flows through the pipe
Qm = P2 • v 2 ■A 2 = pi • vi ■Ai
(33)
Q m is the mass flow rate along pipe, units kg/sec. Squaring both sides of 33
122
and solving for v%
2
2
I Pi ' ^1
* =
(34)
plug it in 32
2 ■(-Pi —-P2) = p2 - v l ~ Pi- v\
(35)
then substituting v2 from 34 into 35
o (p
n\_
2 [ 2 /Pl'^lV
2|
,2
P2 ' (Pi ’ A l f ~ Pi ‘ (P2 ‘ A?)2 (36)
from 36 iq, can be written as
«i = \/2 • (P, - P2) ■, j —
(pl • A i *
-------------------------(37)
V P2 ■(pi • ^ i ) - pi • (P2 • Mr
this value is substituted on Equation 33
Qm =
P i'
-t U
=
P i ■(Pi - P2) • I 2 . (P' AA ' f {P\ '
V
p2 • (pi
• Mr
„
- pi • (P2 ■Mr
(38)
Since the pipes are circularwith D upstream diameter and d downstream diameter. Their circular cross areas are: A 2 — it ■{d/2)2 and A x — n ■{D/2)2.
123
After substituting on Equation 38 and ordering terms:
« « = J n T Z p ' i ' d 2 ' %/2 '
♦
*
R 19
•O-*
J**• •fcTSl*
llll Illl • • • • • •
000000 ® ♦ ♦ ♦ ♦ l~pJL _pJ U p J l_ p j
l_ p j
•-EKJ-* •-EE}-*
•-Ea*# ♦-E2>* $w o
HyPER I n s t r u m e n t a t i o n HMSU
(a) PCB Silkscreen.
(b) PCB Tablet.
Figure 77: Final PCB for Signal Conditioning.
B .2
Sensor Scales After the signal conditioning phase, all outputs range from 0 to 5 volts. I t’s
then required to scale the output to properly fit the sensor response. Every sensor has a response table, provided by the constructor, th at can be used to scale. Unfortunately most of them the are not lineal at the extremes of operation. In 127
order to simplify the scale calculations a lineal scale is preferred. All sensors were selected with a good lineal response on the region of interest, so no data is lost during the scaling. All scales are done in software.
P ressure Sensor A linear response is assumed in the next interval: 0.5 Volt corresponds to 0 PSI and 4.5 Volts to 30 PSI. In Figure 78 a plot of the sensor response to the change in pressure is presented.
So the line response is given by the
points (0,0.5); and (30,4.5). The line equation is Y = m x + b with m = (y2 — y l ) /( x 2 — x l ) = (4.50.5)/(300) = 2/15. Therefore the offset value is b = 0.5. The scale equation is Volts = (2/15) * P S I + 0.5 If Volts
Pressure Scale
are given the scale can be 4 expressed as (Volts — 0.5) * (15/2) = P S I ,
| £
3 2
A cceleration Sensor 1 For the accelerometer the 0
5
10
15
20
25
30
operation ranges is: 1.5 Volts I — 0 G and the change rate in
p jg ure yg- Linearized Pressure Sensor Response,
gravities is of 300 mV — 1 G.
128
Figure 79 shows the sensor response to the change in acceleration. So the line equation using the points (-5,0) and (5,3) is Y = m x + b with m = (y2 —y l ) /( x 2 — x l ) = (30)/(5 — (—5)) = 3/10. So b = 1.5 The scale equation is Volts = (3/10) * Gs + 1.5 And given the volts the scale becomes (Volts — 1.5) * (10/3) = Gs.
V oltage M easurem ent This section presents d ata on voltage monitoring output. Table 1 shows the values obtained after a high-swing test. Figure 80 plots the sensor response to the change in volt age. So the line equation using
Acceleration Scale 3
the points (—240,0.281) and 2
(240,4.719) is Y = m x + b with m = (y2 — y l ) /( x 2 — x l) =
1
(4.7190.281)/(240 —(—240)) = 0.009245833. 1 Therefore b =
0 6
2.5.
4
0
2
4
6
Gravities
The scale equation is
Vout = (0.009245833) * V in +
2
Figure 79: Linearized Accelerometer Response.
2.5. And if given the Vout the scale becomes (Vout —2.5) * (1/0.009245833) = Vin Table 1 also shows the values obtained after a low-swing test. In figure 81 the
129
Table 1: Voltage Scale. Nom-High swing 240
-240
24
-42
4.719
0.281
2.888
2.112
V,n (V) V o u t
swing(V)
Nom-Low swing
Generator Speed Test for Voltage Sensor Calibration.
sensor response to the change in voltage is plotted. So the line equation us ing the points1(-42,2.112) and
Voltage Scale
= mx + b
5
with m = (y2 — y l ) /( x 2 —
4
xl)
3
(42,2.888) is Y
=
(-4 2 ))
(2.8882.112)/(42 =
0.009238095.
So
2
b — 2.5. The scale equation is
1
Vout = (0.009238095) * V in +
0 300 -2 0 0 -1 0 0
2.5. And given the Vout the
0 Vin
100
200
300
scale becomes (Vout - 2.5) * Figure 80: Linearized Voltage Response Nom(1/0.009238095) - Vin.
High Swing.
130
Current Sensor For AC current the ratio is divided as 0-5V corresponding to 0-150A of current. Figure 82 graphically shows the sensor response to the
Voltage Scale
change in current. So the line
5
equation using the points (0,0)
4
and (5,150) is Y = m x + 6
3
with m =
(y2 — y l ) /( x 2 —
2
x l ) = (1500)1/(50) = 30, so
1
6 = 0. The scale equation is
0 1-
...................................................
-3 0 0 -2 0 0 -1 0 0 Current = (30) * V i n
0 Vin
100
200
300
Figure 81: Linearized Voltage Response NomB .3
Lab V IE W C ode Low Swing. The original stand-alone
implementation of the hydro generator instrumentation is described here. This virtual instrument is displayed i
in Figure 83. Basically it is in infinite loop th at takes both pressure measurements and the it computes the water velocity to calculate next the water discharge. This basic GUI has no external communication with any other program and it is de signed to monitor the energy harvester while connected to a USB NI-DAQ or an
131
arduino working as DAQ. This Lab VIEW program allows the data logging and in conjunction with the interface of Figure 14 is used to monitor all the system response. Current Scale 150
100
0
1
3
2
4
5
Vin Figure 82: Linearized Current Response.
132
133 Figure 83: Lab VIEW
Instrumentation Code.
C
E X T E R N A L SO FT W A R E LIBR A R IE S
This part a list of libraries developed by other companies or programmers is presented. These libraries influenced the development of this project either by using some code or borrowing some implementation aspects. When code was used, proper care was taken in not violating any copyright. The name of the package is provided next to a link to its web page.
• Open Source Fuzzy Logic Library and FCL language implementation: Used a the base of the fuzzy logic package of this project. h t t p :/ / j f u z z y l o g i c . s o u rc e f o rg e .n e t/h tm l/ja v a .h tm l
• Neuroph, java neural network framework: Used to implement the neural network training algorithms. h ttp ://n eu ro p h .so u rcefo rg e.n et/
• Java genetic Algorithms Package: Used to implement the genetic and evo lutive optimization section of this project h t t p : / / j gap. sourcef o r g e .n e t/ I • Open Source Swarm Optimization Package: The PSO code of this project is based on this library h t t p : / / j swarm-pso. sourceforge.n e t/ 134
• JavaOctave: This library allows to run Octave scripts from java, it was used to enable the m atlab based control definition in the software. h t t p s : / / k e n a i . com/proj e c t s / j a v a o c t a v e / p a g e s /H o m e
• Java Universal Network/graph Framework: This library is the base of all graphical graph/network representations used in the GUIs. The node selec tion interface, and the control design relay heavily in this package. h t tp : //jun g.sou rceforge.net/
• JFreeChart: A library to plot graphics, heavily used in the node instrumen tation visualization on the server. h t t p : / / www. j f r e e . o r g / j f r e e c h a r t /
• GoogleMaps API: This library was used in the server and mobile client, and allows the creation of interactive maps in real time. h t t p s : / / d e v e l o p e r s . g o o g l e . com/maps/
• JScience, java tools and libraries for the advancement of sciences: It contains a set of mappings to mathematical structures such as rings and fields. Also has a matrix tem plate to solve linear algebra. h t t p : / / j s c ie n c e . org/
• Apache Math: This library contains many useful classes to solve problems th at range from ODE to machine learning. 135
h t t p : / / commons. a p a c h e . or g /p ro p er / co m m on s -m a t h /
• JavaCalculus: Allows the program to parse algebraic expression from strings h t t p s :/ / c o d e .g o o g l e . c o m /a r ch iv e /p /ja v a c a lc u iu s/
• Michael Thomas Flanagan’s Java Scientific Library: Some of its functions to solve control systems are used in the system’s m ath library. h t t p s ://www. e e . u c l . a c . u k / ~ m f l a n a g a / j a v a /
• AChartEngine: It is a library to make charts on Android based devices. It is heavily used on the mobile client in the instrumentation section. h t t p ://www. a c h a r t e n g i n e . o r g /
• JArduino: Allows the reading and writing of inputs to a serial communicated arduino from a java program, it has the limitation of not executing code, just accessing inputs and outputs. h t t p s ://github.com/SINTEF-9012/JArduino/wiki I
• Mikhail Gorodetsky Python’s packing and unpacking library: Used in the protocol production for the raaspberry pi pythno client. i
h t t p s : / / p a s t e b i n . com/XJyZMyHX
136
D
SY ST E M P E R F O R M A N C E C O M PA R ISO N
To compare the system developed in this dissertation with the commercial top-of-the-shelf software the next hypothetical scenario is supposed. There are two lighthouses, one in the New York coast and other in Los Angeles. Figure 84 depicts the distance of about four thousand Km between the two points. Each Lighthouse has a turning mirror th at rotates at variables speeds over a bright incandescent light. The mirror turns thanks to a motor th at has hall-effect speed encoder.
Lighthouse
Lighthouse
Figure 84: Lighthouses in the East and West Coast.
The motor on NY is running at full speed while the one in LA is stalled. The idea is to make them spin at the same rate automatically. This coordination is 137
achieved because each lighthouse has an identical node comprised of: i) A motor, ii) A tachometer attached to the motor shaft, iii) A Micro-controller with the next abilities: it can acquire the speed sensor data, and it can adjust the actual motor speed to achieve the desired speed reference. Figure 85 depicts the lighthouse’s control node.
Speed Adjustment
Speed .ererence
DAQ and Control
Figure 85: Control of Lighthouse Mirror Motor.
i
D .l
Control A rchitecture To achieve coordination among the lighthouses’ motor speeds the next se
quence of events must occur. Each control node must send its current speed to the other node and receive the other node’s speed, then use the received infor mation to adjust its own. The other control node must transm it and receive the 138
same information simultaneously. This configuration is depicted in Figure 86. This architecture shows the main problem in distributed control: communication between nodes. Communication is problematic for the next reason: if the LA node is running a zero velocity, this is the information th at will be sent to the NY node. NY node also will send the full speed to the LA node. These mes sages could reach their destination at different times, but once they have arrived, they affect the speed of its receiving node. Every node is supposed to send its speed to the other at a constant rate no m atter if it has received a new update or not. T h is 1phenomenon implies th at for several moments during the control process, the node will send a state and immediately it will modify its state with newly received information, thus making the sent information inaccurate. These discrepancies make harder to coordinate the lighthouses’ motor speeds accurately.
D .2
Test D escription A test to compare Lab VIEW with Open CACE was designed in the next
form: two simulated nodes running a motor model with its speed control are connected through a local network with added random latency. To simulate the latency from LA to NY information provided from the next AT&T site was used: h t t p : / / ip n etw o rk . bgtmo. i p . a t t . net/pw s/ netw ork_delay. h tm l. A simulated normal distributed latency of 60 ms average with a standard deviation of 20 ms was used in the test.
139
l^auJsVr Speed Adjustment
Speed Adjustment reed
Speed Reference
DAQ and Control
Speed Reference
Los Angeles
DAQ and Control k J
New York
Figure 86: Simple Distributed Control.
D .3
Lab V IE W Im plem entation Lab VIEW offers at least three methods for implementing distributed con
trol systems: i) T C P /U D P Sockets, ii) The DataSocket Transfer Protocol, iii) The Distributed Control and Automation framework. The T C P/U D P Socket is the most low-level form of communication implemented by NI. It consists of Vir tual Instruments (VI) th at visually implement the socket API in LabVIEW. This I method is the fastest in LabVIEW, but it is also the most complex to implement [ since all the bookkeeping effort is delegated to the programmer. The DataSocket Transfer Protocol (DSTP) is an encapsulation of the simple socket. It allows a simpler communication between VI by hiding from the pro grammer all variable casting details. This method puts an additional execution 140
overhead in the program, making it slower than the simple Socket approach. These first two methods are too complex to implement leaving all the ab straction of the controller tasks, variable mapping, and updating to the program mer. To reduce this complexity, NI has The Distributed Control and Automation Framework (DCAF). Is against the DCAF th at the comparative test is performed due to its similar approach to variable mapping, and variable auto update. To set up a distributed control using DCAF in LabVIEW the user must create a configuration file describing the system using the interface of Figure 87. This interface allows the mapping creation of measured variables. Also, this interface ! sets up the control logic used by every node. Every control node, or in the DCAF lingo: standard engine, could be configured with a specific IP address to access distant nodes through the Internet. Figure 87 shows the DCAD configuration of a simulation consisted of three engines, one for each lighthouse motor, and a principal monitoring station to display the results to the user. Running a distributed control has to implement all the engines and to put them in a loop, this is depicted in Figure 88. Additional VI are required for every engine implementing the control of the motor, also a VI for the visual user interface. Each engine must be in different VI files. The programmer must define a VI th at allows the graphical display of the system properties. Then the monitor interface must be hooked up to the stan dard engine (UI) inside the DCAF configuration interface. After that, the User 141
{ 3 SimulatedSystem.pcfg File
Tools
About
B t l 3 System Configuration 3 © PC 3 0 Standard Engine (UI) ; -j:::Tags : Mappings • | Q Ul Reference ' 9.M UOP S 0 Standard Engine (Simulation) iS iiiT ag s
Manual Mapping
; Visualization ; Automated Interface Matching
Channel Temperature output range high output range low
Module a Motor Controller li Motor Controller Li Motor Controller Ic
Tags Fan Lamp Setpoint P 1
Thermocouple Rea/ Motor Model Temperature i UDP
&S&K99*
: •(35 Motor Controller Logic : - J Motor Model ; US UOP : & 0 Standard Engine Tags ■ Mappings i IjScRIO
|
|a
Tag Setpoint P 1 0 Fan on? Fan Lamp Fan Lamp 0 Fan on? 1 lam p P Setpoint
Dir >> » »> .» ; >>
