Budapest University of Technology and Economics

Faculty of Electrical Engineering and Informatics

Department of Control Engineering and Information Technology

Constantino Migulez Pea

CYBER-PHYSICAL APPROACH ON
THE TRACKING OF BIOMEDICAL
SAMPLES
MSc. Smart Systems Integration

SUPERVISOR

Dr. Ferenc Ender

BUDAPEST, 2016
Contents
1 Introduction .................................................................................................................. 2
2 System Description....................................................................................................... 2
3 Structure of the Work.................................................................................................. 3
4 State of The Art ............................................................................................................ 4
4.1 Cyber-Physical Systems and Laboratory Information Management Systems ........................... 4
4.2 Intel Edison Hardware Platform ................................................................................................ 6
4.3 Overview .................................................................................................................................... 6
4.4 Selection of Edison over Galileo ............................................................................................... 8
4.5 Open-Sourced Embedded Hardware Comparison ..................................................................... 9
4.6 Wireless Sensor Networks ....................................................................................................... 11
4.6.1 IEEE 802.15.4 ................................................................................................................... 13
4.6.2 ZigBee ............................................................................................................................... 16
4.6.3 XBee.................................................................................................................................. 20
5 Materials ..................................................................................................................... 29
5.1 Hardware .................................................................................................................................. 29
5.1.1 Arduino Breakout Board for Intel Edison......................................................................... 29
5.1.2 XBee Modules................................................................................................................... 30
5.1.3 Arduino XBee Shields ...................................................................................................... 32
5.1.4 XBee USB adapter ............................................................................................................ 33
5.1.5 Routers .............................................................................................................................. 33
5.1.6 Other Hardware................................................................................................................. 34
5.2 Software ................................................................................................................................... 34
WampServer 2.5: ....................................................................................................................... 34
Apache: ...................................................................................................................................... 34
PHP: ........................................................................................................................................... 34
Embedded Java: ......................................................................................................................... 34
MySQL Community Server: ...................................................................................................... 34
Mariadb Server:.......................................................................................................................... 34
PuTTY:....................................................................................................................................... 34
FTDI Drivers: These drivers were used by the USB XBee adapter. ......................................... 34
MySQL Workbench ................................................................................................................... 34
Arduino IDE:.............................................................................................................................. 35
 Eclipse Intel IoT IDE: ................................................................................................................ 35
MySQL Connector C library for Arduino: ................................................................................ 35
MySQL Connector/J: ................................................................................................................. 35
MRAA and UPM Java libraries: ................................................................................................ 35
X-CTU: ...................................................................................................................................... 35
Yocto Project Linux: .................................................................................................................. 35
Wireshark Network Analyser: ................................................................................................... 35
Adobe Dreamweaver: ................................................................................................................ 36
Google Chrome browser: ........................................................................................................... 36
6 Specifications and Design .......................................................................................... 37
6.1 System Description and Top-Level Architecture .................................................................... 37
6.2 Use Cases ................................................................................................................................. 40
6.2.1 Use Case 1: Sample Selection and SHR Retrieval from STU .......................................... 40
6.2.2 Use Case 2: SHR Storage on STU .................................................................................... 41
6.2.3 Use Case 3: SHU Remote Reboot and SHU Self-Configuration ..................................... 41
6.2.4 Use Case 4: SHU Remote Shutdown. ............................................................................... 42
6.3 Database Design....................................................................................................................... 43
6.3.1 Distributed Database System ............................................................................................ 43
6.3.2 Relational Model............................................................................................................... 45
6.3.3 Main Database Server Operations..................................................................................... 48
6.3.4 Local Database Operations ............................................................................................... 50
6.3.5 Replication ........................................................................................................................ 53
6.4 SHU-STU XBee Interface Design ........................................................................................... 53
6.4.1 Addressing ........................................................................................................................ 55
6.4.2 Communication Protocol .................................................................................................. 56
6.5 SHU Software Driver Design .................................................................................................. 57
6.5.1 Start- up Linux Script......................................................................................................... 58
6.5.2 Shu Software Driver.......................................................................................................... 60
7 Implementation .......................................................................................................... 66
7.1 Design and Implementation Workflow.................................................................................... 66
7.2 Intel Edison Configuration....................................................................................................... 71
7.2.1 Installation of USB drivers ............................................................................................... 71
7.2.2 Serial Communication and Terminal Set-Up to the Edison board ................................... 72
 7.2.3 OS Image Flashing............................................................................................................ 72
7.2.4 Wi-Fi Setup ....................................................................................................................... 73
7.2.5 Configuration of SSH connection for Over- The-Air Programming ................................. 77
7.2.6 Backing- up of the Edison Image....................................................................................... 79
7.3 Database ................................................................................................................................... 79
7.3.1 Preliminary: Database Installation; Remote Access and Replication Configuration and
Testing........................................................................................................................................ 80
7.3.2 Final database Implementation. Federated Tables. ......................................................... 100
7.4 XBee interface........................................................................................................................ 105
7.5 Software Driver...................................................................................................................... 112
7.6 STU Emulator ........................................................................................................................ 114
8 Verification and Results .......................................................................................... 118
8.1 Use Case 1: Sample Selection and SHR Retrieval from STU ............................................... 118
8.2 Use Case 2: SHR Storage on STU ......................................................................................... 122
8.3 Use Case 3: Remote Reboot and Initialization. ..................................................................... 124
8.4 Massive SHR Update ............................................................................................................. 128
8.5 Massive Sample Selection ..................................................................................................... 131
9 Conclusions ............................................................................................................... 135
10 References ............................................................................................................... 137
11 Table of Figures...................................................................................................... 139
12 APENDIX I: Table Comparison of "Open-Spec Single-Board-Computers and Compute r-
On-Modules by June 2016 .............................................................................................. 1
 STUDENT DECLARATION

I, Constantino Migulez, the undersigned, hereby declare that the present MSc thesis work has been
prepared by myself and without any unauthorized help or assistance. Only the specified sources
(references, tools, etc.) were used. All parts taken from other sources word by word, or after
rephrasing but with identical meaning, were unambiguously identified with explicit reference to the
sources utilized.

I authorize the Faculty of Electrical Engineering and Informatics of the Budapest University of
Technology and Economics to publish the principal data of the thesis work (author's name, title,
abstracts in English and in a second language, year of preparation, supervisor's name, etc.) in a
searchable, public, electronic and online database and to publish the full text of the thesis work on
the internal network of the university (this may include access by authenticated outside users). I
declare that the submitted hardcopy of the thesis work and its electronic version are identical.

Full text of thesis works classified upon the decision of the Dean will be published after a period of
three years.

Budapest, 1 July 2016

....
Constantino Miguelez
 Abstract
In clinical analysis laboratories a large number of sample test tubes are processed during
routine diagnostics. Traditional methods used for sample registration and tracking involve a high
degree of human interaction, and therefore these methods are inherently inefficient and prone errors.

Laboratory Information Management Systems are intended to reduce human overhead in such
processes, improving efficiency, data quality and availability while reducing costs. Cyber-Physica l
Systems represent an evolution of embedded and networked control systems where the components
have a direct interaction with the physical world; these systems integrate computational, storage and
communication functionalities along with object control and tracking in the physical domain.

This thesis describes the design and implementation of a novel and innovative Cyber-Physica l
approach for a Laboratory Information Management System featuring full automation in the process
of digitally registering and tracking biomedical samples across the physical domain of a clinica l
laboratory analysis.

Identification of samples is performed by RFID-labelled test tubes and sample containers.

Numerous RFID readers are present within the laboratory area in order to keep track of sample status
and movements across different workstations. XBee wireless technology is used for communicatio n
between RFID readers and a number Intel Edison Computer-On-Modules which handle data
operations against a distributed database system in several local and remote servers, in order to
provide data redundancy and failover protection.
 Resumen
En los laboratorios de anlisis clnico, un gran nmero de muestras son procesadas durante
los trabajos rutinarios. Los mtodos tradicionales para el registro y seguimiento de las muestras
precisan de un alto grado de interaccin humana, y por ello son inherentemente ineficientes y
propensos a errores.

Los Sistemas de la Gestin de la Informacin de Laboratorio (LIMS) estn destinados a

reducir la carga humana en dichos procesos, mejorando la eficiencia, calidad y disponibilidad de los
datos a la par que recudir costes. Los sistemas ciberfsicos representan la evolucin de los sistemas
embebidos de control y comunicaciones de red, donde los componentes del sistema tienen interacci n
directa con el mundo fsico; estos sistemas integran funcionalidades de computacin, almacenamie nto
y comunicacin, as como de control y seguimiento de objetos en el dominio fsico.

Este trabajo describe el diseo y la implementacin de un innovador enfoque ciberfsico para

un sistema de la gestin de la informacin de laboratorio. Este sistema se caracteriza por una
automatizacin completa del proceso de registro digital y de seguimiento de las muestras analticas
desde el punto de extraccin o almacenamiento y a lo largo de los diferentes procesos y estaciones de
trabajo dentro del laboratorio.

La identificacin de las muestras es llevada a cabo por medio etiquetas inteligentes RFID
embebidas en los tubos de ensayo y en los contenedores de los mismos. Varios lectores RFID
localizados en las estaciones de trabajo del laboratorio registran los movimientos y el estado de las
muestras. La comunicacin entre los lectores RFID y varias plataformas hardware Intel Edison se
lleva a cabo por medio de tecnologa XBee. Los microcomputadores Intel Edison se encargan de
gestionar los datos sobre un sistema de bases de distribuidas en servidores locales y remotos que
proporcionan redundancia de datos y tolerancia a los fallos.
Abbreviations
System Devices
SHR: Sample Holder Rack Racks

SHU: Storage Head Unit

STU: Storage Tray Unit

Other Abbreviations Used

AES: Advanced Encryption Standard

CCA: Clear Channel Assessment

CMOS: Complementary Metal-Oxide Semiconductor

CPS: Cyber Physical Systems

CTS: Clear To Send

DHCP: Dynamic Host Configuration Protocol

DNS: Domain Name System

ED: Energy Detection

FFD: Full Function Device

FTDI: Future Technology Devices International

GPIO General Purpose Input Output

GPL: General Public License

IDE: Integrated Development Environment

IoT: Internet of Things

IP Address: Internet Protocol Address

LAN: Local Area Network

LECIM: Low-energy, critical infrastructure monitoring

LED: Light Emitting Diode

LGPL: GNU Lesser General Public License

LLC: Logical Link Control

LQI: Link Quality Indication

LR-WPAN: Low-Rate Wireless Personal Area Network

MAC Address: Medium Access Control

MEMS: Microelectromechanical Systems

NAT: Network Address Translation

OPKG: OpenWrt Package Manager

OSI: Open Systems Interconnection

OTA: Over-the-air (Programming)

PAN Personal Area Network

PHP: PHP Hypertext Preprocessor

RF: Radio Frequency

RFD: Reduced Function Device

RFID: Radio Frequency Identification

RNDIS: Remote Network Driver Interface Specification

RSSI: Received Signal Strength Indication

RTS: Request To Send

SBC: Single Board Computer

SFTP: SSH File Transfer Protocol

SQL: Structured Query Language

SSH: Secure Shell

SSID: Service Set Identifier

SUN: Smart Utility Networks

TQM: Total Quality Management

USB OTG: Universal Serial Bus On-The-Go

WAN: Wide Area Network

1 Introduction

In clinical analysis laboratories, very high numbers of sample test tubes are processed during
routine diagnostics. Barcodes and handwritten labelling are the methods traditionally used for
registration and tracking of biomedical samples; these systems, are inherently inefficient and prone
to human errors.

Total Quality Management (TQM) is a crucial parameter in laboratory diagnostics. TQM can
only be ensured by guarantying complete reliability of the whole sample management process; from
extraction and labelling, to transport, storage and laboratory administration. By reducing the human
overhead and paperwork involved in each step of this process, TQM can be exceptionally increased.

The Smartlab project is an innovative Laboratory Information Management System (LIMS),

which aim is to optimize the management and tracking of test tubes by automatizing certain tasks that
hamper the administration of clinical laboratory samples. This technological solution is intended to
drastically improve TQM by reducing the human overhead involved in certain tasks such as sample
labelling or sample barcode scanning and search and selection of test tubes containing the samples
within the storage banks; while also allowing to keep track and to record environmental parameters
to which biomedical samples are exposed and that are not recorded with traditional methods, affecting
to TQM.

Some of the features of this CPS are the enabling automated reading of sample tube
information, allowing traceability and environmental monitoring of sample tubes from extraction
point to laboratory, tracking of samples within different working areas of a laboratory and enabling
fast retrieval of samples from refrigerated storage areas, being this latter feature the one that this thesis
work deals with to a major extent.
2 System Description

The proposed system integrates communication over TCP/IP, Radio Frequency Identificatio n
(RFID), Wireless Sensor Networks (WSN), Embedded Computing, a Distributed Database
Management System (DBMS) and Web technology for presentation and user interface.

Sample tracking is based on embedding a RFID tag in each sample tube, containing
information relative to the sample. The test tube is stored in a Sample Holder Rack (SHR). Each SHR
includes a RFID tag which uniquely identifies it and it is intended to implement several sensors for
monitoring a set of environmental variables during transport and storage.

Once in laboratory, SHRs are stored in Storage Tray Units (STUs), each one of them being
able to store a number of SHRs and read their RFID tags. A Storage Head Unit (SHU), a device
located in the endpoints or storage rooms, acts as a gateway for a Wireless Sensor Network (WSN)
connecting up to hundreds of STUs and being able to retrieve the information from STUs as well as
SHRs. Each SHU contains a database where information regarding SHRs and Samples within its
range is stored.

The system is designed to support the co-existence of several SHUs, each one coordinating
its own WSN to several STUs which, in turn, contain SHRs. All SHUs report to a Main server where
all laboratory records are kept in a centralized MySQL database and are accessible to end users. The
system is designed to be scalable, being able and not limited to store and register several thousands
of sample tubes.
3 Structure of the Work

The background section gives an introduction to the Cyber-Physical systems, their approach
in the management of laboratory samples along with a brief literature review on this topic, the state-
of-the-art of this technology and the principles and organization of Laboratory Informatio n
Management Systems. Next, the Intel Edison Embedded PC is presented, along with its features and
a comparison with similar hardware platforms in the market. Last section covers Wireless Sensor
Networks, a description of the IEEE 802.15.4 standard, ZigBee and a more in-depth explanation of
the operation of the XBee devices used in this project.

The Materials section list and briefly describe of the Hardware and Software components used
during the development of the project, summarizing the characteristics of the wireless XBee model
chosen for this project, justifying its selection and comparing its characteristics with similar modules. ,

The methods section is divided into a design and an implementation section of the distributed
database between the Main Server and the SHUs, the WSN communication interface between the
SHU and STU and the Embedded Software on the SHU along with all necessary configuration steps
carried out on the embedded hardware platform. The software development of the SHU is subjected
to confidentiality terms and only its Top Level Design architecture is described.

Finally, results and robustness tests for interconnectivity, stability and data integrity are
included along with a section comprising few design suggestions for further development.
4 State of The Art

4.1 Cyber-Physical Systems and Laboratory Information Management

Systems
Cyber-Physical Systems (CPS) represent an evolution of embedded and networked control
systems where some of the components have direct interaction with the physical world. CPS integrate
computational, storage and communication functionalities along with object control and tracking in
the physical domain. Cyber-Physical Systems are normally interconnected with the virtual domain
by using the global digital communication networks.

The main characteristics of the Cyber-Physical Systems are the capability to interact with
physical objects for control and monitoring purposes; and the utilization of the available informatio n
in the virtual domain; where in some cases they can learn and evolve.

Cyber-Physical Systems applications can be found in multiple and diverse sectors, such as
manufacturing, energy, health care, transportation, smart cities ...etc. The context of interest within
the scope of this thesis relies on the applications of CPS in the context of clinical laboratory
management and Laboratory Information Management Systems (LIMS).

In modern laboratories, extensive amounts of data are produced; as new technologies are
incorporated to the context of laboratory analysis, higher amounts of data are being generated, and
therefore increasing the problems associated with the management of this data. Methods are required
to address this problem, and one of them are the LIMS.

The Laboratory Information Management Systems, appeared in 1970s and enable the partial
automation of the work performed in the laboratory, where traditionally about a 75% all associated
costs are related to manpower. By reducing the human interaction, overheads are reduced. One of the
objectives of LIMS is to integrate some of the sub processes within the laboratory operation among
the work performed by different individuals and improving overall efficiency. In this manner, LIMS
can reduce costs and improve data availability and identification of problems in order to address them
in the shortest time intervals possible, again, reducing associated costs [1].

The main benefits of LIMS are that data is digitally stored and can be automatically retrieved,
eliminating the need to manually search on files, the improvement of business efficiency and data
quality, automated log-in, tracking and management tasks; automated integration of hand-held LIMS
devices, automated quality control and quality reports and ease of access through the web [1].
 LIMS and CPS integration enable complex and flexible laboratory automation by
implementing automated communication between different laboratory components, which comprise
sensors, robots, cell handling, analytical instrumentsetc. LIMS and CPS integration benefit of data
consistency and usability and a guaranteed system robustness and independence as well as extended
functionalities such as process tracking using embedded visualizations or complex collaborative tasks
[2].

The most important challenges regarding the future of LIMS are the integration of systems
and processes across heterogeneous environments, providing business-to-business (B2B) networking
to enable cooperation, quality assurance and LIMS validation [3].

Sample Storage Management and tracking is a specific application of LIMS. Examples of

LIMS-CPS integration found in the literature are A Sample Storage Management System (SMS) for
Biobanks [4], where a database system was developed to enable information analysis, retrieval and
different forms of presentation for large-scale biobanks of human samples; enabling to track a ll
samples and container movements, including the management of dynamic processes while complying
with levels of data safety and confidentiality standards.

On another paper, The EnzymeTracker: an open-source laboratory information manageme nt

system for sample tracking [5], a low-cost, web-based LIMS system was implemented to track
online a growing number of laboratory samples by using QR codes, and tools for monitor ing
numerous experiments.

In the article Efficient Sample Tracking With OpenLabFramework [6] a web-based

platform was designed to enable the tracking of specialized types of samples and implemented with
an open architecture that enables it to extend it to different kinds of samples. The tracking mechanis m
is fully customizable, based on barcode labels and provides support for mobile technologies.

In Sample tracking in an automated cytogenetic biodosimetry laboratory for radiation mass

casualties[7] a computerized sample tracking system is described to track the samples of radiation
exposure tests within a fully automated biodosimetry laboratory that includes different analys is
stations. The paper focuses on increasing efficiency and maintain the positive chain-of-custody of the
samples by maintaining the tracking during data processing and analysis. The system comprises a
customized LIMS with a central server, a personal computer, workstations, barcode printers, a fixed
station and wireless hand-held devices to scan the barcodes.

These designs described above have all in common a sample-tracking mechanism based in
barcode scanning, which requires a degree of human interaction in the process of registering each
sample. Few solutions using radio frequency technology for sample identification could be found in
the literature. LIMS systems are generally expensive and not all laboratories can afford it, therefore,
considering that a laboratory may handle several thousands of samples and that barcode identificatio n
seems to be the widespread for LIMS design while it is not really a more cost effective solution than
RFID[8]; therefore, Radio Frequency Identification technology is an excellent choice to enter the
LIMS and CPS market optimizing the level of automation in laboratory sample tracking and
management.

4.2 Intel Edison Hardware Platform

4.3 Overview
The Intel Edison is a Computer-On-Module of the size of a standard SD card, oriented to
Internet-Of-Things and wearable technologies, it is a direct competitor to ARM processors in these
fields. It belongs to the strategic diversification from Intel Core classic business in behalf of a foreseen
new age of ubiquitous computing technologies announced by Intel at the 2013 Developer Forum with
the introduction of the Intel Quark System-on-Chip (SoC) processors.

Intel wants Quark to be the foundation of the Internet of Things where everything will
integrate a processor with limited digital capabilities and incorporate sensors that can communica te
with other more powerful devices, such smartphones or computers, enabling the study and analys is
of the acquired data to achieve smart technologies that can reach to the full spectrum of every-day
applications.

The intel Edison features a 22nm a Quark SoC which integrates a single-core high
performance 32-bit Quark 100MHz microcontroller along with a dual core, dual treaded Intel Atom
500MHz x86 CPU. It incorporates Wi-Fi and Low-Energy Bluetooth and an interface of forty GPIO
pins with options to different expansion boards. Includes 40GPIOs, 1GB LPDDR3 RAM, 4GB
EMMC, UART, I2C, SPO, PWM and integrated Wi-Fi and Bluetooth.
 Figure 1Front and back images of the Edison compute module

Since it runs a Linux Operating System, programming applications and writing drivers for
sensors is very similar to PC software development, which simplifies the work and opens the
hardware to developers who have no experience on embedded systems.

The Intel Edison is a low-power device that consumes approximately 1W when it is running,
this power can be reduced to 250 mW or less by using the Quark microcontroller while the Atom
processor is set to sleep mode. On sleep mode, the power consumption is minimized while external
sensors are being monitored by the microcontroller, so that the main processor can be awoken on
demand.

Table 1 Power Consumption of Intel Edison in Different Modes of Operation [9]

Mode of Operation Power consumption

All is switched off (shutdown) 13 mA (100 mW)
Only MCU, generally in sleep 25 mA (193 mW)
Only MCU, generally in sleep 29 mA (223 mW)
Normal work of Linux 67 mA (516 mW)
Linux. MCU sleep 67 mA (516 mW)
Linux. MCU is loaded 71 mA (547 mW)
Linux. Bluetooth 90 mA (693 mW)
Linux. One flow of the base processor 92 mA (708 mW)
Linux. Two flows of the base processor 107 mA (824 mW)
Loading of Linux OS 60-150 mA (462-1155 mW)
Linux. Wi-Fi Rx 240 mA (1848 mW)
Linux. Wi-Fi Tx + 2 flows 290 mA (2233 mW)
 The most significant advantage of the Intel Edison in comparison with its closest competitors
is its reduced form factor. With a dimensions of only 35.5 x 25 x 3.9 mm and its 70-pin SMD Hirose
connector, it enables its integration in custom, purpose-specific fabricated PCBs.

Table 2 Hardware features of Intel Edison [1]

Component Description
Processor 22 nm Intel SoC that includes a dual-core, dual-threaded Intel
Atom CPU at 500 MHz and a 32-bitIntel Quark microcontrolle r
at 100 MHz
RAM 1 GB LPDDR3 POP memory (2 channel 32 bits @ 800 MT/sec)
Internal storage 4 GB eMMC (v4.51 spec)
Power TI SNB9024 power management IC
Wireless Dual-band (2.4 and 5 GHz) IEEE 802.11a/b/g/n
Bluetooth BT 4.0 + 2.1 EDR
Antenna Dual-band onboard chip antenna or u.FL for external antenna
Connector 70-pin Hirose DF40 Series (1.5, 2.0, or 3.0 mm stack height)
Size 35.5 25.0 3.9 mm maximum (to be verified)
Power input 3.15 to 4.5 V
I/O 40 general purpose GPIO which can be configured as:
SD card: 1 interface
UART: 2 controllers (one full flow control, one Rx/Tx)
I2C: 2 controllers
SPI: 1 controller with 2 chip selects
I2S: 1 controller
GPIO: Additional 14 (with 4 capable of PWM)
USB 2.0 1 OTG controller
Clocks 19.2 MHz, 32 kHz

4.4 Selection of Edison over Galileo

The Intel Edison and the Intel Galileo were the two boards that were offered for the
development of the Storage Head Unit in this thesis and the choice was made for the Intel Edison.
Both boards feature the Quark processing and sufficient processing power to support the operation of
the Storage Head Unit developed for this thesis, however the decision was clear and the choice was
made for the Edison board because of the reasons described below.
 The Intel Galileo board, featuring an Intel Quark 400MHz processor and 256 MB of RAM is
less powerful than the Intel Edison, the Intel Edison has 4GB of ROM storage while the Intel Galileo
needs and SD Card.

The reduced size of the Intel Edison compute module enables its integration into customized
PCBs, which is planned to be done on the SHU as well as in another embedded device on the Smartlab
system. On the other hand, the Galileo board does not incorporate a Wi-Fi card, making it compulsor y
to stack on it an Arduino Wi-Fi shield, increasing even more its volume and size. The Edison does
not have this problem as it integrates Wi-Fi and even Bluetooth. Lastly, the Edison provides a level
of prototyping flexibility that the Galileo does not, its computing module can be attached to the
available Arduino expansion kits, providing full Arduino-compatible pinouts in order to use the
Available shields (XBee in the case of this project), and once the prototype is tested, the compute
module can be integrated into a PCB.

Summing up, the Edison board was considered a much better option than the Galileo due to
the fact that it extends the capabilities of the Galileo by being more powerful in terms of computing
power and RAM and by integrating Wireless connectivity. It also provides more flexibility for
prototyping and a smaller form factor than the Galileo board.

4.5 Open-Sourced Embedded Hardware Comparison

The list of open-sourced embedded computing platforms is fairly large; therefore, a table
comparison for prices and hardware features among 81 different boards available in the market is
included in APENDIX I: Table Comparison of "Open-Spec Single-Board-Computers and
Computer-On-Modules by June 2016.

This comparison in this section is limited to two of the most recent, popular, open-sourced
and economically-competitive boards currently available: Raspberry Pi 3 model B and Odroid-C2.

Hardkernel Odroid-C2

The Odroid-C2 arrived on 2016, it is 65 x 56mm lightweight, IoT oriented board integrating
the same Broadcom BCM2835 chip as the Raspberry Pi and a quad-core ARM Cortex SoC. It features
1GB DDR3 RAM, 64GB eMMC and supports microSD storage. It has two USB 2.0 interfaces, an
IR receiver, I2S, SPI, 40 GPIO pins and a serial console port. It operates at 5VDC @ 2A max, with a
typical 0.5A consumption. It supports Android, Arch Linux, Debian and OpenELEC operating
systems [10].
 Figure 2 Odroid-C2

Raspberry Pi 3 Model B

The Raspberry Pi 3 Model B is an 86 x 56mm board featuring a 1.2GHz, quad-core ARM

Cortex-A53 BCM2837 SoC as well as a Broadcom BCM43438 chip with Wi-Fi and Bluetooth
connectivity. It is compatible with the previous Raspberry Pi models and 2.5x faster than the RPI 2.
It features 1GB SDRAM, Micro SD Storage, 10/100 Mbps Ethernet, 4 USB 2 ports and a 40GPIO.
It operates at 5V DC @ 2.5A max [10].

Broadcom BCM2837
Bluetooth 4.1 64bit Quad Core @ 1.2GHz 4 x USB 2
Wi-Fi 1GB RAM 40 GPIO

DSI Port HDMI CSI Camera Port 10/100 LAN

Micro USB Power Input
2.5mm audio jack

Figure 3 Raspberry Pi 3 Model B

 The Odroid-C2 is available for less than 30, more or less the same price as the Raspberry Pi
3 model B, which packs similar features: quad core ARM Cortex A53 System-on-Chips. Speed is
slightly lower of the Raspberry but on the other hand it integrates Wi-Fi and Bluetooth. Pinouts
between the Odroid and the Raspberry are compatible and the Raspberry, as a result of its longer life
through the evolution of its different versions, has consolidated a larger community support and
ecosystem [10].

These two boards presented in this section meet the same hardware features that meets the
Edison regarding the Storage Head Unit requirements, excepting for the reduced form factor that
offers the Edison. This is due to the fact that the Intel Edison Compute on Module is strongly oriented
towards the IoT and particularly, the wearable market; while the Raspberry Pi and the Odroid-C2 are
Single Board Computers aimed at a broader spectrum of applications. Hence, cost is a major
difference between these devices and the Intel Edison, the latter approximately 40 more expensive.
Another particularity is that these devices provide video support and can run graphical operating
systems, while the Intel Edison does not. The power consumption on the Intel Edison is less than half
than these boards during normal operation, and even 8 times less when only the on-board
microcontroller is used.

In conclusion, in comparison with other Linux-based devices, the Intel Edison is an ideal
platform for applications where form factor and low-power consumption are critical; Boards like the
Raspberry Pi and Odroid, which have many common features with the Edison board such as offering
a high computing power, have reduced prices at the expense or larger form factors and energy
expenditure. While they offer video support for graphical interface operating systems, they are not
intended for a high degree of portability; being the cost difference the major trade-off among these
characteristics.

4.6 Wireless Sensor Networks

Wireless Sensor Networks (WSN), may be made up of tens to thousands of autonomous
devices, nodes, physically distributed among a particular scenario for monitoring and control
purposes, each of them incorporating a range of different sensors and actuators; along with data
processing, storage and wireless communication functionalities.

Smart sensors are nodes which computational capabilities that enable them to perform
decision-making tasks upon their internal or external conditions, automating and increasing the
accuracy on data collection and power efficiency. Smart sensors constitute the core of Cyber-Physica l
Systems (CPS), like Smart Cities or Smart Buildings; where physical objects are networked,
monitored and controlled using smart sensors. Smart objects are the end devices of the Internet of
Things (IoT), that interfaces the physical and virtual worlds and where each physical object can be
uniquely addressed over the network [11].

Energy
Power Storage RF Transceiver
Harvesting

A A
Sensors D CPU D Actuators
C C

Firmware

Figure 4 Block Diagram example for WSN Smart Sensor

Each node comprises at least sensing subsystem to sense different environmental variables; a
RF module for wireless communication and a compute module, normally a low-power processor, to
process the data acquired by the sensors from its physical environment. Second and third generatio ns
of Smart Sensors have increased in complexity, including predictive and reactive functionalities as
well as self-awareness, cognitive and energy harvesting abilities [12].

Each node may integrate a variety of sensors among different technologies :

Microelectromechanical systems (MEMS) sensors like accelerometers, gyroscopes, pressure or
acoustic sensors; Complementary metal-oxide semiconductor (CMOS) sensors for measuring
temperature or humidity for example or Light Emitting Diode (LED) sensor for measuring light
intensity or proximity among others.

WSNs are characterized by the capability of their nodes to establish ad-hoc links without
predefined physical infrastructure excepting for the sink-node, which is normally a network device
connected to a computer where data is extracted from the network. WSN are fault-tolerant and have
self-healing capabilities with a dynamic topology, where routing paths change over time since nodes
may appear or disappear periodically. Each node can behave at any moment as sender or receiver,
offer routing support to other nodes as well as register data from its own sensors. They are
characterized by their efficient energy management, that enables them to have extended autonomy
and, therefore, being capable of operate in remote locations with very low maintenance [13].

Wireless Sensor Networks were originally developed by the Defense Advanced Research
Projects Agency (DARPA) of the United States for detecting soviet submarines using wireless
hydrophones deployed across Atlantic and Pacific oceans during the Cold War. During the decade of
the eighties, several American universities continued further research under the Distributed Sensor
Network program, first civilian applications for WSN were on the fields of environme nta l
monitoring and disaster prevention, eventually WSN reached the heavy-industry domain [14]

Today, WSN have evolved to require lower maintenance and cost, being currently deployed
for a broad range of applications. These include home automation, medicine, automotive industr y,
industrial quality control, medicine, environmental investigations or surveillance among others.

Future challenges of WSN rely on the assessment of different application-specific trade-offs

such as performance, energy, security or reliability in order to develop a standardized set of solutio ns
for different types of systems. As Smart Systems, WSN design involves the integration of a wide
range of technical fields such as semiconductor design, energy harvesting, network protocols,
embedded software or sensor and actuator technology among others, constituting on one side an
opportunity for the manufacturers for integrating added value to their devices while, as compared
with other technologies, a significant slowdown in the time to reach commercialization and ample
market presence [14]. Some examples of ongoing research regarding the field of WSN are multimed ia
delivery over WSN, integration of WSN with the next generation of wireless internet, minimizatio n
of power consumption and node synchronization and location issues [13].

4.6.1 IEEE 802.15.4

IEEE 802.15.4 is a standard that defines the physical and medium access control layers of
Wireless Personal Area Networks (LR-WPAN). It focuses on communication of ubiquitous and low-
date-rate devices which operate under reduced power consumption requirements. The main
characteristic of 802.15.4 among Personal Area Networks (PANs) is to achieve exceptionally low
manufacturing costs by focusing on technological simplicity.

On its most basic form, it is conceived for a 10-meter distance communication link with a data
transfer rate of 250kps. Several physical layers are defined in order to fulfil different approaches for
embedded systems with low power consumption requirements. One of its most important aspects
relies on its adaptation for real time operation, using guaranteed time slots, CSMA/CA collis io n
avoidance and integrated support for secured communications. It also includes functions for energy
consumption control, link quality and detection of energy levels [15].

While specifications on LR-WPANs are intended for a general scope of applications. Certain
fields have special requirements that have been individually addressed on successive revisions of the
standard. On 2015, IEEE 802.15.4 includes the following: Smart Utility Networks (SUN), devices
intended to be deployed on large geographical areas which require eventual peaks of maximum
transmission power in order to communicate with a central node; Rail communications and control
(RCC), networks installed on railways or trains, for long distances taking over narrow parts of the
spectrum; Radio Frequency Identification (RFID), devices normally used within industrial and
commercial environments for identification applications in which the identified object normally uses
one-way communication; Low-energy, critical infrastructure monitoring (LECIM), for network of
self-powered devices performing scheduled communications and with special MAC layer
specifications to minimize network traffic; and Medical Body Area Network (MBAN) services, using
a restricted spectrum allocation in order to protect patients from interference with a defined set of
shared band usage requirements [15].

Table 3Main properties of IEEE 802.15.4[15]

Property Description
Frequency / Data rate 868 MHz: 20kb/s; 915 MHz: 40kb/s; 2.4
GHz: 250 kb/s.
Range 10 20 m.
Latency Below 15 ms
Channels 868/915 MHz: 11 channels.
2.4 GHz: 16 channels.
Frequency Bands 868/915 MHz; 2.4 GHz.
Addressing Short 16 bits; Long 64 bits
Medium Access CSMA-CA, slotted CSMA-CA, TSCH
CCA, TSCH CSMA-CA, CSMA-CA,
LECIM ALOHA with PCA
Operating temperature -40 to +85 C

4.6.1.1 Protocol architecture

The protocol stack is based on the architecture reference model for network protocols OSI
model (Open Systems Interconnection), the standard defines the Physical layer (PHY) and Medium
Access Control (MAC) layer, while it forecasts interaction with upper layers by the Logical Link
Control (LLC) component, which is an OSI data link layer interface defined by IEEE 802.2 [16].

The Physical layer defines the characteristics of the network at an electrical level and provides
a service for data transmission over the physical medium. Its main tasks are the operation of the RF
transceiver, Energy Detection (ED), computation of the Link Quality Indication (LQI) over the
packets received, channel selection and Clear Channel Assessment (CCA). Characteristics of raw
data rate regarding transmission coverage and throughput are also specified by the PHY layer. For
larger transmission distances with better sensitivities notwithstanding data rates, 868MHz (Europe)
or 915MHz (America) bands are used; while the 2.4GHz band is used worldwide for higher data rates
on shorter link distances.[15].

Upper Layers

IEEE 802.2 LLC

Other LLC
SSCS

IEEE 802.15.4 MAC

802.15.4 868/ 802.15.4

915MHz PHY 2.4GHz PHY

Physical Medium

Figure 5 IEEE 802.15.4 protocol stack

The MAC layer manages device association, packed delivery; structure, validation and
acknowledgement of frames and channel assess along with security mechanisms. MAC Common Part
Sublayer (MCPS-SAP) and MAC Management MLME-SAP are services provided for
communication with upper layers. LLC, which is just above de MAC layer, enables protocol
multiplexing across the MAC layer, flow control optimiza tion and packet retransmission. IEEE
802.15.4 specifies a Service Specific Convergence Sublayer (SSCS) for interfacing IEEE 802.2 LLC
and the MAC layer as in it is shown in Figure 5 [15].

4.6.1.2 IEEE 802.15.4 Device types

The IEEE 802.15.4 standard makes two closely related device classifications, according with
the device functionality and according the network role of the device. Regarding device functionality,
these are divided on Full Function Devices and Reduced Function Devices; whereas regarding the
network role they are classified as PAN Coordinators, Coordinators and End Devices.

FFD devices are normally connected to the mains power and that are able to communica te
with any other device within range, they can operate as coordinator or as endpoint and in any
topology.
 RFD devices are intended for simple tasks such as data monitoring, they are generally battery-
operated and with limited computing power and communication requirements. RFD can never operate
as coordinators or routers [17].

Coordinators are FFD devices which can rely messages, PAN coordinators are a special type
of coordinators; which besides relying messages, are in charge of starting the network and have
capabilities to find suitable channels and automatic PAN ID configurations. In an 802.15.4 network,
only one PAN coordinator can exist. Finally, End devices can be FFD or RFD devices which are not
behaving as a coordinator.

4.6.2 ZigBee
ZigBee is a protocol built on top of IEEE 802.15.4 to extend its functionalities. It was designed
by ZigBee alliance in order to add mesh networking capabilities to 802.15.4. Mesh networking is
used in applications where distances between communicating nodes may be bigger than transmiss io n
ranges and therefore intermediate nodes are used to retransmit the messages.

ZigBee protocol is designed to provide dynamic topology capabilities, where several nodes
can stablish a network without user interaction and in case of node failure, routing paths would
dynamically change. Routing algorithms used in ZigBee networks are Ad Hoc On Demand
Distance Vector Routing (AODC) and the Tree Based Routing Algorithm [18]

Application Layer (APL)

Defined by
ZigBee Application Support Sublayer (APS)
standard Security
Services
ZigBee NWK

Defined by 802.15.4 MAC

IEEE
802.15.4
standard 802.15.4 PHY

Physical Medium
.

Figure 6 ZigBee Protocol Stack

 As shown in Figure 6, the upper Network (NWK) and Application (APL) layers defined by
the ZigBee specification sit on the top of the 802.15.4 protocol stack (Figure 5). As it was described
on section 4.6.1.1, IEEE 802.15.4 specifies an interface for upper network and application layers,
which can be very simplistic. However, the advantage of using proprietary ZigBee NWK and APL
layers is the reduced memory footprint required for implementing the whole protocol, which in turn
may translate in a cost reduction. By using ZigBee, interoperability among devices from different
vendors is ensured, which is one of the key features of ZigBee; another advantage is the reliability
provided by the dynamic routing capabilities introduced with the mesh topology support [18].

4.6.2.1 ZigBee Device types

There are there types of devices: Coordinator, Router and End device.

The coordinator is the device that starts the network, either by performing energy and active
scans in order to find a suitable PAN ID in the clearest channel. Once it starts a network, it controls
the association of other devices. A coordinator may have network routing functions.

The function of router devices is mainly to route data across the network and assist end devices
joining the network. Both coordinators and routers cannot enter sleep mode.

End devices are the most basic elements of the network. They do not perform routing tasks
and they can enter different states of power-saving modes. They may be connected to sensors to poll
periodic data.

4.6.2.2 Network topologies

The main network architectures used to deploy WSNs are described in this section. Point-to-
point, Point-to-multipoint and Cluster Tree topologies are both supported by IEEE 802.15.4 and
ZigBee while Mesh topology is supported only by ZigBee. Real-world network implementations may
vary significantly, being hybrids of the main topologies described in this section. This relies on the
self-configuring and dynamic topology features of ZigBee, where nodes may be randomly located,
randomly appear or disappear from the network and behaving as different devices at each moment
[13].

Point-to-Point: It is the simplest network topology, which comprises just two nodes, where
one of them is configured as coordinator in order to be able to start the network and the
other node is configured as router or end device.

Point-to-Multipoint: Also called Star topology, it is formed by a coordinator node situated in

the centre of the topology. Every packet in the system passes through the coordinator, which
 is in charge of routing the messages according to the needs of the nodes; therefore, end
devices do not communicate directly with each other.

Point-to-Point Point-to-Multipoint Cluster Tree

Coordinator (FFD)

Router (FFD)

End Point (RFD)

Figure 7 Network topologies supported by IEEE 802.15.4

Cluster Tree: In this topology the coordinator communicates with FFD devices, which in
turn, communicate directly which all nodes within their cluster, being a cluster all end
devices around them.

Mesh Hybrid Mesh-Cluster

Figure 8 Network topologies supported by ZigBee

Mesh: Each node manages more than one connection, therefore there exists several routes to
reach the same destination. This topology employs router nodes to support the coordinator in
retransmitting the messages to the End Devices according to their needs.

Table 4 Comparison of network topologies [18].

Topology Advantages Disadvantages
Point-to- Low latency. Not always possible to
Multipoint implement.
Robustness and Reliability.
Low scalability (Collisions).
Simplicity.
If Coordinator fails, whole
Easy to implement.
network is affected.
Homogeneous Energy
expenditure.
 Mesh Lower cost that Cluster Tree: System complexity.
Not many of routers needed to
High number of collisions.
achieve high scalability.
Higher latency.
Reliable even if one or several
nodes fail.
Cluster All advantages of star Routers may significantly
Tree topology. increase final cost.
High scalability. If a router fails, branch fails.
Low degree of collisions. Costly.
Complex dynamic routing
algorithms.

4.6.2.3 Packet structure

PHY frames comprise three fields: The Synchronization Header (SHR), PHR Header (PHR)
and PHY payload. The purpose of the SHR header is to allow the receiver to synchronize with the
transmitter, the PHR Header contains the length of the frame while the PHY payload encapsulates
the information transferred to the layers above.

The general format of MAC frames was designed to be highly flexible and match the needs
of different applications with different network topologies while maintaining a simple protocol. The
MAC frame is contained in the PHY payload, it is constituted by a MAC Header (MHR), for
addressing functions; a MAC Footer (MFR) for data integrity verification and the MAC payload.

MAC and PHY layers are specified on IEEE 802.15.4 while the NWK and APS layers that
rely on top of them, as described below, belong to the ZigBee specification.

AHR Aux. HDR APS Payload MIC APS Frame

NHR NWK Payload NWK Frame

MHR MAC Payload MFR MAC Frame

SHR PHR PHY Payload PHY Packet

Figure 9 ZigBee packet structure [18]

NKW layer comprises a header (NKW) for network addressing and a payload, which
conforms the APS frame, which has four fields; these fields are an APS Header (AHR) for control
and application- level addressing, an auxiliary frame header (HDR), which contains the shared keys
used for encryption and the APS payload, which contain application level data. The Message Integrity
Code provides a means for checking the integrity of the payload [18].

4.6.3 XBee
XBee is a trademark for a range of wireless solutions based on the 802.15.4 standard and
commercialized by Digi International. XBee modules are an ideal choice for rapid prototyping, they
use SMT or Axial 20-pin standard connectors. All modules share the same pinouts, offering great
flexibility to switch to different protocols in the same hardware by interchanging the modules.
Modules include digital GPIO, Analog inputs, an internal microcontroller with different
programmable variants, industry leading sleep currents and a range of different antennas.

Figure 10 XBee Pro trough-hole module with RPSMA antenna connector (Left), XBee SMT module (Right)

4.6.3.1 XBee Module operation

4.6.3.1.1 Command mode and Transparent Mode

The XBee modules are able to run in three different operation modes: The AT Transparent
Mode which is equivalent to a virtual serial link between two XBee modules; the AT Command Mode
which is used to remotely change the configuration settings of the XBee modules; and the API Modes
1 and 2, which enable the exchange of predefined data structures.

In AT command mode, AT Commands allow to configure different settings such as network

and addressing parameters; the RF interface, security parameter, low-power parameters,
configuration of the GPIO, configuration of pin polling and diagnosis.

In AT transparent mode, the settings that govern the communication are configured trough
AT Command mode, therefore, the module need to be changed to AT Command mode every time
that the destination addresses need to be changed, making the operation slower. The source address
in not included in the frames. This is the operating mode chosen to implement the communicatio n
interface between the SHU and the STU.
 API mode: Change of destination address in simpler than in AT mode, each frame contains
both the source and destination addresses, the API frames can contain AT commands themselves.
Disadvantages are that frames need to be built by a host device prior transmission, upon reception the
whole frame needs to be parsed to read the payload, as opposed to the AT Transparent mode.

4.6.3.1.2 Serial Communication in AT transparent mode

The XBee modules contain a CMOS logic level UART, by which they can be interfaced from
a host device, such as an external microcontroller or the Intel Edison board using compatible voltage
levels (2.8-3.4 V).

The UART interfaces on the hosts microcontrollers and the XBee modules must be configured
with same baud rate, data start/stop bits and parity. Configuration of these settings on the XBee
module can be performed either by reprogramming its firmware using XCTU software or remotely
once in AT Command Mode from another XBee module.

When operating on AT transparent mode, the XBee modules behave as a virtual serial port,
all outbound data received by the XBee module from the host microcontroller through the Data Out
(DO) pin is queued to be sent wirelessly; in the same manner, all inbound data received wirelessly to
the XBee module is buffered to be sent to the host microcontroller through the Data In (DI) pin.

Data is sent asynchronously through the DI pin, when no data is being transmitted, the UART
line is kept at high level, the beginning of serial communication is signalled by a low start bit
following eight data bits and a stop high bit.

Voltage Least Significant Bit

1 1 1 1 1 0 0 0 1

Time
Start Bit (Low) Stop Bit (High)

Figure 11 : UART data packet as transmitted through the RF module [19].

The XBee modules contain a Data In and a Data Out buffers; their function is to store the
inbound data from the wireless link and outbound data from the host microcontroller; data is buffered
until it is either sent through the RF link or to the microcontroller via UART.
 The internal data flow of the modules including the DI and DO buffer is shown in the figure
below.

DI DI Buffer
Transmitter
CTS
Antenna
Processor
Port
RTS
Receiver RF
DO DO Buffer Switch

VCC

GND

Figure 12 XBee Internal data flow diagram [19]

All serial data entering the XBee module through the UART is kept in the Data In (DI) buffe r
until it can be packetized and transmitted through the RF link.

The packetization rate of the DI-buffered data is determined by the packetization timeout (RO
value), which is the time allowed to elapse between the reception of last character until the DI-
buffered data is wrapped into a packet and sent wirelessly.

If RO is configured to 0, every character received from the host microcontroller is directly

transmitted to the RF link. If RO value is set to a higher value, which allows the inbound data to reach
the 100 bytes of capacity in the DI buffer in a shorter time than the RO packetization timeout; DI data
is automatically packetized as it reaches 200 bytes and it is subsequently sent to the RF link in order
to prevent buffer overrun. Likewise, packetization is triggered if a Command Mode Sequence
(GT+CC+GT) is received; causing RF transmission of all the DI data prior entering into AT
Command Mode.

In brief, the three possible events that trigger packetization are the reception of an AT
Command Mode sequence, a packetization timeout event and the reach of the 200 Byte maximum DI
buffer capacity.

Hardware flow control can be implemented using the

signal, which is enabled by setting
, Clear To Send, goes logically high when the DI
DIO7=1 on the XCTU firmware configuration.
buffer is 17 bytes to full, in order to notify the host microcontroller to stop sending data.
is
restored to low when at least 34 bytes are freed back from the DI buffer, signalling the host to resume
sending data.

Software flow control can be implemented instead of a hardware mechanism by, both,
ensuring that the host microcontroller is sending messages under 200 bytes, which is the size of the
DI buffer; and by using a lower baud rate on the host device UART than in the RF interface. The
UART interface data rate, corresponds to the BD firmware setting that is flashed on the XBee module
using the XCTU.

The DO buffer queues all incoming data from the RF link and pipes it to the host
microcontroller. If DO buffer reaches full capacity, overflow can occur and the subsequent loss of
the inbound RF data.

There are two scenarios where DO buffer can overflow; when the RF data rate is faster than
speed at which the UART is set and if the XBee module is not allowed to pipe out the DO-buffer
data. The first scenario is avoided by either ensuring a proper UART interface data rate between the
XBee module and the host microcontroller (BD) or by implementing a software flow control
mechanism to avoid buffer overrun. The second scenario is managed by implementing hardware
signal, which is enabled by setting DIO6=1 on the XCTU firmware
flow control using the
configuration. When
is set to logical low, the contents of the DO buffer are sent to the host
device UART.

4.6.3.1.3 Configuration of the XBee network

Operation characteristics of the XBee modules on the Physical and Medium Access Control
layers of the IEEE 802.15.4 protocol are briefly described in this section.

Network operation depends on its configuration since a LRWPAN may use one of the two
channel access mechanisms: Beacon enables and non-beacon.

In non-beacon networks, the CSMACA standard is used and the operation is as follows: When
any device needs to transmit on the network, it first checks if the channel is busy by another device
transmitting. If another device is transmitting, the device will retry to transmit later or it will indicate
a communication failure after several unsuccessful retries. An ACK frame confirms if the
transmission was successful and this is sent immediately after each packet is received as shown in the
following picture:
 Figure 13 Data transfer model End Device-Coordinator in a non-beacon enabled network

In a beacon enable topology, each frame is fragmented in several time slots, which allows for
several channel accesses avoiding collisions. (CSMACA, Carrier Sense, Multiple Access, Collis io n
Avoidance). In a beacon enabled network, each device wishing to transmit during the contentio n
access period, waits until the next time slot and then determines if any other device is being
transmitting at that moment.

The network is formed by one Coordinator and several End Devices which share the same
Personal Area Network, PAN. Several PANs can coexist within the same range and channel. There
can only exist one coordinator in each PAN whereas the maximum number of end devices it is only
restricted by data traffic.

4.6.3.1.3.1 Association

The XBee modules are configured to operate as coordinator by setting CE=1. End devices are
configured as such by setting CE=0. Each end device needs its destination address configuration to
math its coordinator low MAC address. XBee modules are preconfigured with a broadcast destinatio n
address as factory default. In later sections a design suggestion is described for a dynamic firmwa re
configuration system, where it is the SHU the device in charge of setting the proper communicatio n
configuration parameters, such as addressing, on the SHR XBee modules which are found in range
with factory-default settings.

Once a coordinator and an end device are found to be within the same PAN, they automatica lly
establish a membership, this is the association process. In order to associate, both devices must have
its firmware configured with the same PAN Identifier, PAN ID, which must be unique within different
networks in range. This process is governed by the A2, Coordinator association, parameter.

Upon power-up, end devices are unaware of the PAN ID and channel of their coordinator.
The A1 parameter, End Device Association, sets the flexibility regarding PANI ID and Channel for
an associating end device.
 When the association process starts, each end device broadcasts a Beacon Request frame. The
coordinator replies with a Beacon and the end device sends an Association Request, which allows the
coordinator to know its MAC address and assign it a low address (16-bits). The coordinator always
assigns the 0xFFFE address to transmit. Employing 64-bit addresses for transmission and 16-bit
addresses for reception, the coordinator can easily identify which is the end device that is transmitting
without the need of maintaining an internal table of assigned addresses.

In order for and end device to start the association process, the bit 2 in the A1 parameter must
be set. In order for a coordinator to accept end device association request, the bit 2 in its A2 parameter
needs to be set.

4.6.3.1.3.2 Dynamic PAN ID and channel configuration

The assigned bandwidth to 802.15.4 in 2.4GHz is divided in sixteen channels spaced by 5MHz
each. The parameter SC allows to specify a bitmap of the channels on which to operate. Likewise,
the SD parameter sets the scanning time for each channel and the CA (Clear Channel Assessment)
parameter controls the maximum allowed energy level for which a channel is considered clear for
operation.

4.6.3.1.3.2.1 Coordinator

The behaviour of the coordinator upon power-up is determined by the parameter A2,
Coordinator Association. This parameter consists of three bits, bit 0 is the Reassing_PANID flag,
whereas bit 1 is the Reassign_Channel flag and bit 3 corresponds to the AllowAssociation flag.

If bit 0 is not set, the coordinator is configured to stay on a fixed channel, it listens on it silently
upon power-up and does not perform a scan. Likewise, if bit 1 is not set, the module maintains the
CH, Channel value present on its configuration upon power-up [19].

If bit 0 is set, the coordinator is configured to reassign its PAN ID, it sends Beacon Request
frames in all the channels and elaborates a list of all PAN IDs found in order to elaborate a unique
new one. First it sets itself in a channel and transmit broadcast requests (0xFFFF) on addresses and
all PANIDs. Next, it listens for beacons from any other coordinator present in this channel for a time
configured in SD (Scan Duration parameter). This operation is repeated until five PANs are found or
all channels have been scanned. Finally, the coordinator has found the PAN IDs and channels already
in use. These results are used to set a PAD ID on the coordinator. The module will use the value set
in the PAN ID parameter it this is not found to be already in use by the discovered PAN IDs, if this
value is found to be in use, the module automatically assign itself a unique PANID. As described
above, SC and CA parameters also govern this operation [19].
 If bit 1 is set, the coordinator is configured to reassign its Channel to the clearest one. Upon
power-up, it sets itself in one channel and issues an energy scan for the time specified in the SD
parameter, this operation is repeated until all channels have been scanned. Once the scan in finis hed,
if the bit 0 is set, the coordinator discards all channels where PANs have been found. Finally, when
the clearest channel has been detected, the CH, channel value is updated [19].

If both bits are set, the coordinator is configured to reassign its PAN ID and channel, it chooses
a unique PAN ID in the most silent channel [19].

Once the coordinator has either issued energy and active scans to configure its PANID or CH
or has been preconfigured to use a specific values previously configured. It sets itself on that channel
and PANID and listens for end devices connecting to the network. The bit 3 on the A2 parameter,
AllowAssociation, determines if only end devices are allowed to connect to it when this flag is set.
The XBee modules have an on-board LED, the coordinator remains on while the start-up process is
taking place and starts blinking once it has successfully started.

A2 bits 0 and 1, ID, CH and MY (source MAC address) parameters should not be modified
during operation since this would cause, the MAC address of the coordinator to reset with a
subsequent loss of connectivity to the End Devices. A2 bit 3, AllowAssociation, may be change d
without risk.

4.6.3.1.3.2.2 End device

The behaviour of an end device upon power-up is determined by the parameter A1, End
Device Association. This parameter consists of eight bits; bit 0 is the Reassign_PANID flag, bit 1 is
the Reassign_Channel flag, bit 2 corresponds to the AutoAssociate flag and bit 3 is the
PollCoordOnPinWake; the remaining bits are reserved.

If the AutoAssociate Flag is not set, the device uses its present values on the MY, CH and ID
parameters to transmit without performing a new association. If AutoAssociate is set, it performs
PANID and Channel scans as described below.

If the AutoAssociate bit is set, the End Device broadcasts Beacon Request frames in all
channels and PANIDs upon power-up; following the same process as described for the coordinator
power-up scan. Once the scan is finished, it associates to a coordinator depending if Reassign_PANI D
and Reassign_Channel flags are set or not; in order whether to enable or disable association on any
of these respective values. In the most flexible case, where both are set, the End Device sends an
AssociationResquest to a Coordinator with any PANID found in the channel with highest RSSI. The
Coordinator replies with an association confirmation and the on-board LED of the End Device begins
to blink at a rate of twice per second. Once the End Device is operating the values for the CH, ID and
A1 parameters should not be changed since it would break the existing association.

4.6.3.1.3.3 Addressing
Every XBee module has a factory unique IEEE 64bit MAC address, which corresponds to the MY
parameter. All XBee packets contain both the destination and source addresses in their headers.

The 802.15.4 specification supports short (16bit) and long (64bit) addressing. XBee modules can be
configured to use only 16bit addressing by setting the DH (Destination address High) parameter to
DH=0. 16bit addresses are dynamically assigned by the network coordinator and are unique only
within their network. Regardless of the addressing in use, modules can only communicate when they
are in the same PAN and channel [19][20]. .

4.6.3.1.3.3.1 Unicast transmission

In order for two XBee modules to communicate, the DL, Destination address Low values of the
senders must match last 16bit of the MAC address (MY parameter) of the receivers.

Table 5 Sample Unicast Network Configuration [19]

Parameter RF Module 1 RF Module 2

MY (Source Address) 0x01 0x02
DH (Destination Address High) 0 0
DL (Destination Address Low) 0x02 0x01

Unicast transmission mode is the default mode on the XBee modules. In Unicast transmiss io n,
packets are addressed to just one recipient. Once a packet reaches its destination, the recipient sends
back an ACK, Acknowledgement, packet to the sender. If the sender does not receive an ACK, it will
attempt send the packet a maximum of three times unless an ACK is received.

4.6.3.1.3.3.2 Broadcast Transmission

In broadcast transmission, packets are received by all the devices on the network. In broadcast
mode, ACKs are not sent; therefore, there is no transmission control mechanism to ensure packet
delivery. Broadcast operation on the XBee modules is configured by setting both DL=0 and DH=0.
Note, that if using 16bit addressing, only the Destination Low parameter needs to be changed since
Destination High is already DH=0.
4.6.3.1.3.3.3 XBee Operation Modes
The XBee Modules have five different modes of operation: Transmit, Receive, Sleep and
Command mode.

The module enters either Transmit mode when inbound data from the host device enters the
DI buffer. There are two types of transmit mode, direct and indirect transmission; in direct
transmission, data is transmitted directly to the destination address while in indirect transmission, the
module waits for the destination to request the data before transmitting it. Before transmitting, the
module performs a CCA (Clear Channel Assessment) on which the energy level of the transmiss io n
channel is compared to the value set in the CA parameter; if the measured energy level is higher than
CA, the module waits for a time specified in the RN (Backoff Exponent) parameter to retry the
transmission.

Sleep
Mode

Transmit Idle Receive

Mode Mode Mode

Command
Mode

Figure 14 Operation modes of a XBee module

The XBee modules enter Sleep Mode when they are not transmitting for at least the time set
in the ST, Time Before Sleep, parameter. During Sleep Mode, power consumption is minimized. In
order to enter Sleep Mode, the Sleep_RQ (pin 9) must be high and the SM, Sleep Mode, parameter
must be set to 1 (Hibernate), 2 (Host-controlled sleep) or 5 (Cyclic Sleep).[19]
5 Materials

5.1 Hardware

5.1.1 Arduino Breakout Board for Intel Edison

The Arduino breakout board provides the Intel Edison provides an Arduino native pinout, it
is designed to be compatible with the Arduino R3 board, allowing the stacking of Arduino shields for
interfacing them with the Edison module.

Figure 15Intel Edison Breakout Kit for Arduino

All pins in the board support GPIO functionality, and some PWM, ADC, SPI or I2C. Pins are
multiplexed for different functions and selection of these is done through the use of SoC pin
multiplexing control interfaces and GPIO output signals. Supported pins functions are external GPIO,
used for input and output signalling using on the external shield pins; Pin multiplexing control for
selecting different function available for a particular shield pin; Pin Buffer, level-shifter for direction
control and Pin pull-up control [21]. Two breakout boards were used, mounting their respective XBee
shields and modules.
 Figure 16 Arduino pinout [22]

5.1.2 XBee Modules

The XBee modules used are the 802.15.4 Series 1 model. Point to Multipoint Wireless
Networking RF Modules with 1mW PCB antenna. They operate on the 802.15.4 protocol stack band
can be interfaced serially on TTL levels. For the first implementation of this project, four of these
modules were used, one for the SHU, two for simulated STUs in star topology and another as packet
sniffer/injector by using the USB XBee adaptor.

Figure 17 Front and back side of an 802.15.4 S1 XBee module

 Table 61.1.1.1 Characteristics of the XBee 802.15.4 Multipoint Wireless Networking RF Module [23]

Power output 1mW (+0 dBm)

Indoor/Urban range Up to 30 m
Outdoor/RF line-of-sight range Up to 90 m
RF data rate 250 Kbps
Supported network topologies Point-to-point, point-to-multipoint, & peer-to-peer
Supply voltage 2.8 - 3.4 VDC
Transmit current 45 mA (@ 3.3 V) boost mode
35 mA (@ 3.3 V) normal mode
Receive current 50 mA (@ 3.3 V)
Power-down sleep current <10 A at 25 C
Frequency band 2.4000 - 2.4835 GHz
Interface options 3V CMOS UART
Size 0.960 in x 1.087 in (2.438 cm x 2.761 cm)

XBee modules were chosen among other wireless modules due to its compatibility with
Arduino and the ease to interface them with the Intel Edison Arduino breakout board by using the
existing Arduino shields, within the range of XBee models, all of them sharing a common footprint,
making it easy-to-susbstitute model for one or another, depending upon application needs with
minimal development needs, while also being a great deal for rapid prototyping and time-to-market
reduction.[24] The required 802.15.4 network topology on the Smartlab system design between the
SHUs (coordinators) and the STUs (end devices) is of Star or point-to-multipoint, with no need of
advanced routing capabilities such as XBee Digimesh; for this reason the a 802.15.4 Series 1Point-
to-multipoing model type was chosen. This XBee module type has two versions, the PRO and no
PRO. Due to short range of operation required for this system, typically, within a storage room; the
non-PRO version was finally the chosen for this project due to its low-power operation, integrated
PCB antenna and point-to-multipoint network topology. Next table shows a comparison between
these two model versions.

Table 7 1.1.1.1 Comparison of XBee 802.15.4 Point-to-Multi point modules [24]

Performance 802.15.4 802.15.4 PRO

Indoor/ Urban Range 30 m 90 m
Outdoor LoS 90 m 1600 m
Transient Power Out 0 dbm (1mW) 18 dbm (63mW)
 RF data rate 250 kbps 250 kbps
Receiver sensitivity -92 dbm -100 dbm
Operating Icc (TX) 45 mA 215 mA
Icc Stand by 10 uA 10 uA
Antena Option Chip/wire/RPSAM/U.FL Chip/wire/RPSMA/U.FL
Supported Network Topologies Point-to- Point-to-point/multipoint/peer-
point/multipoint/peer-to- to-peer/repeater
peer/repeater
Encryption 128 AES 128 AES
GPIO 15 15
Analog Inputs 4 4

5.1.3 Arduino XBee Shields

The Arduino XBee shield provides a physical interface between the XBee module and the
Inter Edison Arduino breakout board. Among all the XBee Arduino shields available, this specific
model (XBee W/o RF Module PN#A000021) was chosen due to the fact that it is described by Intel
documentation as a tested and working shield on the Edison board [25].

Figure 18 Arduino XBee shield

The XBee module worked correctly mounted on this shield, however functionality was
limited when using it on the Edison Arduino Breakout board. At it can be seen on the top-right corner
of Figure 18, the shield incorporated a switch which with USB and XBee positions. This is intended
to select the XBee UART lines to be connect directly from the host device (Arduino) or by the USB, (
Figure 16) the USB position, interfaces the DOUT and DI pins of the XBee module with the Rx and
Tx pins of the USB FTDI chip respectively when using an Arduino board. It was not possible to
connect directly to the XBee module from the PC by using the USB on the Edison due to the fact that
the Intel Edison has three serial ports, and the one that is switched to in the USB position
corresponds to the UART1 port, being UART2 the port that actually interfaces the USB line. The
outcome of this is that it was not possible to program the firmware of the XBee modules directly
when mounted on the breakout board, and instead, it was needed to use an external USB adapter
for this task.

Figure 19 XBee shield mounted on the Arduino Breakout board,

5.1.4 XBee USB adapter

XBee USB adapters were used to program the firmware settings on the XBee modules by
connecting it to a PC using a USB type A to type B cable. It communicates with the XBee modules
using UART protocol. It works with a FT232RL chip and requires the installation of USB FTDI
drivers on the PC.

Figure 20 XBee USB adapter

It is also possible to control send and transmit data directly from the computer and to listen to
the network, which was particularly useful for programming the controllers and debugging the
communication.

5.1.5 Routers
Two different routers were using for the development of this work: Technicolor TC7200
Cable modem dual band concurrent Wi-Fi 802.11n home router in a first phase were database
replication was configured and tested on the Intel Edison, and a ASUS Wireless-N600 802.11n RT-
N18U High Power Router for the final implementation.

5.1.6 Other Hardware

Sony VAIO laptop: Intel 2.4 GHz x 4 Core i5 Processor, 4 GB RAM, 500 GB HD and
802.11b/g/n wireless interface. Running Apache and MySQL servers on Windows 7 Home
Premium 64bit. It was used to simulate a remote MySQL database, a remote server on Apache,
and a remote client trough Google Chrome browser

AC Adapter Phihong PSA15R-120P: Wall Mount AC/DC Adapter 15W 12V 1.25A for
powering the Inter Edison board.

Micro SD MMC CARD 4GB for backing up de configured Intel Edison Image.

Oscilloscope, Multimeter, USB cables and pin connectors.

5.2 Software
WampServer 2.5: A software stack consisting of Apache web server, MySQL and PHP.

Apache: An HTTP web server that was used to host the PHP code used to test the databases. It
is licensed under Apache license.

PHP: Hypertext Preprocessor is a server-side programming language licensed under PHP

license. A code in PHP was used to test the databases from a remote client.

Embedded Java: SHUs software components were developed in Java in order to provide
portability to different hardware platforms.

MySQL Community Server: (GPL) Multiuser and multithread relational database

management system.

Mariadb Server: (GPL): A MySQL-compatible database installed on the Intel Edison board.

PuTTY: SSH Telnet Client used to connect to the Edison boards and to the XBee modules.

FTDI Drivers: These drivers were used by the USB XBee adapter.

MySQL Workbench: (GPL) is a visual database tool. It was used to create and manage the
databases as well as writing and testing the different database scripts, connecting remotely to the
Main and local databases installed on the SHUs and configuring their parameters. MySQL
workbench allows for easy management of user privileges, table manipulation, importing and
exporting data among other features.

Arduino IDE: (GPL) is an integrated development environment for the Arduino platform. It
was used on the first development stage for programming the Edison board and testing the
MySQL database replication. Includes a collection of C/C++ libraries LGPL licensed.

Eclipse Intel IoT IDE: (GPL) is a development environment for Intel Edison and Intel
Galileo on the Eclipse platform. It includes the native device libraries on these systems and allows
to stablish SSH connection to the modules, Over-The-Air programming and file management. It
was used to develop the final software on the SHUs.

MySQL Connector C library for Arduino: (GNU) C library used to connect the Intel
Edison directly to the MySQL servers during the first stage of development.

MySQL Connector/J: (GNU) Platform independent SQL Java libraries used to imple me nt
database connectivity on the SHU software

MRAA and UPM Java libraries: Libraries used to interface the GPIO and particular ly
the XBee module on the Intel Edison. These libraries are included in the Eclipse IoT, which
checks and synchronizes the native libraries on the Intel Edison.

The mraa I/O library translates the GPIO interfaces to the available pinout on the Edison board
enabling the control of communications at low-level by using high-level languages such as Java.

The UPM library is a high-level repository of sensor libraries written in C++ and based on the
mraa libraries. The UPM Java XBee library was used to implement the XBee communicatio n.
This is a simple library using the Java Native Interface which implements the classes for
communication in AT transparent mode.

X-CTU: (Freeware) Windows based to stablish a serial connection to the XBee RF modules.
The program includes a user friendly graphical interface that allows to interface several RF
modules simultaneously and configure their firmware. Moreover, this software permits to
perform several tests on the modules and over the network such as RSSI tests, range tests,
network scans, measure the transfer ratio between two radio modules in the same network,
monitor the RF communication and inject packets into the network.

Yocto Project Linux: (GNU) Operating system running on Intel Edison.

Wireshark Network Analyser: (GPL) was used for troubleshooting the Wi-Fi connection.
Adobe Dreamweaver: (Proprietary License) Web development tool. It was used for
programming the PHP test code used perform tests to the databases and their connectivity during
the first stage of development.

Google Chrome browser: (Freeware) was used remotely query the SQL databases by the
PHP code hosted on the Apache web server. Licensed under Google Terms of Service.
6 Specifications and Design

The work within the scope of this thesis focuses in the design and implementation of the
Storage Head Unit (SHU), the Distributed Database System and the XBee wireless interface between
the SHU and the Storage Tray Units (STUs) within the Smartlab Cyber-Physical System (CPS).

6.1 System Description and Top-Level Architecture

The objective of the Smartlab system is to automate the tracking of samples (test-tubes) within
a clinical analysis laboratory context. For this purpose, the system needs to maintain constant
awareness of the status of the test-tube samples registered in the laboratory by continuo us ly
monitoring and updating the distributed database system in order to provide a means to locate, select,
register, retrieve data or automatically update the collection of sample data while the test tubes are
being manipulated.

The Sample Holder Racks (SHRs) contain the sample test tubes and both of them can be
identified by embedded RFID tags. The Storage Tray Units (STUs) are intended to be installed on
the refrigerated areas of the laboratory, where the biomedical samples are stored. The STUs are
comprised of stackable trays in which the SHRs are inserted. Each STU tray is equipped with a RFID
reader to retrieve the information of the stored SHRs along with a LED indicator to indicate the
laboratory workers specific SHRs, when any of the samples that they contain are selected from a web
user interface.
 Main DB
Server

SHU

Sample
Federated Tube
DB XBee

RFID Tag
Router XBee

RFID Reader

LED

LIMS
User Interface

STU #1 STU #2 SHR

Figure 21 Labroom Top-Level System Architecture

STUs are driven by a STM 32 microcontroller, which controls a XBee module and connects
to the Storage Head Unit (SHU). The SHU, which is implemented on an Intel Edison Board, behaves
as the XBee coordinator and it communicates with all the STUs within its Personal Area Network
(PAN). Several PANs can co-exist within the same range without conflict. As coordinators, SHUs
are responsible for creating the XBee network, managing the association and registration of the
discovered STUs on the main database. They also provide network addressing support at the
application layer to ensure message delivery to specific STUs while using Broadcast transmission.

Data is stored in a Main database server, which may be physically located in the laboratory or
on a remote location, Each SHU contain an embedded database server using the Federated SQL
engine, which proxies all database transactions to the main database server. Therefore, SHU databases
behave as mere SQL relays, not storing data themselves. Data redundancy and failover protection are
provided by a replication set-up where the Main databases copy their data into a centralized Data
Warehouse, which may store data for several main servers, each belonging to a different laboratory.
(Figure 23)
 Samples can be selected from a web application user interface that writes on the main
database. SHUs continuously monitor the contents of the database looking for selection of samples.
When sample selection occurs, the SHUs under which the STU containing the SHR containing the
the selected sample (for each sample) is located, sends messages on the XBee interface, addressed to
those STUs affected and instructing them to turn on or off the LED indicators for the SHRs.

If a SHR is manually retrieved from the STU tray or if it is stored in one of them, the STU
notifies via XBee to the SHU this event. The SHU updates the database accordingly.

Figure 22 Network Topology of the System

The following above shows the network topology of the system for one laboratory room from
the main database end to the STU end. The system is scalable so that the number of STUs, SHUs and
laboratory rooms handled by it may increase indefinitely.

The system design, as it will be presented in the database implementation section, is flexib le
in regards of the Main DB server location. The implementation is tested to support both, a Main
database within a LAN or a remote Main database over the WAN.
6.2 Use Cases

6.2.1 Use Case 1: Sample Selection and SHR Retrieval from STU
Description: A laboratory worker needs to retrieve a set of samples from a refrigera ted
storage room. Using a web application, selects the chosen samples. By using luminous indicators, the
system signals in which trays the sample holders (SHRs) containing the selected samples are stored.

Preconditions:

1. The samples exist on the Main database.

2. Samples are stored in the refrigerated area; therefore, sample Status is cooled.

3. The SHUs and STUs associated to the samples are running with no errors and therefore
have online Status

Main Flow:

1. The laboratory user searches the desired samples on the User Interface and marks them
as selected or as unselected if they were already selected, according to needs.

2. The sample selection or deselection is applied to the Selected field on the Sample table
in the Main database.

3. Upon update on the Sample table, a trigger stored on the Main database checks on
which SHRs the samples are contained, and if the SHRs LED indicators are already
turned on or off.

4. Only the SHRs which are not turned on and contain a sample which has been selected
are marked for LED turning on. Similarly, only the SHRs which do not contain any
other sample which is selected and contain at least one sample that has been unselected
are marked for LED turning off.

5. The SHU, observes this changes and notifies the corresponding STUs, the turning on
and turning off orders for the trays of the SHRs containing the samples.

6. The LED indicators on the corresponding STU trays are turned on or off.

Post conditions:

1. The Laboratory User, spots the SHRs by the LED indicators and retrieves the SHRs.

2. The SHU updates the Status of the SHR on the Main database from cooling to floating
and disassociates the SHR from the STU and the SHU on the database tables
6.2.2 Use Case 2: SHR Storage on STU
Description: The laboratory worker stores a SHR on the refrigerated storage room.

Preconditions:

1. The SHR to store was previously being moved around the laboratory. Therefore, its
status is floating and it is not associated to any STU nor SHU.

Main Flow:

2. A laboratory worker places the SHR on one of the STU trays.

3. The SHR ID on the RFID tag of the SHR is read by the STU tray.

4. The STU notifies the SHU the STU ID, SHR ID in an update message.

5. The SHU associates the SHR ID to the received STU ID and its own SHU ID on its
local Federated database. The SHU changes the status of the SHR to cooled.

6. The SQL queries on the Federated database are proxied to, and take effect on, the Main
database.

Post conditions:

1. The new status of the SHR along with the STU and SHU IDs that it is associated to,
can be observed from the User Interface which connects to the Main database.

6.2.3 Use Case 3: SHU Remote Reboot and SHU Self-Configuration

Description: An user, marks a specific SHU for reboot from the user interface. Upon
receiving this notification, the SHU services all pending XBee communication, safely stops the
running services and reboots. Power-up triggers a start-up script and executes initialization routine,
which creates the federated database, configures the Wi-Fi and XBee interfaces and registers the
STUs in range in the database.

Preconditions:

1. SHU status is online

Main Flow:

1. User marks an SHU ID or SHU Alias for reboot. This action sets the Action field for
the corresponding SHU on the database to reboot.
 2. The SHU sees the reboot order. If it is in the middle of a XBee communication with
the STU, it services the pending messages until all of them have been acknowledged
by or to the STU.

3. On its local federated database, the SHU sets the Status of all STUs within its own
domain to offline and it sets its own Status as offline.

4. The SHU executes a Linux command to stop all running services and proceed to
reboot.

5. On reboot the Intel Edison connected to the Wi-Fi network, a start-up script is
executed. The SHU ID, and IP address are written on a file. The SHU software driver
is initiated.

6. On running, the SHU software driver calls the initialization procedure. It drops the
pre-existing database, and creates a new one using the Main database IP address and
login credentials present in a user-modificable SHU configuration directory. It
connects to the main database, creating new federated tables.

7. The SHU executes a network discovery, and registers all STUs in range in the
database.

8. All Initialization steps and errors, if any, are registered into a logfile. Errors are
communicated to the User Interface by writing on the local database if it is up.

Post conditions:

1. The SHU is up and running, it can be seen as online from the user interface as well as
all the STUs within its range.

6.2.4 Use Case 4: SHU Remote Shutdown.

Description: An user, marks a specific SHU for shutdown from the user interface

Preconditions:

1. SHU status is online

Main Flow:

1. User mars an SHU ID or SHU Alias for shutdown. This action sets the Action field for
the corresponding SHU on the database to shutdown.
 2. The SHU sees the reboot order. If it is in the middle of a XBee communication with
the STU, it services the pending messages until all of them have been acknowledged
by or to the STU.

3. On its local federated database, the SHU sets the Status of all STUs within its own
domain to offline and it sets its own Status as offline.

4. The SHU executes a Linux command to stop all running services and proceed to
shutdown the Intel Edison board.

Post conditions:

1. The Intel Edison board is not running. It is seen on the database as offline as well as
all the STUs under its domain.

2. The only way to bring up the SHU at this point is to manually power-on of the Edison
board.

6.3 Database Design

6.3.1 Distributed Database System

The database architecture of the system comprises three types of database servers: A data
Warehouse which can be located on the Main or in the laboratory building, several Main Database
servers, one located in each laboratory or laboratory room and a number of local embedded database
servers running on the Intel Edison Board (SHU).

The chosen Database Management System is MariaDB, the SQL engines used are InnoDB on
the data Warehouse and the Main database for data storage; and the FederatedX engine on the SHUs
for query mirroring to the Main database.

Mariadb is an open source and lightweight database and a compatible alternative to MySQL
which was developed by former MySQL designers. The similarities between Mariadb and MySQL
are very high. Mariadb is built on the open-source code of MySQL and all changes implemented on
newer versions of MySQL are mirrored in Mariadb. Although package names are differe nt;
commands, configuration files, sockets, APIS and protocols are all the same. Therefore, all MySQL
connectors that allow different programming languages to interface with MySQL, also work with
Mariadb. On the other hand, Mariadb offers some extra features and MySQL does not offer as well
as performance improvements.[26]
 The FederatedX engine is a more reliable version of the Federated engine and it is only
supported on Mariadb server. Tables created using the FederatedX engine do not store data, instead
they behave as proxies by replicating all queries executed against them over their associated tables
on the Main server. Federated tables are used to provide local data availability from tables stored on
the Main database without the increased network traffic and configuration downtimes associated to
clustering and replication.

MASTER #1 STU

Federated SHU#1 STU

WEB
SERVER
MAIN DB
DB #1 STU
STU

Federated SHU#1 STU

DB
STU
STU

Federated SHU#1 STU

DB
STU

REPLICATION Federated Federated

SLAVE DB DB
LER LER
STATION#2 STATION#1
LABROOM #1
MAIN DB #1
MAIN DB #2
MAIN DB #... MASTER #2 STU

Federated SHU#1 STU

DATA WEB
MAIN DB
SERVER
WAREHOUSE DB #2 STU
STU

Federated SHU#1 STU

DB
STU
STU

Federated SHU#1 STU

DB
STU

Federated Federated
DB DB
LER LER
STATION#2 STATION#1
LABROOM #2

Figure 23 Distributed database Architecture

Each SHU runs a MariaDB database server with a set of Federated tables connected to a Main
database server. The database system is designed to support an undefined number of local databases
as the system scales up. New SHUs and other embedded-database devices may be incorporated to the
running database system with no downtimes. The embedded software on the SHU manages automatic
local database creation, configuration and connection.

A dedicated machine one each laboratory runs a Main Database server along with an Apache
Web server. The main database, using the InnoDB engine stores all the data in the context of the
laboratory while supports the incoming SQL transactions from the associated Federated databases on
the SHUs and other embedded databases of third devices within the laboratory (out of this Thesis
scope). The Apache server connects locally to the Main database and runs the Web User Interface
used by the system.

Finally, the database system is designed to support data redundancy and failover protectio n
by using a replication set-up, where each Main database server replicates its contents on a data
warehouse. The data warehouse, behaves as a replication slave for a number of main databases. Data
is stored in separated databases in the data warehouse server for each Main database in each laboratory
room (See Figure 23).

6.3.2 Relational Model

The Main database structure comprises ten tables. The relational model was designed to
provide data support to all the operational requirements on the Smartlab system. However, only the
Sample, SHR, SHU and STU tables provide support to the SHU device operations within the scope
of this thesis and only these tables and their related operations will be described.
 Figure 24 Main Database's EER Diagram

The relational diagram in Figure 24, shows the database structure. The Sample table contains
the data regarding the individual test tubes and their statutes. Each test tube is identified by an RFID
tag, the data in this tag is stored as Sample_id, which uniquely identifies each sample and therefore,
is the Primary key of this table. Many samples can be stored on each SHR, therefore the relation
between these two tables are 1-N where with SHR_id as the foreign key on the Sample table. The
Status column is an enumerated type which is used to indicate if the sample is stored in the refrigera ted
area, cooled; if it is not associated to any device, floating, or at any other location within the lab. The
Selected field is a Boolean type which is written by the Web User Interface directly during sample
selection or unselection.
 Figure 25 Structure of Sample table

Figure 26 Structure of SHR table

As the test tubes, each SHR is uniquely identified by an RFID tag, its value is stored in the
SHR_id field, which is the primary key of this table. Each STU can store several SHRs, thus, there is
a relation N-1 between these tables and STU_id is the foreign key on the SHR table. Likewise, many
SHRs can be under the same SHU domain. SHU_id is another foreign key. The status field determines
whether a particular SHR is stored in the refrigerated area (cooled), or it has been retrieved by a
laboratory user from its STU tray and therefore its location is temporally undetermined (floating).
The lastAction field is a flag of enumerated type used by the SHU software driver to determine which
type of message (LED indicator turning on or turning off) must be sent to the STU. Lastly, the
Selected field is a Boolean type used to mark the SHRs containing samples that have been selected.
This field is written by a Trigger stored on the main database.

Figure 27 Structure of STU table

 Each STU is uniquely identified by the Serial number of the microcontroller that drives it.
This value is sent to the SHU during the STU Discovery that takes place at SHU initialization. The
SHU takes care of registering this value along with the Status field, which marks each STU as online
or offline. The STU_Alias column is used for human readability, each STU may be given a descriptive
name, making is easier to be identified from the user interface. There is a relation N -1 between the
STU and the SHU tables, being SHU_id a foreign key in this case.

Figure 28 Structure of SHU table

Each SHU can be uniquely identified by its SHU_id, during boot-up, the SHUs store the 16
least significant bytes of their Wlan0 MAC addresses in this column. This is the Primary Key. Like
the STUs, SHUs may be given an Alias in the SHU_Alias column. IP_address and Status are used to
support network mapping and tracking for remote SSH console connections to the Intel Edison boards
if needed. The Action field is used to remotely control the SHU: The observe and update values
correspond to the main operation states of the Software Driver and are written by the Trigger stored
on the Main database; the reboot and shutdown values are written by the user interface, and once
written, the respective actions are initiated on the Intel Edison.

6.3.3 Main Database Server Operations

All data regarding the samples and devices within the laboratory is stored in the Main database
server. Its main functionality is to store this data and support all the incoming SQL transactio ns
originated from the local databases using FederatedX engines, which are running on the SHUs and
other embedded devices across the laboratory.

The Main database server can also be configured to be the Master of a replication set-up where
a data warehouse situated in a different physical location is the slave; and, in turn, the slave of other
Main databases in different laboratories or laboratory rooms.

The Web user Interface accesses directly to the Main Database server, retrieving data on
demand and performing sample selection as it was described in the Use Case 1. Communication and
event notification from the web interface to the SHU takes place through the database and a trigger
stored on the main database server is used for this purpose.

A trigger is a user-defined procedure that is stored in the database server and fires every time
a determined event occurs over a certain table. In this case, modifications of the Selected column on
the Sample table. Therefore, the trigger called SHUnotifier executes every time a sample is selected
or unselected by the user interface. SHUnotifier has three functions, there are:

Mark as selected the SHRs containing the selected samples

If the selected SHRs do not have floating status:

o Set action=update on their corresponding SHU

o Set lastAction=turnon/turnoff on the selected SHR

delimiter //
create trigger SHUnotifier after update on sample
for each row
begin
SET @thisSampleSHR = (select shr_id from sample limit 1);
SET @thisSampleSHU = (select shr.SHU_id from shr join sample on
shr.shr_id=new.shr_id limit 1);
SET @selectedSamples = (select count(*) as count from SAMPLE where selected=true
AND SHR_id=@thisSampleSHR);
SET @thisSampleSHRStatus = (select Status from SHR where SHR_id=@thisSampleSHR);
if (new.selected=true and old.selected=false) then
if (@selectedSamples>0) then
update shr set shr.selected=true where
shr.shr_id=@thisSampleSHR;
if (@thisSampleSHRStatus!='floating') then
update SHU set action='update' where
SHU_id=@thisSampleSHU;
update shr set shr.lastAction='turnon' where
shr.shr_id=@thisSampleSHR;
end if;
end if;
end if;

if (new.selected=false and old.selected=true) then

if (@selectedSamples=0) then
update shr set shr.selected=false where shr.shr_id=@thisSampleSHR;
if (@thisSampleSHRStatus!='floating') then
update SHU set action='update' where SHU_id=@thisSampleSHU;
update shr set shr.lastAction='turnoff' where s
shr.shr_id=@thisSampleSHR;
end if;
end if;
end if;
end
// delimiter ;

Figure 29 Trigger on Sample Selection Stored in the Main Database

6.3.4 Local Database Operations
The local database on the SHU comprises two federated tables, a view and a stored procedure.
The database and its components are erased and rebuilt at every reboot of the Intel Edison, federated
tables do not contain data, therefore there is no data lost during this operation.

Federated tables are identical in structure to their counterparts on the Main database. The
database creation queries executed at SHU initialization require the IP address, user and password of
the Main database. This values are retrieved from a configurable file in the Intel Edison. If no Main
database configuration file is found, the defaults values that the software uses are IP/port
192.168.1.100:3306, User root and no password.

SHU Access to its local database is performed by a root user with no password, restricted to
Access from host only. Remote database management, if needed, could be performed by accessing
the SQL console in the Edison on a SSH session over Wi-Fi or USB.

6.3.4.1 SHU Local Database Components

Federated SHR Table: This table is connected to the SHR table on the Main database, which
stores all SHRs, and therefore, it is the second largest table in the system after the Sample table. It
may contain up to thousands of records.

ThisSHU View: This object is a stored query that filters down the contents on the SHR table
by the SHU_id corresponding to the SHUs Wlan MAC address on which the database is running.
Therefore, it contains only a subset of the data from the SHR table, scaling down its size and ignoring
all records irrelevant to this SHU similarly to a horizontal partition by SHU_id. Since the SHU writes
on the SHR table; by using a view, data integrity is enforced by ensuring that it can only modify the
dataset corresponding to SHRs under its domain.

ToggleStatus Stored Procedure: This is a SQL query stored on the server that receives an
SHR_id as an argument and performs the following actions:

Toggles its status field of the corresponding record between cooled and floating.

If the new SHR status is floating, then it disassociates it from their STU and SHU by setting
these columns to null on the SHR table.

If the new SHR status is cooled, then it sets the STU_id field to the STU ID contained in the
XBee message that fired the execution of the stored procedure and sets the SHU_id field to the SHU
ID of the SHU executing this operation.
 Using a stored procedure reduces the amount of queries executed since it eliminated the need
for the SHU software driver to perform an extra query to retrieve the current SHR status or the need
for storing the status of the SHRs on memory. On the other hand, opening and closing connectio ns
are expensive operations, therefore this implementation contributes to improve the system efficie nc y.

FEDERATED TABLE
TABLE Sample
Sample STORED
Sample_id
Sample_id PROCEDURE

ToggleStatus
Status
WebApp Status cooled/floating
Selected (True|False)
Sample Selection Selected
TABLE SHR UPDATE
FEDERATED TABLE SHR tray turn on/off
SHU_id Retrieve/
SHR VIEW Update SHRs
SHR_id ThisSHU
TRIGGER SHU_id SHR Status change
SHUNotifier LastAction SHR_id SHR_id STU
LastAction
(turnon|turnoff|nothing)
LastAction Status Edisons Wlan MAC
Status (cooled|floating|inler)
Selected OBSERVE SHU_id
Selected (True|False) Status
Polling SHU
Selected Monitor STU IFace
TABLE SHU
SHU_id FEDERATED TABLE
IPAddress SHU
...
SHU_id
Action (observe|update|reboot)
IPAddress INITIALIZATION
Status (online|offline) STU Discovery

Action Edisons Wlan IP
IP Address
TABLE STU Status
STU_id FEDERATED TABLE
REBOOT
... STU
Status (offline|online) STU_id
...
Status
Cloud Database SHU Local Database SHU Software STU

Figure 30 Main-Local Database Interface and SHU Operations

The components comprising the database interface between the Cloud server and the local
servers are put together on Figure 30. This figure describes the database operation in the following
directions:

Sample Selection SHR Tray Indicator turn-on

1. By using the Web Application, a user selects a set of samples. Their Selected field is
then updated to true.

2. The Selected field on the SHRs containing the samples is updated to true and the
lastAction field is set to turnon.

3. If so, the Action field on the SHUs managing the corresponding SHRs are changed to
update.

4. When the SHU sees a change to Action = update on the Federated SHU table, it queries
the Federated SHR table to retrieve SHR_id and lastAction values of the SHRs of those
SHRs which lastAction column do not contain a nothing value.
 5. SHU communicates the STU the SHR_ids to turn which contain a turnon value on
their LastAction column.

Sample Deselection SHR Tray Indicator turn-on

1. By using the Web Application, a user unselects a set of samples which were already
selected.

2. The Web application checks, for each unselected sample, it there are any other
remaining samples selected within the same SHR. If no other selected samples are
within the same SHR, the Web Application turns the SHR Status to turnoff.

3. The Web Application sets the Action field on the SHU table to update for each SHU_id
associated to the SHRs to turn off.

4. Analogously to the sample selection procedure. The SHU communicates the SHRs to
turn off when it sees a change from Status=observe to Status=update in the SHU table.

SHR retrieval Cloud database update

1. A SHR is removed from the STU. STU notifies the SHU.

2. SHU receives the notification and executes the ToggleStatus stored procedure.

3. ToggleStatus updates the status of the corresponding SHR from cooling to floating
and sets STU_id and SHU_id fields to null in the Federated SHR table, in order to
disassociate the SHR from these devices while it is floating.

4. SHR table on the Cloud database is updated through the Federated SHR table.

SHR storage Cloud database update

1. A SHR is stored in a STU tray, the STU notifies the SHU its SHR ID and STU ID

2. The SHU, updates the SHR table on the database. On the SHR table, the STU_id field
is set to the received STU ID value, and the SHU_id field is set to the SHU unique id
of the device handling the operation. ToggleStatus is called to change SHR.Status to
cooling.

3. Note that the SHR could have been released from a STU associated to another SHU,
for this reason, STU_id and SHU_id fields were set to null during the SHR retrieval
operation.
6.3.5 Replication
As it has been described previously, a replication set-up provides data redundancy for the
Main database server when it is configured as a master and another database server (data warehouse)
is configured as the slave. Data and transaction on the Main server are replicated on the data
warehouse, in case of failover, the data can be restored from the warehouse into the Main server.

The slave server has been named data warehouse because it can be used to provide data storage
to multiple Main database servers simultaneously. In order to clarify and not to confound this set-up
with multi-source or multi- master replication configurations, it needs to be pointed out that in this
design the data warehouse server runs multiple database instances as slaves for each main database.

During the implementation iterations, multiple tests have been carried out in order to test and
configure the replication operation on the MariaDB servers. Replication has been tested on the
embedded databases on the Intel Edison as well as over a simulated WAN environment and the
configuration and testing process is thoroughly described in the implementation section of this thesis.
Due to the fact that current system requirements do not need this type of database configuration, it
has not been included on the final implementation of the system. Therefore, data warehouse and the
configuration process for the replication are documented in this thesis as a design suggestion and
reference if further system development needs arise.

6.4 SHU-STU XBee Interface Design

The communication between the Storage Head Unit (SHU) and the Storage Tray Unit (STU)
takes place wirelessly using XBee communication.

The network topology is designed in a star topology where the XBee module on the SHU is
the coordinator and the XBee modules on the STUs are the end devices. Communication takes place
in AT transparent mode

Figure 31 represents the system data flow for an XBee link comprising two XBee modules
which are connected to their respective host devices by the UART interface.
 DI DI
CTS RF Link CTS
Host MCU XBee XBee Host MCU
(Intel Edison) DO Module Module DO (STM32)
RTS RTS

Storage Head Unit (SHU) Storage Tray Unit (STU)

Figure 31 Data flow for the UART-interfaced XBee RF link between the SHU and SHR.

As shown in Figure 31, four pins are needed on this AT transparent mod communicatio n
setup: DO, DI pins and negative logic pins
CTS (Clear to Send) and
RTS (Request to Send), which
are used for hardware flow control of the DI and DO buffers respectively.

Table 8 XBee module pins used for data transfer in AT Transparent mode

Signal Pin
DI 2
DO 3

CTS 12

RTS 16
VCC 1
GND 20

The XBee modules have their firmware configured with factory default UART settings, these
are (8N1): Baud rate 9600bps, 8 data bits, No parity and 1 stop bit.

The XBee network formed by the STUs and their corresponding SHUs follow a star, point to
multipoint, nonbeacon with coordinator topology. Each coordinator operates the end devices within
a Personal Area Network (PAN) ID; XBee modules have their firmware configured to operate in a
specific PAN ID. Two XBee devices configured with different PAN IDs cannot communicate with
each other, therefore several PAN IDs can co-exists within the same physical space with no
disturbance.
 PAN ID #1

STU
STU

SHU STU

STU SHU: Coordinator

SHR: End Device
STU

STU STU
STU STU

SHU STU SHU STU

STU STU
STU STU

PAN ID #2 PAN ID #3

Figure 32 Three SHUs Operating three overlappi ng networks configured with different PAN IDs

Each SHU and its STUs are configured with different PAN IDs so transmissions from
different PANs do not interfere with each other at the upper 802.15.4 protocol stack layers, and
therefore reducing the processing load on each host device.

6.4.1 Addressing
The firmware on the XBee modules is user configurable and the destination address to which
each module transmits can be initially configured on the firmware settings, as well as during runtime.

In this design, the destination address of the end devices (STUs) do not need to change, and
therefore they are configured on firmware to communicate with the SHU using unicast transmiss io n.
The SHU in turn, is configured to broadcasts all packets. In the payload of each packet there is a
number of messages, each one including the STU_id to which they are destined to. When an STU
receives an XBee packet from the SHU, it discards those messages which STU_id do not match its
own and process the STU_id-matching messages.
6.4.2 Communication Protocol
The communication protocol at the application layer comprises four types of messages:
Selection/Deselection, Update, Acknowledgement and Network Discovery.

Each message is delimited by a + character at the start, a ; delimiter between fields and a # to
mark the end of the message. The first field of the messages correspond to the STU_id to which the
message is destined to or it is originated from, the second field corresponds to the SHR_id regarding
the operation in the Selection and Update messages or filled with a single 0 character in the Network
Discovery messages. The last field indicates the type of message: 0 (Turnoff or Deselection), 1
(Turnon or selection), UPD (Update), ACK (Acknowledgement) or NWD (Network Discovery).

Upon message reception, each device processes the message and returns it with the last field
filled with an ACK, in this manner the original sender is notified that the message has successfully
arrived to its destination. If no ACK is received, the original message is resent for a number of times
until an ACK is returned. In the case of the SHU, the software driver resends the messages five times
by default, this value is part of the SHU configuration parameters.

+STU_ID;SHR_ID;SELECTED#

SHU +STU_ID;SHR_ID;ACK#
STU

+STU_ID;SHR_ID;SELECTED# : Notifies the STU which SHR LED indicator to turn on/off.
SELECTED: [1 | 0]

+STU_ID;SHR_ID;UPD#

SHU STU
+STU_ID;SHR_ID;ACK#

+STU_ID;SHR_ID;UPD# : Update message. Notifies the SHU when a SHR has been released from
the tray or when it has been put back on it.
UPD: [cooled | floating] SHU toggles status field when sees UPD sent from STU
+0;0;NWD#

SHU +STU_id;0;0#
STU
+STU_id;0;ACK#
+0;0;NWD# : Network Discovery message. It is broadcasted by the SHU during the Initialization
procedure in order to discover all STUs in range.

+STU_id;0;0# : This is the STU reply to a NWD message, the STU awaits for an ACK after sending it,
if it does not receive it, it resend the NWD reply.

6.5 SHU Software Driver Design

A closed loop lifecycle was used (Figure 37). The chosen lifecycle for the development of the
SHU Software Driver is evolutive and incremental, it enables the progressive introduction of new
components, algorithms and techniques, allowing to correct to possible errors that may arise during
further development and evolution of the system.

The software application running on the SHU is object-oriented. The programming langua ge
used on the final implementation of the SHU Software Driver was Java. It was chosen due to its
multiplatform, compile once, run anywhere philosophy, which enables for code portability to
different hardware platforms in case the future system evolution requires the SHU to run on either a
cheaper or newer hardware platform.

The application on the SHU is not performance-critical on one hand, on the other hand the
Intel Edison, featuring a dual core 500MHz Atom processor is a powerful platform as well as many
of its current competitors, therefore, taking into account the rapid evolution, increasing computing
power and lowering prices on the embedded hardware and Single-Board-Computers available in the
market; Java is a good design choice for this application since it will be highly unlikely to pose any
performance restriction even in the case that the SHU performance requirements tighten up as the
system scales.

The software was developed following the Model-View-Controller (MVC) software design
pattern, which separates which is based in the separation of the data, the control logic and the user
interface in the Model, Controller and View packages respectively. A MVC software architecture
facilitates future design modifications and hardware platform portability by segregating the software
components, optimizing code flexibility and reusability; and minimizing time costs on further
software modifications.

The finalized SHU prototype comprises not only the Software described in this section, by
also a series of configuration steps described in the implementation section regarding the upgrated
Yocto Linux image and packages, database server installation, jdbc libraries, wpa_supplica nt
configuration file for Wi-Fi access and Startup script; as well as files needed by the SHU driver such
as Logfile and Main database connection and credentials file. The independent installation of each of
this components on the Edison board requires an amount of time that makes it unpractical for batch
configuration of several SHUs when implementing the smartlab system on a real laboratory scenario.
For this reason, the SHU prototype is provided as a whole in a compressed system image that can be
rapidly flashed on several boards; ensuring all of them have the same configuration. The software is
designed to completely recreate database objects and retrieve the hardware and network
identifications at every restart of the Intel Edison, except for the Logfile, which is intended to keep a
record of the operation history of the device.

6.5.1 Start-up Linux Script

The SHU driver runs on the Yocto Linux OS as an application. A start-up script was
implemented to run at system boot up and it is in charge of performing the preliminary operations
needed to correctly run the Software Driver and to launch the application. Figure 33 shows the
sequence of operations performed by this script.
 Power-Up & OS Boot-Up

Register Boot Date&Time in

/smartlab/Logfile

Create file and Write Wlan0 MAC

address in /smartlab/thisSHU file

Append Wlan0 IP address in

/smartlab/thisSHU file

Bring mySQLd service up

Execute mysqlcheck autorepair

Launch SHU SW Driver jar

Figure 33 Start-Up Script

During system bootup, the OS takes care of launching all the Linux components as well as
the bringing up the Wi-Fi Wlan0 interface and connecting to the network. The startup script
operations are shown in the figure above.

The bootup event is registered in the logfile located in the /smartlab/ directory, where other
files used by the SHU software as well as the executables are located. The wlan0 MAC address is
registered in a file in this directory and it is used later as the SHU_id which identifies the device on
the database. The IP address is also registered in this directory. As a note, it needs to be mentio ned
that system is designed to use static addressing so the router managing the LAN network assigns an
IP to each Edison based on its Mac Address.

The script also starts the mysql service and runs a table repairing operation over the database
to ensure the mysql.proc table is not damaged and the federated database can be correctly created
during the software initialization routine. Finally, the SHU Software Driver is launched.
6.5.2 Shu Software Driver
The Software Driver is a finite state machine where the transitions depend on the changes in
the status column the SHU table of the database for the record matching the SHU_id of the SHU that
polls the database to check for notifications addressed to it and generated from the user interface in
order to initiate a state transition.

During the Initialization Procedure, the SHU connects to the Main database Server and creates
the database objects in its local database described in section 6.3.4.1. The Status field in the SHU
table determines to which state the SHU needs to switch. The main two alternating states during
normal operation are Observe and Update and they are controlled by the trigger which runs on the
Main database server. As it was described in the database operations, one of the functions of this
trigger is to set the Status field of a specific SHU to update every time a STU under the SHU XBee
network domain needs to be notified to turn on or off any STU tray.

Therefore, when no updates need to be sent to the STU side, the SHU stays in Observe mode,
listening for changes on Status and messages on the XBee interface. When it is signaled to switch to
Update mode, it performs the required operations, restored Status to Observe in the database and
returns to the Observe state.

INITIALIZATION
PROCEDURE
SHU.Status=Observe

OBSERVE UPDATE

SHU.Status=Update

SHU.Status=Reboot REBOOT SHU.Status=Reboot

REBOOT
PROCEDURE

Figure 34 State Diagram of the SHU Software Driver

A third state is meant for handling the required operations to stop the software driver safely
and either shutting down or rebooting the system. These operations take place when Status field is
changed to reboot or shutdown manually from the user interface. In Figure 34 State Diagram of the
SHU Software Driverthese two actions are merged into one single state since the reboot exit
procedure is the same with the only difference of calling a system shutdown or reboot the very end.

6.5.2.1 Software Initialization Procedure

Once the SHU Driver is launched, it executes the initialization procedure. Figure 35 shows
the operations that take place during its execution.

The SHU id, IP Address as well as the IP address, user and password of the Main database are
loaded from the files in the /smartlab/ directory. These files are written during the boot up excepting
MainDBaccess, which needs to be configured manually. If MainDBaccess is not configured, the
software uses a default IP address with root user and no password to attempt a connection to the Main
database, as well as it registering a warning in the log file.

Next, the federated tables and the View described in section 6.3.4.1 are created. Any errors
are registered in the log file and will trigger a failed initialization message at the end of the process,
which in turn, will trigger a system reboot in order to attempt to initialize the system again. If it failed
again, and the SHU was trapped into an endless booting loop, this would be seen from the Main
database and the user interface as an SHU not coming up. Subsequently, the reasons or the failure
could be found on the log file inside the /smartlab/ directory.

Once the local database is successfully created, the SHU registers its IP address and SHU_id
in the database with online status.

On the next step, it executes a Network Discovery in order to find all the STU devices that
are in range, it retrieves their STU_ids and registers them in the database with online status, associated
to its own SHU_id. The Initialization ends by driving the SHU into the Observe state.
 START SHU DRIVER

Stored Data

/Smartlab/thisSHUid Load stored data:

SHU ID
/Smartlab/thisSHUIP
SHU IP address
Main DB IP address
Main DB user and password
/Smartlab/MainDBaccess Log File
/Smartlab/log
Connect to Cloud DB
Create Local Federated Database
SHR Table
SHU Table
ThisSHU View
ToggleSHRStatus Stored
Procedure

Initialization Successful Initialization Error

Record Date, Time and Error Type Error? Record Date, Time and Error Type
Into logfile Into logfile

SHU Table
REBOOT
Register SHU Status = online
Register SHU IP address

STU Network Discovery

STU Table
For each discovered STU_id:
Register STUs Status = online

OBSERVE

Figure 35 Initialization Procedure Flowchart

6.5.2.2 Observe and Update

After successful initialization, the SHU has entered into Observe mode. While in Observe
mode it mainly performs two actions: Listen and Service the incoming messages from the XBee side
and Listen for Update transition orders from the Database (User) side.

Inbound XBee messages from the STU side can be only or UPD or ACK type. UPD messages
may be received at any moment while ACKs are only received after the SHU has sent any messages
to the STU. The SHU maintains a list of expected ACK messages, and resends the unacknowled ged
messages for a predefined number of times before logging an error.

Each time an UPD message is received, the SHU immediately acknowledges it to the STU.
The STU is expected to resend unacknowledged messages in the same way than the SHU does to
enforce message delivery. After acknowledging the UPD message, the SHU proceeds to process it,
updating the database accordingly by calling the toggleSHRstatus stored procedure and using the
Main-local database interface mechanism described previously.

The SHU stays in Observe mode until it finds its status column in the SHU table has been
changed to update. If it is the case, by reading from the ThisSHU view, it finds out which SHRs have
been marked for notification to the STU, and which type of notification is (turnon or turnoff),
restoring this field to nothing as it reads from the SQL view.

The SHU builds a list of SHR objects, where the attributes of the objects implement getters
and setters corresponding to the columns of the SHR table, along with a method to keep track of the
number of transmission retries per SHR message as well as throwing the error file and database
logging on SHU.errormsg column if the maximum number of transmission retries is surpassed.

Next, the SHU builds XBee packets containing the messages generated from the SHR object
list. The maximum number of messages allowed by packet is another configuration (global) variable,
which is intended to provide rapid means of fine tuning the XBee communication against the STUs
during the testing phases by limiting the data streams to avoid buffer overflow and subsequent data
losses at the other side of the XBee interface.

The packets are transmitted to the STUs and the sent messages kept in a list of
unacknowledged messages, which are deleted individually once the corresponding ACKs are
received or in case they reach the maximum number of transmission retries. The SHU restores its
Status field on the database and is now in Observe mode again.

The periodic alternation between the Observe and Update states can only be broken by manual
user action against the database or the user interface. In this case, if the Status is changed to reboot
or to shutdown, the SHU enters the reboot procedure described in the next section.
 INITIALIZATION
PROCEDURE

Retrieve XBee Buffered

data from STU.

Parse data into single

SHR messages.
For Each SHR Message:
yes no
ACK? yes
UPD?
Expecting ACK for no
this SHR? no no Is this SHR under
this SHU domain?
yes
yes

Remove SHR from List Register Error in Logfile Toggle SHR status
of unacknowledged Report error on DB (cooled/floating)
Sent Messages (SHU.error)

Retrieve List of unacknowledged

SHR messages
For Each SHR Object
SHU configuration parameter
Max Number of TX no yes
Retries TX Retries > Max
Retries#?
Remove SHR from List of
Resend SHR msg
unacknowledged SHR messages

Increase SHR individual Register Error in Logfile

messages retries counter Report error on DB (SHU.error)

Poll SHU.Status on
Local DB

no no
SHU.Status= SHU.Status=
update? reboot?
yes yes
Retrieve selected SHRs from LocalDB . REBOOT
(SHR_id,STU_id,LastAction) PROCEDURE

For Each SHR Record

yes SHR.lastAction= no
turnon?

Build individual turnon SHR Build individual turnoff SHR

message addressed its STU_id. message addressed its STU_id.

Restore
SHR.lastAction=
nothing

SHU configuration parameter

Max Number of SHRs Group individual SHR messages into
records per XBee Xbee message and sent to STU
message.
Add sent SHRs to List
SET SHR.Status=observe on DB
of unconfirmed SHRs
6.5.2.3 Reboot Procedure
When the reboot procedure is initiated, the SHU retransmits any pending messages and
listening for acknowledgements until these are received or until the maximum number of
retransmissions is reached.

The reboot event is registered in the log file and the SHU sets the status field of all the STUs
under its XBee network domain to offline in the database, as well as its own status. As the SHU
reboots, these changes can be observed from the user interface.

Next, the SHU Software driver stops, executing a Linux reboot -h command to safely stop all
running services and proceed to system reboot.

In case the status field was set to shutdown, the SHU executes the same procedure described
here with the only difference that at the last step it executes a shutdown -h command. In this case the
Intel Edison board stops and the only way to start it again is by manually powering it on.

START REBOOT
PROCEDURE
For each unacknowledged SHR message

Retransmit pending
unacknowledged SHR
messages.
Increase SHR individual
messages retries counter
Register Error in local Logfile
TX Retries > Max Retries#?
Report error on DB (SHU.error)

Register Reboot Event in Logfile /Smartlab/log

SHU Table
Register SHU Status = offline

STU Table
Register STUs Status = offline

Intel Edison System Reboot

Figure 36 Reboot Procedure Flowchart

7 Implementation

For the implementation section, the work has been divided in five parts: The configuration of
the Intel Edison, the Distributed Database System, the XBee interface, the SHU software driver and
the STU emulator.

In the case of the database system, the work has been performed in two differentiated parts:
A preliminary part, included for configuration reference and Proof of concept on the data
warehousing architecture on shown in Figure 23 using database replication. A second part describes
the database creating and the implementation of the interface between the main and local databases
using the FederatedX engine.

Next step was the implementation of the XBee interface, testing the communication in AT
transparent Mode of the XBee modules, designing a communication protocol and setting up XBee
firmware configuration.

The embedded software on the SHU was written following a Model View Controller design
pattern using Java. Programming the Intel Edison was performed Over the Air on SSH connectio ns
using Eclipse IDE. A Batch script was written to perform a preliminary configuration of the system
at each boot up before automatically launching the SHU Driver.

A STU emulator was written in order to develop and debug the XBee communication and the
database operations performed by the SHU. The STU emulator was used on perform the system
Verification.

7.1 Design and Implementation Workflow

System development was carried out in an iterative manner, following a top-down approach
from the high- level idea, modelling in increased detail each component and system integration during
each iteration.

Each iteration focused in more or less degree on each of the core workflows, depending of
which was the specific goal for that particular iteration. The result at the end of each iteration was
reviewed and some feedback was provided to the next one, enabling in this manner the design to
evolve during the iterative process through continuous refinement.
 Requirements
HW/SW System
Specification

Architecture Design
Component Partitioning

SHU-STU
DDBS SHU
Interface

Specification Refinement
& Analysis

Co-Design
Main-Local DB IFace OS Configuration SHU-STU Comm. Protocol
SHU DB Control Logic XBee STU-XBee
Main DB SHU DB
Handler FSM Controller Emulator

Unit Testing

Integration

Verification

STOP

Figure 37 Development Workflow Chart

The chart above illustrates the development process and the breakdown of the development
for each component of the system on a top-down approach where at each loop iteration the
implementation and integration between different components was further detailed. The followin g
table provides an overview of the tasks carried out at each iteration.

Table 9 System Development Iterations

Preliminay Objectives Study the System requirements and Intel Edison platform.
Iteration Study the 802.15.4 RF hardware options available for the on
market and choose one according to compatibility with
Edison and requirements on SHU-STU interface.
 Determine SW components needed to implement the
DDBMS
Get Intel Edison board up and running.
Results Yocto Linux Image flashed and configured on Edison board.
Hello World and Wi-Fi configuration written in C on
Arduino IDE
Feedback Hardware RF components chosen:
XBee 802.15.4 S1 Module.
XBee Arduino Shield.
Software components chosen for DDBMS:
WAMP Server Stack (MySQL, Apache, PHP) on
Main Server.
MariaDB Server on Local DB (Edison).
MySQL Connector C library for Arduino (third
party).
MySQL workbench for managing Local/Main DBs
DDBMS will implement DB replication.
Iteration Objectives Set up the Local and Main Database servers
1 Create a sample DB for testing.
Test DB access using MySQL Connector C library to Local
and Main Databases.
Write a PHP snippet for DB access from a remote Web
client.
Configure and test DB access over WAN.
Results Coded access to local and Main DBs using C libraries is
successful after fixing privilege conflicts.
DB access over WAN-simulating configuration works.
Feedback Users will be set to default root with no password until
achieving first operative version of the system.
Iteration Objectives Set up Database replication (Master)-> (Slave)
2 Test the operation
Results DB updates successfully replicated from Master to Slave
Feedback DB network traffic needs to be optimized.
Iteration Objectives Investigate feasible configurations to minimize unnecessary
3 DB network traffic.
Study XBee module firmware configuration.
 Determine XBee firmware configuration according to
requirements
Research XBee libraries compatible with Intel Edison
Test XBee communication
Results Federated DB engine is feasible in MariaDB for providing
local data availability without network overhead.
Not possible to configure XBee firmware from PC using
Edison Arduino breakout board.
AT Transparent communication mode is chosen for the
SHU-STU interface
Intel UPM Java XBee libraries are chosen.
Feedback XBee USB adapter will be used for firmware configuration
and for XBee communication development and debugging.
Programming language is switched from C to Java
Eclipse IoT IDE will be used for SW development and OTA
programming.
Iteration Objectives Design the DDBMS, DB schema on the Main MySQL server
4 and Federated DB on Edison (Local) MariaDB server.
Produce DB creation and bulk data loading SQL scripts.
Test Replication operation.
Results A definitive DB schema for the Main DB is designed and
implemented.
Top-level design of the interface between the local DB and
the SHU SW is defined.
Federated DB is working on MariaDB but triggers cannot be
reliably implemented on a Federated DB engine.
Feedback Need to find alternative to triggers
Iteration Objectives Install J/Connector lib. on Edison and test DB access
5 Test XBee communication on Edison using UPM java libs.
Research DB alternatives to Federated tables.
Results DB access and XBee communication working.
Feedback Trigger need to be moved to Main DB
Database Schema needs to be modified to support the local
database operations.
Iteration Objectives Design the XBee communication protocol on the SHU-STU
6 interface.
Implement the Main-Local database interface
 Develop a STU Emulator to respond to XBee messages.
Test the XBee Communication.
Results XBee protocol is defined.
Trigger is working on the Cloud DB, using flags to control
the behaviour of the SHU upon database changes.
STU Emulator is working using Intel UPM libraries and
communication tested injecting packets from the USB
adapter.
Feedback The size of the XBee packets needs to be controlled
Iteration Objectives Design and implement the Software on the SHU.
7 Integrate components and test SHU operation.
Perform preliminary operational tests.
Study available options to optimize SHU SW performance.
Results SHU software controller is implemented.
Operation for Use Case 1 and 2 is tested manually.
Size of XBee packets is implemented as a configuration
variable.
On-board MCU is a feasible way to implement a soft-real
time system using Inter Process Communication.
Feedback Operation testing for high number of selected samples to be
performed.
XBee Interface to be managed by MCU on C.
Iteration Objectives Write a Start-up Script for Use Case 3.
8 Develop a STU emulator to test the SHU operation and
massive data transfers.
Study how to use IPC on ttymc0 or a Producer-subscriber
implementation between the MCU and the Linux Application
Make the MCU run the XBee and separate the XBee
interface Listening function from the Java Application.
Results STU emulator is up and running
Start-up bash script is developed
Unsuccessful results while trying to run the XBee from the
MCU by interfacing ttyMFD1 only garbage returned.
MCU access to ttuMFD1 seems to block the resource making
it not possible to use it to send from Java.
Feedback Extremely scarce documentation regarding the Intel Edison
MCU development. No XBee example code or XBee
libraries.
 XBee will be managed by the Java application.
Iteration Objectives Verify all use cases on the SHU against the STU emulator.
9 Results Timeouts and Buffer sizes used by the XBee libraries were
fine tuned.
A problem was encountered in the XBee listening function,
missing ACKs from the STU. Separated XBee functions for
use during observe and update states developed using
different timeouts.
Feedback SHU meeting Use Case operation requirements against the
STU emulator and Databases.

The following graph shows the amount of work performed for each inner workflow
throughout successive iterations during the development.

Table 10 Breakdown of the development process in terms of amount of work

Iteration Preliminary 1 2 3 4 5 6 7 8 9

Requirements
CORE WORKFLOWS

Analysis

Design

Implementation

Verification & Testing

Workload
- +
7.2 Intel Edison Configuration

7.2.1 Installation of USB drivers

In order to be able to connect the Intel Edison breakout boards to the computer, it is required
to install the FTDI drivers and install the Intel Edison Device USB driver, which installer
automatically sets up all required drivers (RNDIS, CFC and DFU).

Once these drivers were successfully installed, it was possible to see the Intel Edison as a
new drive in Windows file manager when connecting the board to the computer using the two USB
cables (with the switch heading towards the Micro USB socket).
7.2.2 Serial Communication and Terminal Set-Up to the Edison board
The terminal provides direct access to the Linux environment, enabling the user to receive
messages on the screen and provide keyboard input from the PC to the Edison board.

In the Edison board, console UART communication from the compute module is converted
into Serial to USB by a FTDI chip on the breakout board. Serial communication can be established
by connecting the Edison board to a PC by its micro USB OTG port and using a SSH/Telnet client
such as PuTTY. The COM port that needs to be selected in order to set up PuTTY is found in the
Device Administrator tree under the name USB Serial Port; another COM port appears Intel
Edison Virtual Com Port when both Micro USBports are connected to the PC, this port is used
during OS image flashing and providing power support to the board.

Figure 38 Using PuTTY to establish console communication.

As it is shown in the figure above, the USB Serial Port used in this case corresponded to
COM10, which was set to the Serial Line field in PuTTY and the speed was set to a baud rate of
115200 bps (8N1 notation is assumed). Session configuration was saved to posterior connections.

7.2.3 OS Image Flashing

The Intel Edison boards come from factory with a preinstalled version of Yocto Linux,
however, Intel recommends downloading and flashing the boards with the latest image available of
the operating system. Intel provides a compiled image of Yocto Linux as well as its source code
available for download from its website.

Yocto Linux image is provided in a compressed file; which contents were extracted on the
Intel Edison. It was recommended to previously delete all files contained on the Intel Edison drive
found in Windows file manager in order to remove existing old OS image.

Once all image files were extracted, by establishing a serial connection using PuTTY, a shell
was opened on the board; the execution of reboot ota command triggered a system restart and
subsequent installation of the new image.

Figure 39 First boot of the Edison board on updated Image

7.2.4 Wi-Fi Setup

Initial configuration of the Intel Edison board is performed by the configure_edison setup
command, which allows for a several configuration options,
 Figure 40 Options for the configure_edison command
Wireless network connection configuration was performed by executing the configure_edison
wifi command; it lists the available wireless networks and prompts a menu asking to which of them
connect. In this case, network number 9 was selected, then it asks for the password and connects to
it.
 Figure 41 Available Wi-Fi networks configure_edison wifi
Upon successful connection, the IP address of the board is displayed and its domain name.
Wi-Fi configuration can be checked with the wpa_cli > status command, as shown in Figure 42

Figure 42 Wi-Fi network configuration

If Wi-Fi connection problems are encountered, it can be solved by bringing down and up there
wlan0 interface.

ifconfig wlan0 down

 ifconfig wlan0 up

The boards were named Edison1 and Edison2 using configure_edison name. The board
automatically sets an http server once connected to the network. Figure 43 shows a screenshot of a
successful http connection to the device over LAN to http://edison.local

Figure 43 Http connection to Intel Edison over LAN

It was necessary to disable DHCP and configure a static IP address in the Intel Edison. All
the implementation of this project is based on static IP addressing. Static addressing was configured
on both the router by binding a MAC address to a specific IP address, and in the Edison board by
editing the wpa_cli-actions.sh script, which is located in the /etc/wpa_supplicant/ path; commenting out
the line starting with udhcpc, and adding a new line to manually configure the IP, as shown below.
Built- in Yocto text editor vi was used for this purpose.
if [ "$CMD" = "CONNECTED" ]; then

kill_daemon udhcpc /var/run/udhcpc-$IFNAME.pid

#udhcpc -i $IFNAME -p /var/run/udhcpc-$IFNAME.pid -S

ifconfig $IFNAME 192.168.0.12 netmask 255.255.255.0

route add default gw 192.168.0.1

fi

Snippet 1wpa_cli-actions.sh configuration for static addressing

The configuration is remembered by the system so that the board is able to connect
automatically to the WLAN in successive reboots. The picture below shows the device connected to
the wireless network just after a reboot.
 Figure 44 Intel Edison automatically connected to network after system boot.

7.2.5 Configuration of SSH connection for Over-The-Air Programming

Besides USB connection, interaction with the Edison board can be done remotely via SSH
over Wi-Fi. In this way multiple remote connections can be established to several boards at the same
time in order to perform Over-The-Air (OTA) programming and transfer files over SFTP: Enabling
to reprogram the SHU devices without need for physical access to them as long as they are powered
and connected to the wireless network.

In order to enable SSH over WiFi it is necessary to take the USB0 interface down and set a
device password and connect to the wireless network.
ifconfig usb0 down
ifconfig wlan0 up

configure_edison setup

By default, the SSH service on the Edison board is configured for access through the OTG
USB interface on 192.168.2.15 and if needed, can be changed to a different range by editing the
usb0.network file:
 Figure 45 Editing usb0.network file for SSH connection to the Edison board

Security is configured so SHH connections cannot be established if a device password is not

set on the device on /etc/ssh/ssh_config, this was changed by editing the file and uncommenting the
line #PasswordAuthentication no. Device password was changed using the passwd command.

Using no passwords erases the neccesity of typing them each time that that the code needed
to be compiled on the board or it needed to be accessed to modify any configuration.

Table 11 Login credentials used for SSH Access to the Intel Edison Boards

Device name Address Login Device password

Edison1 (SHU) 192.168.1.101 root -
Edison2 (Emulated STU) 192.168.1.104 root -

Software development was carried out using the Eclipse IDE provided by Intel for
development on the Intel Edison and Galileo boards. It includes the native libraries used by the boards
and a collection of Java UPM sensor libraries based on the libmraa low-lewel skeleton for Linux-
based hardware platforms.

Figure 46 Remote connection to Edison for OTA programming using Eclipse Intel IoT IDE
7.2.6 Backing-up of the Edison Image
Configuration and installation of all the required components takes a significant amount of
time. In order to be able to duplicate this process with less effort in multiple boards, an image of the
configured operative system is provided, including the start-up script, the database server and the
software driver.

For this process a 4GB micro SD card, was used. In first place, the root password needed to
be disabled by using the command passwd -d root; next, by inserting the card into its slot on the
breakout board and rebooting the system, the SD card was automatically detected and mounted. The
Linux command dd, enables to copy and convert data at low level and it is used for making backup
copies. It was run on the shell with as follows:

Figure 47 Backing up Edison image

Where if contains the path from which data will be copied and of the path to the mounted SD
card, along with the backup filename. Likewise, in order to copy this image into another board, it was
done by executing the dd command as follows:

Figure 48 Loading cloned Edison image

7.3 Database
Database development and implementation was divided into two differentiated phases, a
preliminary part where the database servers were configured and tested as well as replication was
tested in the embedded MariaDB server as proof of concept. The second part focused on the creating
of the database to support the Smartlab system operations, and the Main-local database
interconnection using the FederatedX engine on MariaDB.

In the preliminary part of the database implementation section, a remote server and a
MySQL database were installed on a WampServer in a personal computer while the local MySQL
database was installed on the Intel Edison board using MariaDB. Communication was routed over
LAN, while also testing connectivity through the external interface of the router and configuring the
system to simulate a scenario where connection takes place over the WAN. A simulated remote
client was included for testing and troubleshooting connectivity within the two endpoints as it will
be explained in detail within the following section. The aim of this part was to perform connectivity
tests over the WAN and tests for database replication operation between a MySQL Main DB and
the MariaDB database in the Intel Edison and to show the feasibility of a remote replication set-up
using MariaDB in order to implement data redundancy and failover protection on the system. This
preliminary part, includes the tests carried out and the results obtained during this process.

On the second part of the database implementation, a full database schema for the whole
Smartlab CPS was designed. This DB is intended to provide support not only for the operation
described in this thesis but across the entire CPS system integrating other devices. The FederatedX
engine was used to proxy SQL queries from the SHUs to the main database. The Federated database
interface between the main and local server was designed in order to rely completely the
communication on the database without needing to open additional sockets for notifications between
the user interface and the SHUs.

7.3.1 Preliminary: Database Installation; Remote Access and Replication

Configuration and Testing.
The configuration steps and tests and results described within this section are included for
reference as well as to show the feasibility for the implementation of a replication set-up to a Cloud
server using MariaDB and the Intel Edison; as shown in the distributed database architecture on
Figure 23. The final implementation of the system in the Verification and Results section, while it
relies on the federated engine interface between the local and main databases, it does not include the
replication set-up described in this section.

Two sample MySQL databases were initially implemented, one of them stored locally in the
SHU and the other in the remote server. The SHU database stores information about all the STUs
devices within range and mirrors the remote database so both of them contain same data.

For demonstration purposes a simple database was created, consisting of one table which
respectively consists of the following fields: node ID, a timestamp, long address and short address.
 Please note that this section is intended for configuration reference and the IP addresses that
were used during this section are different from the addresses used on section 7.3.2, the addresses
found on the latter section correspond to the actual system implementation.

7.3.1.1 Creation of a Test Database

The database created first on the Main server, named smartlab and it was written using
MySQL Workbench, this software allows for more comfortable SQL scripting and ease of
management of a more elaborated database which was implemented during posterior development of
this project.

WampServer is a software stack comprising PHP, MySQL and Apache web server, it was
used to mount the daemons on a personal computer; enabling testing of database connectivity from
the Apache Web server using a Web Browser and PHP, all within the same machine.

The SQL script shown in Snippet 2 was used to create the database table Nodelist in smartlab
database on the Main server. The same script was used on local database in the Intel Edison board to
create a replica of Nodelist table, in this case, running the script from the MySQL console. The
information corresponding to four fictitious nodes was inserted into the table in order to test the
functionality of SQL queries within the SHU, the remote server and a remote client, as it will be
explained in later sections.

The primary key for this table is NodeID set to increment its value automatically with each
node addition to the table. The fields of the table are all set to not null because the MySQL connector
library, used to program the SQL calls from the SHU, checks for null fields as a break condition for
the row reading loops, if any field was left null, even there was data left within the same row; this
would cause this data not to be read.
create database smartlab;
use smartlab;
create table NodeList (
NodeID int not null auto_increment,
Node_address varchar(16) not null,
Node_short_address varchar(4) not null,
NodeType enum('SHU_Coordinator','SHU','SHR','SHR2') not null,
Time_since_registered TIMESTAMP not null,
constraint pk_NodeID primary key(NodeID)
);

insert into NodeList(NodeID,Node_address,Node_short_address,NodeType,Time_since_registered)

values(1,"00124b0001fe4881","af5b","SHU_Coordinator", CURRENT_TIMESTAMP);

insert into NodeList(Node_address,Node_short_address,NodeType,Time_since_registered)

values("00124b0001fe5246","db7c","SHU ",'2015-11-30 00:00:00.0');

insert into NodeList(Node_address,Node_short_address,NodeType,Time_since_registered)

values("00124b0001fe7563","01fe","SHR",'2015-11-30 00:00:00.0');

insert into NodeList(Node_address,Node_short_address,NodeType,Time_since_registered)

values("00124b0003fe8525","03fe","SHR2",'2015-11-30 00:00:00.0');

insert into NodeList(Node_address,Node_short_address,NodeType,Time_since_registered)

values("00124b0003ff8538","03ff","SHR",'2015-12-11 00:00:00.0');

Snippet 2 SQL script for creating Nodelist test table

7.3.1.1.1 MariaDB installation

The MariaDB package was installed using the OPKG Package manager in Yocto Linux on
the Intel Edison board. Prior to installation the opkg repository needed to be updated prior by running
the command opkg update. The MariaDB package was downloaded with the opkg install MariaDB
command.

The following lines were added in the file /etc/opkg/base-feeds.conf in order to fetch the
installation packets from the correct repository for the Intel Edison board.

===/etc/opkg/base-feeds.conf contents below===

src/gz all http://repo. base-feeds.conf opkg.net/edison/repo/all
src/gz edison http://repo.opkg.net/edison/repo/edison
src/gz core2-32 http://repo.opkg.net/edison/repo/core2-32
===end of /etc/opkg/base-feeds.conf contents===

Snippet 3 Repository update in base-feeds.conf file

To start the MySQL service, the command systemctl start mysqld.service was run and to check
that the service is running: systemctl status mysqld.service. This last command should display the
following messages in the Edisons console:
 Figure 49 Message of MariaDB is up and running

7.3.1.1.2 Database creation in MariaDB

MariaDB is compatible with MySQL. MariaDB console is accessed by the mysql command.
Once in the mysql console, a new empty database called smartlab was created by running the
command create database smartlab.

Once an empty database was created, the following step was to clone into it the same Nodelist
table that was created on the Main server database by using the same SQL script (Snippet 2). Since
the PuTTY client allows for copy/paste functionalities, this step was simplified by copying into the
MariaDB console the whole script used to generate the NodeList table in the remote server.

By running the describe No delist SQL command, MariaDB console displayed the structure
of the table after it was created.

Figure 50Structure of NodeList table in MariaDB database

As Figure 50 shows, it has exactly the same structure than the NodeList table in the remote
server, shown in the next figure.
 Figure 51 Structure of NodeList table in the MySQL database on the Main server.

In the same manner, the NodeList table was populated with the same contents, the following
figure shows the displayed results for a Select * from NodeList command.

Figure 52 Contents of NodeList table in MariaDB database.

7.3.1.1.3 Configuration of MariaDB for access from a remote client

On the default configuration of MariaDB, packages are bind to the local loopback IP address
127.0.0.1 by default as a security measure. In order to enable remote connections to the database,
default configuration needs to be modified in the defaults file, which is located in /etc/my.cnf

For doing this, it is necessary to edit the file my.cnf, comment the lines showing the skip-
networking and bind_address commands and restart the MySQL daemon by running the systemctl
stop mysqld.service and systemctl start mysqld.service commands.
 If skip-networking is enabled, the server rejects all connections excepting those coming from
localhost as well as preventing remote slaves from replicating the database. If bind_address is
enabled; in a similar way, the server only listens for connections in the local loopback 127.0.0.1

7.3.1.1.4 Configuration of user connection privileges from remote hosts

In order to accept incoming connections, it is necessary to add a user with privileges to connect
to the server from a remote address. This is done from the mysql command line client as follows:

grant all privileges on *.* to 'root'@'%' identified by '' with grant option;

A root user that could connect from anywhere was created in this way, where % is a wildcard
from its IP address and no password is set. This way allows for easier troubleshooting during the
development within the scope of this thesis work. After the operation of the system is validated and
SHUs are deployed, users, privileges and allowed IP addresses should be configured accordingly.

Once the root user is added with remote connection privileges, it can be confirmed by running
a select over the user table as shown in the figure below.

Figure 53 Users table of MariaDB database

7.3.1.2 Main Database configuration on WAMP Server

7.3.1.2.1 Configuration of WAMP Server

Most of the configuration parameters for WampServer can be set in at the httpd.conf
configuration file. For security reasons, the default configuration of WampServer restricts incoming
remote connections. In order to configure it for accepting external connections, the following lines
within the< Directory> tags were modified as follows, the third line set an allow rule by which if a
client does not match any of the allow or deny rules, is not granted access. The fourth line allow any
client to access the server. For security, this needs to be restricted on the Main database server to only
a group of permitted clients.

<Directory />
Options FollowSumLinks
 AllowOverride ALL
Order allow, deny
Allow from all
</Directory>

Snippet 4 httpd.conf enabled remote access settings

The default port used by WampServer is 80 (Http), in order to avoid conflict with other
software running in the computer that this project was developed, the port was changed to 8080
(Https) by replacing the line Listen 80 to Listen 8080 in httpd.conf

Having configured port forwarding on the router, the last configuration was to allow the
WampServer to be reachable from the internet by changing the line ServerName localhost:80 to
ServerName 192.168.0.13:8080, which corresponds to the private IP assigned to the MySQL server
and the https 8080 port.

7.3.1.2.2 Configuration for remote access PHPmyAdmin

On WampServer, the configuration of user privileges can be don either from the command
line, MySQL workbench or by using the PHPmyAdmin interface. In order to grant privileges to
remote clients for incoming connections two new entries needed to be added as shown in the last two
rows of the following figure. One for access within the LAN and another for connections over the
internet. In the first case, all privileges were granted while in the second case only select, insert and
update queries were configured to be allowed.

Figure 54 Configuration of users privileges

Troubleshooting this part of the work was problematic when trying to programmatically query
the remote server from the Intel Edison board, having apparently configured correctly the user
privileges and tested the port is open when making connection, no results were returned while the
execution of the code in the Intel Edison seemed to have stopped, debugging to library- level was
performed by using the serial monitor for print feedback. The execution was found to get stuck inside
a packet reading loop within the read_packet() function of the MySQL connector library for Arduino.
Wireshark network analyser was used to capture the returned packets from the host after the query
from the SHU. It was found that the host returned garbage characters along with a warning message
as this: 5.6.17-U;fq(oy1%fSLc/]go y0"!#08S01Got packets out of order.

After some research it was found that this was due to an access denied message, and the reason
for this was an incorrect configuration of the user privileges because entering a new user with
Host=% as a wildcard in order to grant access from any, however in the user table already existed
a Host=localhost entry, which is more specific than the wildcard %, and therefore, MySQL used it
in preference than the new entry.

User configuration shown in Figure 54 worked as intended, granting access to the database
from 192.168.0.13 (WampServer machine) and the external router interface 80.99.120.253

Privileges for were set to Select. Insert and update. Both privileges and users need to be
changed on further implementation when implementing security purposes.

7.3.1.3 Router Configuration

The system requirements demand that the local databases on the SHUs need to be accessible
over the internet.

During this first stage of the development, implementation and testing was done within a
Local Area Network; in order to simulate access from a remote client over the Internet to the Main
server (Figure 58) or the SHU DB server (Figure 60Figure 56); all inbound connections were
addressed through the external interface of the router and using port forwarding, making in this way,
both the SHU and the SQL server, accessible from the internet while simulating the a scenario where
both of them would communicate over the Internet.

In order to allow incoming connections from the external interface of the router to devices
connected in the local area network, it was necessary to open the required ports and forward them to
the intended devices; 3306 (SQL) and 8080 (Https) for the databases and running the PHP test code
respectively.
 Figure 55 Port forwarding configuration on a Technicolor TC7200 router.

Once this configuration was set in the router, it was possible to check it from the Edisons
console by running the following netcat command (syntax: nc host port): nc 192.168.0.13 3306 or
alternatively using telnet (syntax: telnet host port): telnet 192.168.0.13 3306 If a connection refused
message is returned, this means that the port is closed, similarly for https.

Due to the reduced set of features of the Technicolor TC7200 home-type router used for
setting up this testing topology, port forwarding had to be changed from 192.168.0.13 (WampServer)
to 192.168.0.12 (SHU, Edison) on each test depending on which sever the inbound connectio ns
wanted to be addressed to.

7.3.1.4 Test of Database access over simulated WAN configuration

The PHP snippet shown in Error! Reference source not found. was written for testing the q
ueries to the Main and Local databases. Since the tables on these databases will be replicated, share
the same structure. This script was used to query the contents of Nodelist table on both databases.
.

<?php
echo "Connecting to DB..<br>";
$link = mysqli_connect('127.0.0.1:3306', 'root', '');
$query = mysqli_query($link,"use smartlab");
$SQL_command="SELECT * FROM NodeList" ;
if (!mysqli_query($link,$SQL_command)) printf("ERROR\n",
mysqli_error($link)."</br>");

$result = $link->query($SQL_command);
//printf("%s",$result);
if ($result->num_rows > 0) {
// output data of each row
while($row = $result->fetch_assoc()) {
echo "NodeID: " . $row["NodeID"].
" / Node_address: " . $row["Node_address"].
" / Node_short_address: " . $row["Node_short_address"].
" / NodeType: " . $row["NodeType"].
" / Time_since_registered: " .
$row["Time_since_registered"]. "<br>";
}
} else {
echo "0 results";
}

mysqli_close($link);
if (!$link) die('Connection closed');
?>

Snippet 5 smartlab.php run on Apache server to test DB connectivity from a Web browser.

This script especially useful for troubleshooting connectivity configuration issues, since that
just by changing the IP address on line 3, it allowed for rapid connectivity testing to any of the two
databases within the LAN, the remote server (Figure 58) or the SHU (Figure 60). By starting a
connection from a remote client to any of both sides, it simplified troubleshooting, since duplex
communication is desired between both sides (Figure 56); and allowed for simulating the real scenario
in which the connection to the Main database is required to take place over the internet by substituting
this address by the IP address of the WAN interface of the properly port forwarding-configured router
(80.99.120.253). For simplicity configuring users and privileges, users were left to root in both
databases with no password during the all the implementation.
 Figure 56 Desired bidirectional communication over simulated WAN within the SHU and remote server, and
from the SHU to itself (NAT router needed).

During this stage of development, the Main and the local SHU databases are running within
the same Local Area Network, the php script described previously was used to test that the database
connections over the internet could take place correctly.

In a real scenario, at least two routers would be used as shown below, each one would be the
gateway of its respective network, and all database connections would be addressed to their WAN
interfaces.
 Figure 57 Equivalent topology for the implementation of the SQL databases

This test was performed in two parts. Both parts were performed initiating the connection
from a web client in the same manner that the LIMS User Interface would use a webpage hosted on
a web server (Apache server), upon request, the php script containing the IP address of the WAN
interface of the router is executed on the web server, which sends a SQL query, the router redirects
the connection according to its port forwarding settings. The port forwarding settings were modified
on each test to redirect the query either to the Main database or to the Local database.
 Figure 58 Simulating SQL queries over the WAN from a client to a remote server within the same LAN

On the figure above, the router was configured to forward incoming connections on the 3306
(muSQL) port from the WAN interface to 192.168.0.13, which is the address of the PC, where
WampServer containing the Main MySQL server was installed. The results of the query are send
back to the web client following the return path and displayed on the web browser as shown below.

Figure 59 Results of a remote SQL SELECT query to NodeList table

Once the access to the Main DB was confirmed, the port forwarding configuration on the
router was modified in order to redirect the packets to the SHU. The aforementioned test was
performed throwing the same results as shown in Figure 59
 Figure 60 Simulating SQL queries over the WAN to the SHU from a remote client within the same LAN.

7.3.1.5 Database Replication

Database replication provides availability increase and data safety by data redundancy, which
in the event of data losses in any database, recovery could be performed automatically and rapidly.
In the case of any of the database servers coming down during operation, the mirror server would
take the role of the downed server and bring its copy of the data online, this is known as automatic
failover.

In database replication, two copies of the same database are stored in two different instances
of an SQL server, the database replication between these servers is started by what is called database
mirroring session.

During a database replication session, the main server acts as a hot standby server, cooperating
with the principal server as partners and playing complementary roles, every insert, update or delete
action on the principal server is replicated on the mirror server and registered in a logfile.[27]

7.3.1.5.1 Replication Master Configuration

 For configuring the master, binary logging must be enabled and the server must be assigned
to a unique server ID. Binary loggings is the basis replicating database modifications from the
principal server (master) to the mirror server (slave). Binary logging can be activated by editing the
configuration file my.cnf on the MySQL server within the [mysqld] section of the file, the lines were
changed to this:

[mysqld]
log-bin=mysql-bin
server-id=1
innodb_flush_log_at_trx_commit=1
sync_binlog=1

Snippet 6 Master server replication configuration on my.cnf

Where the second line corresponds to the binary log basename in order to generate binary log
files. The third line gives the master server a unique id of 1. If the id was explicitly set to 0, the master
server would automatically reject all connections from slaves. All servers, whether on master or slave
configuration must be assigned a unique id. The last two lines ensure the best durability in the
replication when using InnoDB database engine. After saving the changes, the server was restarted
to make the new configuration effective.[28]

It was necessary to create a user account for the slave in the master server so it could use it to
connect to its master; although an existing user could be used, for security reasons it is best to create
a new user since the replication username and password are stored in plain text in the replication log
file of the slave server, which could potentially compromise the master server. Creation of a replicant
username with replipass password and grating it access rights on the master was performed from the
MySQL console, using the following commands:

create user replicant@'%' identified by 'replipass';

grant select, process, file, super, replication client, replication slave,
reload on *.* to replicant@'%';
flush privileges;

Snippet 7 User creation and privilege granting on replicating slave

After creating the new user and granting privileges, it can be checked that it has been correctly
added from the mysql.user table as shown in the following figure.
 Figure 61 Replicant user added on master MySQL server, granted access from any host.

7.3.1.5.2 Replication Slave Configuration

On the slave it is not necessary to enable binary logging although if enabled, it could be used
for crash recovery or backups or if it was part of a more complex topology where while being the
slave, it also behaves as the master of several other slaves. This is noted for possible further
implementation out of the scope of this thesis, depending upon evolving design requirements.

In a similar way than done previously, the slave must be assigned a unique server_id by editing
/etc/my.cnf, in this case it was given the id of 2.
[mysqld]
log-bin=mysql-bin
server-id=2

Snippet 8 Slave server replication configuration on my.cnf

In order to prevent changes on the data while reading the binary log position, the slave needs
to be informed exactly at which position it should start the replication. This was done at the master
server by flushing and locking the table and then getting the current position on the MySQL console
by the commands Flush tables with read lock and Show master status.
 Figure 62 File and position details of the master status

To create a data snapshot of the database:

Mysqldump all-databases master-data >dbdump.db

Note in Figure 62 that the binary logging field is blank since it has just been enabled. The file
and position fields show the name of the log file and position within it, which are mysql-bin.000001
at position 832. These values represent the coordinates at which the slave should start replicatio n
from the master. At this point, having the lock set, it is possible to copy the tables and afterwards
release it using the unlock tables command. This step had only demonstrative purpose since both
databases already contain the same data the so-called raw data snapshot or data dump from the master
was not performed. At this point it is possible to start the replication process.[28]

In order to start the replication, the following command was run in the slave console, the
master address, password, username, port, logfile, position, and retries are set on in:
CHANGE MASTER TO
MASTER_HOST=192.168.0.13, Master IP Address
MASTER_USER='replicant', Replication user name
MASTER_PASSWORD=replipass, Replication password
MASTER_PORT=3306,
MASTER_LOG_FILE=mysql-bin.000001, Recorded Log File (see master)
MASTER_LOG_POS=832, Recorded Log Position (see master)
MASTER_CONNECT_RETRY=10;

Snippet 9 Replication settings command on slave

Once the previous command was successfully executed, the slave was started by listening the
start slave command. The Load Data from Master could be run to retrieve data from the remote server
but this was not done as at this point both databases contain the same data.

7.3.1.5.3 Replication testing

 At this point, both the master server running a MySQL database in the remote WampServer
and the slave server running the MariaDB database in the Intel Edison are properly configured and
the mirroring task is running.

In order to check that replication is correctly working, a row insert was issued on the MySQL
server simulating the network discovery of a new node in the ZigBee network. Following this, two
select * from Nodelist statements were run over both databases on the remote server and SHU
respectively in order to check if the new added row to Nodelist table was successfully mirrored to the
SHU MariaDB database.

The insert statement for the new simulated node in the MySQL database was the following:

INSERT INTO
NodeList(NodeID,Node_address,Node_short_address,NodeType,Time_since_registered)
VALUES(5,"00124b0003ff8538","03ff","SHR",'2015-12-11 00:00:00.0');

Snippet 10 SQL table insert statement to test replication

Next, the insert statement mentioned above was issued over Nodelist, as shown in the figure
below; a new row for NodeID =5 was successfully added in the remote server.

Figure 63 simulating a network discovery-triggered insert event into the remote server

Next, the same select statement was run on the MariaDB console of the Intel Edison, showing
that the new row was successfully replicated from the MySQL NodeList table, corresponding to the
new simulated node with NodeID=5.
 Figure 64MariaDB database on SHU side successfully mirrored upon insert event on remote server side.

At this point, it was confirmed that the Intel Edison or SHU is replicating the database stored
on the remote server. Every modification made over the remote server is being mirrored into the SHU,
proving a correct failover functionality. Note that the communication is addressed through LAN since
the router used for developing this individual project has no NAT functionalities, however, as it was
shown in the previous sections. The configuration was proven to work successfully over WAN in
both directions just by changing the port forwarding settings accordingly and with the aid of the
remote client calling the php code.

7.3.1.5.4 Implementation of coded Wi-Fi configuration, management of SQL databases

and test of replication functionality.

In this section it is be shown how the Intel Edison was programmed in C language using the
Arduino IDE and the MySQL connector and Wi-Fi libraries in order to access both MySQL and
MariaDB databases and test the correctness of the whole project implementation.

The first step was to code a C program that would allow the Intel Edison to connect to a Wi-
Fi network automatically. The libraries needed for this purpose were Wi-Fi and Ethernet which are
built-in into the Arduino IDE. Status messages are sent through the serial interface to the serial
monitor of the Arduino IDE by using the Serial.println() and Serial.print() functions, this is very
helpful for debugging since the Intel Edison Arduino expansion board has no display. Serial
communication is started by the Serial.begin() function, which is part of the SPI library and the baud
rate is set to 115200, same than used for PuTTY client interfacing in previous sections.

The Wi-Fi connector is instantiated by Wifi.begin() which requires the networks SSID and
password as arguments. It would return an error if connection was faulty.

The MySQL connector library for Arduino[29] does not come integrated in the IDE
environment and was downloaded and installed from a third party. The Connector class provides
methods for managing the SQL session, querying and result management among others. Special
caution needs to be taken when dealing with large tables, by performing segmented queries and
deallocate memory periodically within the same queries in order to avoid buffer overflow.

Usernames and passwords in both the MySQL and MariaDB databased were set the same for
simplicity while testing during this first part of the project.

The code written in the Arduino IDE to program the Intel Edison board was written in three
separated sections. In the first part, it connects the Intel Edison to the Wireless network, then it
establishes a session to the remote SQL database and performs a SELECT query over the NodeList
table, displaying over the serial monitor the returned results. Figure 65 shows the returned results
after running this code.

Figure 65 Serial monitor output of programmatically querying MySQL Nodelist from the SHU

The code could be easily modified to connect to either of the SQL databases. The following
picture shows the serial monitor after connecting to the local database stored in the SHU. Note that
both databases are mirrored and contain the same rows.IP addresses and server versions identify each
database.
 Figure 66Serial monitor output of programmatically querying MariaDB Nodelist from the SHU

Once the SELECT queries were checked to operate correctly, INSERT queries were
implemented in the code, the following query was implemented, simulating the addition of a new
network node and automatically both, setting the timestamp from the real system time and assigning
the auto increment node_id field.

INSERT INTO NodeList(Node_address,Node_short_address,NodeType,Time_since_registered)

VALUES("00124b0002aa8521","02aa"," SHR",CURRENT_TIMESTAMP);

The following figure shows the serial monitor output after the SHU has connected to the
remote MySQL database, querying the table NodeList and performing an INSERT. Then it connects
to the local MariaDB database and runs a SELECT query to verify that the table replication has been
effectively performed on the server side. However, the inserted row is not present in Error! R
eference source not found.. This was found to be due that the slave had stopped replicating the
master database. Therefore, it was found that when uploading code from Arduino IDE into the Intel
Edison, the SQL mirroring service stops. This issue left unsolved in order to make programming the
device from the IDE compatible with database replication, and due to the fact that final SHU software
development was carried out in Java language. An alternative solution to this issue was to copy the
source code into the Intel Edison and compile it using gcc instead of doing it from Arduino IDE.

7.3.2 Final database Implementation. Federated Tables.

SQL scripting for database development and testing was mainly performed by using MySQL
workbench. This database management system does not only provide a friendly interface for SQL
coding but also for simultaneously accessing different database servers and managing users and
privileges.

Figure 67 Detail of the MySQL Workbench Panel to connect to local and remote databases.

SQL console was also used, in a less degree in order to troubleshoot database connectivity or
to perform the replication configuration described in the previous section and SQL dumps of the
database contents.

7.3.2.1 Database Scripts

The SQL script Smartlab_Createtables.sql is in charge of generating of all the database
objects. It was initially written and then refined during successive development iterations. This script
can be loaded on MySQL workbench or pasted on a MySQL console in any database server to
automatically create the smartlab database.

Another script was written to automatically load the data on the database,
Smartlab_PopulateTables.sql. This script is intended to be run right after the database creation script,
it loads data from the csv files detailed later contained in the directory paths written in the script.
These lines need to me updated if the csv files are to be loaded from a different location.

A set of SQL queries for testing all types of database operations are provided in Queries for
MainDB.sql, there facilitate the database and SHU testing by simple loading the script on MySQL
Workbench, navigating to the desired SQL query, placing the cursor at the end of the line and clicking
the line execute button shown in the next figure. Upon executing, a panel pops in the MySQL
Workbech window to show the query results, while another panel shows the number of affected rows.

Figure 68 Selecting and executing single queries in MySQL Workbench within the SQL script.
 Another script was written to create the federated tables, Smartlab_SHU_FederateTable.sql,
This script is to be executed once a connection is stablished on the Main database database. It is very
similar to the script for creating the main database but it uses the FederatedX engine. The structure
for the tables are identical to their counterparts on the main database but no data is stored on them,
results are retrieved from the Main database. The script includes the Main database IP Address, user,
password and database name at the creation of each table. This script was written during the first
development iterations when the Federated engine was tested, on later iterations, the creation of the
Federated tables on the SHU local databases was integrated into the SHU Software driver and
therefore the purpose of providing this script is for reference on the structure of the federated database.

A last script, Queries for Federated DB on SHU.sql is provided including test queries against
the Federated tables, to be executed individually.

7.3.2.2 Database Population

Several csv files are provided to populate the database with records using the PopulateTab les
script mentioned above, there are:

List_of_LERs.csv, List_of_LRs.csv, List_of_SHUs.csv, List_of_STUs.csv,

List_of_SAMPLES.csv and List_of_SHRs.csv

These files contain sample data for populating the tables on the Main DB and testing. Data
was written on an excel spreadsheet and exported as csv. The loading of data on
Smartlab_PopulateTables.sql, interprets ; as column separators and \n as end of row.

The data contained in these files emulates a laboratory database scenario with the following
characteristics:

2354 Samples of mixed tube types, unselected and stored in the refrigerated area within
different SHRs

98 SHRs, all cooled.

58 STUs all of them associated to the same SHU, Edison1

30 SHUs, initially all offline. Only one is registered with a real MAC address, and given an
Alias. This is the Edison1 board used during the development of this project.
7.3.2.3 Privileges
For simplicity, on both, the Main and Local databases, all privileges are granted for all
incoming IPs with no password for the user root. The following picture shows the privile ges
window after clicking on the left side panel of MySQL workbench.

Figure 69 Privileges on SHU 'Edison1'

The following image shows the results for a query over the main database showing the
samples in the lab which are flagged as SELECTED and shows some details including device statuses
and network addresses. This query is performed locally on the main server.

7.3.2.4 Federated database operation testing

The Main database structure works as expected for the queries that were tested under the
scenario described in the previous. The federated database on the SHU retrieves satisfactory results
to local queries from the Main database. Query execution times were between 0.015s and 0.811s
depending of the number of records affected.

Figure 70 Query Execution Times against the Local Federated Tables

 Queries against the Federated tables in the Local database are transported and executed in the
Main Database. Therefore, results thrown from both database servers must be identical. The following
two images shown the execution of a compound SQL query joining all the tables in the schema in
order to prove all the Federated tables are correctly connected to their InnoDB counterparts in the
Main database.

Figure 71 Results of query to the main Database by a local connection

The following image shows a similar query performed on the SHUs federated tables.
Figure 72 Results of query to the Main DB using the Federated tables created on the MariaDB mySQL server on
the SHU (Edison1)

As it can be observed, both queries output identical results proving the correct operation of
the Federated tables on the Local database server.

7.4 XBee interface

As described in the Design section, the XBee interface uses AT transparent mode
communication and the network topology is of start type where the XBee module on the SHU is
configured as coordinator.

The XBee modules are driven by the Java UPM libraries provided by Intel, which provide a
basic interface to communicate with XBee modules in AT transparent and command mode.

The XBee on the SHU uses Broadcast transmission while the XBees on the STUs are
firmware-configured to use Unicast addressing. As explained in the XBee protocol design section,
each message contains the STU_id of the destination; therefore, upon receiving broadcasted messages
STUs only process those which contain their STU_id and discard the rest.

7.4.1.1 Addressing

The XBee modules use the MAC addresses for addressing at the Medium Access Control
layer. XBee MAC addresses are 64 bits long. The most significant 32 bits are form the Address High
portion of the MAC while the least significant 16 bits form the Address Low portion of the MAC
address.

XBee may use both portions for addressing or just the Address Low portion. While using the
entire MAC ensures unique identification of a specific XBee module, it also involves some extra
processing overhead on the devices. For medium sized to small XBee networks it is very unlike ly
that two XBee devices may have the same 32 least significant bits and therefore the Address Low is
used.
 Figure 73 Photo of two XBee modules used to test the Communication between the SHU and a STU emulator

Each XBee module contains its MAC address printed on a backside sticker. The figure above
shows the MAC addresses of the XBee module used on the SHU (left) and on the STU (right). The
Address High portion is the same as it identifies the manufacturer and hardware model; therefore, as
long as all XBee modules in the system are the same model. It is only necessary to use the lower
portion of the address.

Table 12 MAC Addresses of the two XBee modules used during the development.

Device name Address High Address Low

Edison1 (SHU) 0013A200 40D5282A
Edison2 (STU Emulator) 0013A200 40D52827

7.4.1.2 Overview of the Firmware Configuration.

As described in the Design section, the serial interface of the XBee modules is left at factory
default settings, which use a baud rate of 9600bps, 8 data bits, 1 stop bit and no parity.

All end devices (STU XBees) operating under the domain of the same Coordinator, need to
be configured with the same PAN ID, Channel and Destination Address. Both device types share the
same configuration settings excluding the once for device type (Coordinator or End Device).

A brief overview of the configuration settings is described below and a table summarizing the
configuration is included later. The configurations for both the SHU and STU XBees are submitted
in the SHU.xml and STU.xml files, which can be loaded by using the XCTU XBee software in order
to program the modules.

The firmware of the XBee module on the SHU is configured to operate as coordinator by
setting CE=1. Both SHU and SHR devices do not operate on battery and have no power saving
limitations, therefore, the Cyclic Sleep Period, is configured to SP=0 which allow the module to
transmit data immediately without retaining data. As a note for further development, power
consumption could be reduced, if needed, by configuring the coordinator to wait until the end devices
to talk first; in this case it would send the message it had queued at that specific time, allowing the
end devices to enter low power consumption mode until they have something to transmit. The
coordinator stores the messages to send until it detects that the end devices are active. If Cyclic Sleep
Period was set to any other value on the SHU, both SP and ST (Time Before Sleep) parameters should
be matched on the XBee modules of the SHR.

End devices on the STUs are configured as such by setting CE=1. Each end device needs its
destination address configuration to math its coordinator low MAC address. XBee modules are
preconfigured with a broadcast destination address as factory default. As mentioned above, SP values
on the coordinator and end devices need to match, therefore SP is set to 0 in the end devices as well.

Table 13SHU Coordinator XBee Firmware Configuration

Parameter Value Description

BD 9600 UART Interface Baud Data Rate
DIO6 1 Enabled HW flow control DO

buffer
DIO7 0
Enabled HW flow control DI buffer
CE 1 Coordinator Enable
A2 Bit 0=0 Reassign PANID flag
Bit 1=0 Reassign Channel flag
Bit 2=1 Allow Association. Coordinator accepts
end association requests from end
devices
Bit 3=0 Reserved
SP 0 Cyclic Sleep Period
ST NP Time Before Sleep
CH C Channel
PANID 3332 PANID

Table 14 STU End Device XBee Firmware Configuration

Parameter Value Description

BD 9600 UART Interface Baud Data Rate
 DIO6 1 Enabled HW flow control DO

buffer
DIO7 1
Enabled HW flow control DI buffer
CE 0 Coordinator Enable
SP 0 Cyclic Sleep Period
A2 Bit 0=0 ReassignPanID
Bit 1=0 ReassignChannel
Bit 2=1 AutoAssociate
Bit 3=0 PollCoordOnPinWake
CH C Channel
PANID 3332 PANID

7.4.1.3 Firmware configuration of the XBee Radio Modules

The XBee modules are configured by using the XCTU Software provided by their
manufacturer, Digi. This section describes the process of configuring the XBee radios.

First, the XBee modules need to be connected to the PC by using a USB FTDI XBee adapter
(Figure 77) and executing the XCTU program. Once the software is running, the software provides
the option to scan the COM ports and automatically discover the connected XBee modules.
Alternatively, the radio modules can be added to the program by manually indicating the COM ports
and the UART settings.
 Figure 74 Manual Additon of the Radio Modules

Once they are found the can be added to the tool, and next it reads their current firmwa re
configuration parameters.

Figure 75 Coordinator Module Discovered by XCTU

The current configuration is shown in a menu where each parameter can be modified as shown
in the picture below. Once the desired configuration is selected, the modules can be programmed by
simply clicking on a write to Module button.
 Figure 76 Configuring the XBee modules on XCTU

7.4.1.4 Testing connectivity in AT transparent mode

In AT transparent mode the communication between two XBee devices behaves as a serial
interface, all data sent to the Tx pin of a XBee device is transmitted wirelessly to the Destinatio n
address. In this test, two XBee modules were used, one configured as End device, configured with
broadcast (0) destination low and high addresses, and another XBee module configured as end device
with the Destination Low and High addresses of the Coordinator device.
 Figure 77 XBee Modules connected to a PC by using the USB adapter.

Once configured and both of them connected to a computer using the XBee USB serial
adapters, basic communication between the devices was tested by opening respective serial termina ls
(Putty) to both of them as seen in Figure 78. The text typed in one of the consoles was directly sent
trough the wireless link and received on the other device.

The end device sends a unicast frames to the coordinator while the latter sends a broadcast
frames to all devices sharing its PAN ID and channel.

Figure 78Coordinator (COM17), End device (COM18)

7.4.1.5 Connectivity Testing using Java

Only two sets of XBee libraries are supported on the Intel Edison, these are the Arduino XBee
libraries and the Intel UPM Xbee libraries, the latter only supports AT mode communication.

A small Java program was written using the Intel UPM XBee Java libraries for listening data
sent from another XBee module connected to the computer by the XBee USB adapter and, by using
the XTCU, several packets of different of sizes were broadcasted.
 public static void ListenToSTU (){
System.out.println("Listening to SHR...");
String response="";
if (sensor.dataAvailable(100)){
System.out.println("Data available");
response=sensor.readDataStr(1024);
System.out.println("Parcial response:"+response);
}
System.out.println("Returned"+response.length()+" bytes.");

Figure 79 Java function to Retrieve XBee data using Intel UPM XBee library.

The XBee driven by the Java library received the data injected from another XBee using the
USB adapter. However the timeout used by datavailable() and the buffer size on readDataStr() had to
be tuned during successive development iterations in order to optimize data reception. This was a
major flaw, on one hand because the UPM libraries are not documented and are not open sourced.
They only include a method descriptor with no hint about their inner operation. On the other hand,
besides having a similar function to the one above written in C++, JS and Python (UPM librar ies
support these four languages) there is no example code available on the internet using this library.

The only source code example provided by Intel about this library uses a 1000ms on this
function. No other source code examples are available on the internet using this library due the short
life of the Intel Edison and it uses AT transparent mode specific for Intel IoT, Galileo and Edison.

The XBee communication was implemented on the SHU software driver by building more
elaborated methods for message processing on top of the basic functions for AT mode communicatio n
provided by the UPM libraries.

7.5 Software Driver

The software driver is the Linux application running on the Intel Edison that controls the
operation of the SHU according to the requirements established by the use cases.

The SHU behaves as a bidirectional relay between the user actions against the main database
server and the physical actions performed on the Storage Tray Units. It notifies each end of the link,
the main database or the STU under its domain, about any changes taking place at the other end.

The software was written in Java and developed using the Intel IoT Eclipse IDE. Classes are
separated in three packages: model, view and controller. The model handles all the data on the system
and database access; the controller responds to user-initiated events on the database or physical events
on the STU end; and the view provides a system console interface for monitoring the SHU operation
and event logging.
 The model package contains four classes: LocalDB, which implements the connection and
operations against the local federated database; the objects from the shr class, contain the informatio n
regarding each SHR involved in a physical event and provides methods for being managed by the
DataHandler class. The DataHandler class implements methods for taking care of constructing and
parsing the messages that are sent and received through the XBee interface and well as keeping track
of the messages that have been sent, acknowledged and received to and from the STUs. Finally, the
MainDB class enables direct access and querying the main database server, bypassing the federated
tables. It is included for debugging or if needed for further development.

Figure 80 Class Diagram of the Model Package

In the Controller package, the InitializeSHU() static method in the Initialization class,
executes de initialization procedure that creates de federated database, performs the STU discovery
and registers the devices on the database. Similarly, the stopSHU class provides the routines to
execute to reboot or shutdown the SHU remotely. The XBeeInterface class, using the Intel UPM
XBee libraries and methods built on top of these, handles the communication with the STUs. Lastly,
the Globals class contains, the configuration variables for the SHU operation. These are retrieved
from the configuration files located at the /smartlab/ directory.
 Figure 81 Class Diagram of the Controller Package

The view package contains the Main class of the program and the methods used to display on
console on real time the information about the operations and errors during SHU operation by using
a colorcode for message severity and a means to set the severity level at which the events are written
to the /smartlab/logfile.

Figure 82 SHU Class contained in the View package

7.6 STU Emulator

A simple program to emulate the behaviour of the Storage Tray Units was implemented in
Java. It operates in a promiscuous fashion, accepting all messages broadcasted by the SHU regardless
of the STU_id to which the messages are addressed to; after processing the messages it individua lly
replies to each message, emulating the network traffic that would be generated by several STUs
connected to the SHU.

It processes each message received from the SHU individually and performs the following
actions depending of the type of message received:

Turnoff Message.

1. Sends back an ACK message

2. Displays the reception of a turnoff Message for 10 seconds

The figure below shows the XBee communication on the left, where the turnoff messages sent
by the SHU are in blue color, and the ACK replies returned by the STU emulator are in red.
On the right side, the STU displaying the received turnoff messages.

Figure 83 STU emulator receiving turnoff messages.

Turnon Message

1. Sends back an ACK message

2. Displays the reception of a turnon message as LED indicator on for 10 seconds

3. Displays Awaiting for SHR retrieval for 10 seconds

4. Sends an UPD message for the SHR_id contained in the original message.

5. Displays SHR Picked Up, UPD sent for 10 seconds.

The following figure shows an XBee packet comprising six turn-on messages for different
SHRs, each one addressed to a different STU. The STU emulator captures all of them and issues and
ACK reply to the SHU, indicating the origin STU_id in the packet (same as the destination on the
initial message).
 Figure 84 STU emulator receiving turnon messages

After the countdown has expired, the STU emulator sends to the SHU update messages for
each STU that was instructed to turn on. In this way, the STU emulator is simulating the physical
SHR retrieval that would be performed by a laboratory user.

Figure 85 STU Emulator sending update messages

Network Discovery

1. Sends back a predefined list of STU_ids

2. Waits for ACK

3. Displays a Network Discovery Received Replying with STU_id message

4. If ACK is not received, resends the STU_ids

 The figure below shows the STU emulator receiving a network discovery packet and replying
with three different STU_ids so that the SHU registers these three devices in the database as
online.

Figure 86 STU Emulator action upon NWD packet reception.

The message format intercepted by XCTU is the following for the SHU(blue) and the STU
emulator (red).

Figure 87 XCTU Captured Packets

8 Verification and Results

Unit testing was continuously performed at each iteration of the system development. At the
end of the last iteration, the system is placed under a simulated user environment and its operation,
performance and reliability were tested. Minor software modifications were performed at this stage
in order to resolve unforeseen problems. This section describes de results obtained during the system
verification carried out after final software modifications were implemented.

. This section describes the operation testing and results of the three use cases established in
the design requirements; as well as testing for robustness from the database side by issuing a massive
sample selection and from the STU side, by issuing a massive SHR storage (update).

Tests were performed by using the dummy collection of data as described in the Database
Implementation section. This data emulates a lab room scenario where there are 2354 test tube
samples which are distributed among 98 SHRs, all of them initially stored in 11 STUs connected to
one SHU.

During the tests, SQL queries were directly executed against the Main Database in the same
manner the User Interface would do. On the STU side, another Intel Edison board was placed running
the STU emulator, which was in charge or acknowledging the received messages (ACKs), and
simulating a SHR user retrieval action by replying with update (UPD) messages after ten seconds of
receiving an SHR-turnon message. The third function of the STU emulator was to reply with
predetermined STU_Ids after receiving a network discovery (NWD) packed during SHU
initialization.

8.1 Use Case 1: Sample Selection and SHR Retrieval from STU
Starting from the database scenario as described above, where all sample-containing SHRs
are stored in their respective STUs and none of them is selected; the following query was executed
on the main database, selecting five hundred samples, contained in 11 SHRs:
update sample set selected=true where Sample_id between 1 and 500;

After sample selection, the SHU retrieved the list of SHRs containing the samples and crafted
the turnon messages to transmit on the XBee interface, addressed to their corresponding STUs, as it
is shown in the lines in blue colour in the figure below.
 Figure 88 SHU Console Verbose: Turnon messages sent to STUs (blue) and STU ACKs (white)

The STU emulator processes all messages broadcasted by the SHU, regardless of their
STU_Id destination. Once the STU emulator received the Turnon messages sent by the SHU, it
acknowledged each message individually by sending an ACK message to the SHU. Next, it initia ted
a countdown for 10 seconds as shown in the next figure.
 Figure 89 STU Console Verbose: SHRs Retrieval countdown after sending Turnon message acknowledgement.

Once the countdown was over, the STU notified the SHU that the selected SHRs have been
retrieved by an user. This was performed by sending Update (UPD) messages back to the SHU for
each SHR. The SHU, acknowledged each UPD message replying with an ACK and subsequently, it
disassociated the SHR from the STU and its SHU (itself) on the federated database and finally,
switched the SHR Status to floating.
 Figure 90 STU Console Verbose: SHR UPDs sent on User retrieval (white) and received ACKs from SHU
(purple)

The communication between the SHU and the STU was monitored by a third XBee module
connected to the PC using the XBee USB adapter and the XCTU software. The following figure
shows the intercepted UPD and ACK messages shown in Figure 90.

Figure 91 XBee communication between SHU and the STU

Finally, the correct operation of the SHRs Turn-on and its consequent SHR retrieval procedure
was checked on the main database by observing the Status of the selected SHRs.
 Figure 92 SHR Disassociation from their SHU/STU and Status change

The figure above shows the status of the SHRs 1 to 11 involved on the selection/retrie va l
process after they have notified by the STU to have been picked-up. The procedure has been
successful, and the SHRs are now floating, they are not located in the cooled storage room and,
consequently they are not associated to any STU or SHU.

8.2 Use Case 2: SHR Storage on STU

Starting from the SHR status depicted in Figure 90, where eleven SHRs are floating; the event
in which these SHRs are placed back on the cooling area was tested. This was performed by sending
custom UPD messages using the USB XBee adapter.

The SHRs do not necessarily need to be placed back on the same STUs or SHUs that they
were associated to before being released, the UPD messages sent to the SHU contain new STU_Ids
to associate these SHRs to, as it is shown in Figure 93.
 Figure 93 Payload of the XBee packed containing the UPD messages sent to the SHU.

The customized packet on the previous image was sent to the SHU. On reception, the SHU,
replies with ACKs for each UPD message and proceeds to associate the SHR to their corresponding
STU as well as updating its status to cooled. These actions are performed by executing the stored
procedure toggleSHRstatus over the federated tables on the SHU local database.

Figure 94 SHU Console Verbose: Processing UPD Messages

The following figure shows the injected UPD packet in blue and the SHU ACK responses in red.
 Figure 95 XCTU Monitored Communicati on on SHR Update events

Finally, the successful operation of this process was checked on the Main database. The figure
below shows that the SHR 1-11 are now back to cooled status and they are associated to STU_1 and
the current SHU performing this process.

Figure 96 Main Database SHR Table showing updated SHRs placed back on cooling area.

8.3 Use Case 3: Remote Reboot and Initialization.

On this section, the Initialization and remote reboot procedure of the SHU were tested. The
SHU can be rebooted at any moment by setting its Action field on the Main database to reboot.

Once the reboot routine is called, the SHU finishes servicing all pending messages and retries
to send all ACK-awaiting messages. Next, it sets all the STUs under its domain to offline status as
well as its own status. Finally, it executes a system, reboot -h command in order to ensure that all
running services are correctly stopped. Figure 97 shows the SHU performing these actions.
 Figure 97 SHU Console Verbose: Reboot Procedure

At this moment, the correct shutdown of the SHU was checked on the Main database, Figure
98 and Figure 99 show the SHU and the STUs under its domain, correctly set as offline during the
reboot procedure.

Figure 98 SHU Status changed to offline during reboot procedure.

Figure 99 Status of the STUs associated to the rebooting SHU changed to offline.

Subsequently, after the reboot -h system command is executed at the end of the reboot
procedure, all processes and services are brought down and the Intel Edison restarts. During power-
up, the start-up script is executed, it retrieves the Wlan0 MAC address and stores it into the
/smartlab/thisSHUid file as well as the IP address into /smartlab/thisSHUip.Next, it starts the SHU
software driver and the Initialization procedure begins.

The following screenshot shows the Actions executed by the SHU on Initialization: Retrieva l
of SHU_id, IP, Database IP and login credentials, Local Database Creation, STU Discovery, and STU
and SHU database registration. The procedure is configured in such a way that all Actions are
registered into the /smartlab/log logfile. If any errors occur, if connection to Main DB is availab le,
these are notified on the SHU.ErrorMsg field.

Figure 100 SHU Console Verbose of a Successful Initialization Routine

The following pictures show the status changes happening during initia lization on the SHU
and the discovered STU devices. The SHU writes on its local federated database, these queries are
reflected on the main database. Consequently, the results of these operations take effect directly on
the main database as shown below.

Figure 101 Contents of SHU Table before SHU Initialization.

As seen from the Main database, SHU was registered as online along with its IP address.

Figure 102 Contents of SHU Table after SHU Initialization.

Figure 103Contents of STU table before SHU Initialization.

This Initialization procedure was executed while the STU emulator was running in another
Intel Edison board. The STU emulator responds with five different STU_Ids to a NWD (STU
discovery) message, therefore, the SHU registered these STU_Ids on the database as it is shown in
the screenshot below.

Figure 104Contents of STU table after SHU Initialization.

The following picture shows the results of the database creation during the Initialization.
 Figure 105 Local Database Objects dynamically created during SHU Initialization

The federated tables, View and stored procedure were successfully created. At this moment
the SHU was fully operative.

8.4 Massive SHR Update

This section shows the communication and SHU operation effectivity for large amounts of
SHRs. SHRs Update events are generated by user manual actions on the cooled storage room either
by retrieving an SHR or by placing it back on a STU. Therefore, it is extremely unlikely that large
amounts of SHRs are placed or retrieved from their respective STUs at exactly the same time instant.
This Test, issued simultaneous update events for the 98 SHRs present in the database and tested
wether the SHU was able to manage all of them with no errors.

The Initial database state for this test consisted of 87 SHR cooled and 11 SHRs floating. By
using the XBee USB adapter and the XCTU packet injector tool, a total of 98 UPD messages were
sent to the SHU for the corresponding SHRs.
 Figure 106 Overview of the mixed statuses of the SHRs on the Initial conditions of the test.

The 87 cooled SHRs receiving the UPD packets were expected to switch to floating.

Figure 107 Query: Select count(*) as Number_of_cooled_S HRs from SHR where status='cooled';

The 11 floating SHRs on the database were expected to switch to cooled.

Figure 108 Query: select count(*) as Number_of_floating_SHRs from SHR where status='floating';

The next figure shows a portion of the packet containing the UPD messages injected from
XCTU (blue) and a porting of the corresponding ACKs sent in response by the SHU.
 Figure 109 SHU ACK responses to UPD packets

It can be observed that the SHU does not start responding until the last UPD message is
received. This is actually due to the fact that the injected packed from XCTU containing the UPD
messages, corresponds to a payload way larger than the actual one for the XBee packets.
Fragmentation and reassembly is taking place at a lower level and it is not shown in the XCTU tool.
This is an extra proof of robustness in terms of testing massive SHR updates for the following reason;
this communication resembles to a unique STU issuing 98 simultaneous SHR updates, however, in a
real scenario there would be several STUs, are under normal operation very few SHRs are expected
to generate an update at the exact same time instant, but if they did, each STU would send independent
packets for the SHRs to update, and therefore the SHU, would be even less likely to catch all incoming
messages without needing to issue message retransmissions.

Figure 110 floating SHRs successfully switched to cooled

Figure 111 cooled SHRs successfully switched to floating

From Figure 110 and Figure 111 it can be seen that the massive UPD packet successfully
processed all SHRs in the database with no SHRs lost. Therefore, it can be ensured, that under normal
conditions of manual SHR retrieval/storage, the SHU will process all events with no bottleneck in the
XBee communication.
8.5 Massive Sample Selection
This section describes the test performed for a complete selection of all samples contained in
the database, which account for a total of 2354 test tubes contained in 98 SHRs. Therefore 98 SHR
turnon messages are crafted and sent to the STU side.

The main difference with the previous section is that regarding the communication, the packet
transmission will be now initiated by the SHU. The SHU, in contrast to the STU, is broadcasting
packets instead of using unicast addressing. This means that all STUs in range see the incoming
packets but only process all of those which are payload-addressed to them; this means that the SHU
needs to fragment the messages at a higher level (not firmware level packet-fragmentation into more
frames at the data link layer, but instead lowering the number of messages sent at a time at the
application layer), this sets a limit on the buffer size required on the STU side to process the data
(using a microcontroller), this limit is a global variable in the SHU software driver design that can be
easily adjusted once the SHU is tested against a real STU instead of the STU emulator.

The starting database state contains all SHRs placed in the cooled storage room.

Figure 112 Overview of the Initial SHR database content.

The process is starting by executing a query to select all samples in the database:
update SAMPLE set Selected=true;
 The SHU starts trasmitint turnon messages to the corresponding STUs crafted is discretized
packets as shown in the next figure.

Figure 113 SHU turnon messages (blue) and STU ACK replies (white)
 The timeout in the XBee Listen() function used in the STU emulator was reduced to 200ms
in order to force it to miss some of the packets, and subsequently forcing the SHU to use the resend
function, which resends unacknowledged messages up to five times before registering an error.
Messages are resent until ACKs are received for every message.

Next figure shows the SHU resending unacknowledged messages until all are confirmed by
the STU (left side). On the right side the STU, sending UPD messages back to the SHU as emulating
the subsequent manual user SHR retrieval.

Figure 114 SHU Resending unacknowledged messages. STU sending UPD messages to SHU
Finally, the result of the sample selection and subsequent SHR retrieval and UPD operations were
tested on the Main database. As shown in the Figures, all SHRs were successfully processed by
disassociating them from their STUs and SHU as well as setting their status to floating.

Figure 115 Massive Sample Selection result: STU and SHU disassociating, floating status

Figure 116 All SHRs in the database were switched to floating status.
9 Conclusions

A distributed database system was designed to support the data operations needed by the
LIMS system. The database system comprised a main database server for data storage and a set of
embedded databases on the Intel Edison Compute-On-Modules running a Federated engine for
connecting to the main database and data transfer.

All communication, including user action notifications from the main database to the Intel
Edison boards, rely on the database interface. A third database server configured as a replicating
slave, was designed to support data redundancy and failover protection to the main database server.
The replication setup was tested using configuration for data transfer over the Wide Area Network
using an embedded MariaDB database as Proof-of-concept. Replication was proven as a feasible
design suggestion for further implementations.

The final database system implementing a federated engine-based database interface, which
was generated dynamically on the Edison boards, between the main and the local databases was fully
tested and its reliability was verified.

An XBee wireless interface for communication between the SHU and the STU was
implemented along with an application layer protocol for communication. The XBee module on the
Intel Edison is driven was the Intel UPM XBee JNI libraries. These libraries were chosen as they
were the only libraries available to run the XBee modules on the Intel Edison board integrated in the
Eclipse IoT IDE; however, they are not open sourced and due to the fact that they are very recent,
there is no example code available online and scarce documentation, making this part of the
development the slowest one as many different approaches were tried. One approach was to drive the
XBee with no libraries by using the on-board MCU, ideally this would enhance the system
performance by dedicating the CPU to data handling and database access while using the availab le
Interproccess communication channels to exchange XBee data with the MCU. Implementation failed
trying to send data through the XBee using the MCU, several different coding attempts using the
MCU SDK in C and XBee firmware configuration were carried out but only garbage was seen and
the other end of the XBee link. Finally, more tests fine tuning the timeouts and buffer lengths used as
parameters on the UPM XBee libraries were tested until the XBee communication reached an
acceptable level of reliability on the tests performed.

The SHU software was entirely developed in Java, as well as a Linux bash script that gets the
system ready before launching the application. The SHU is designed to bring itself up automatica lly
on system power-up. The choice for Java was made as an object-oriented, platform oriented langua ge.
The software was developed following the model-view-controller component separation pattern.
Further development of the software can improve the operation of the XBee interface by
implementing multithreading to run a parallel process to listen on the XBee interface, and also taking
the advantage of extra performance that would provide the Dual Core Atom processor in this sense.

The scarce documentation around the Intel Edison board, especially regarding the XBee
libraries was the most challenging part of this thesis.

As a final conclusion, the Intel Edison Computer-On-Module is a powerful and excellent

platform for developing embedded applications; it is oriented at IoT, and specially, to wearable
applications due to its extremely small form factor (for its features) and low power consumptio n.
However, it needs to be pointed out that its high specifications and miniaturization come at a cost
significantly higher (40-50) than other options such as Single-Board-Computers that offer similar
characteristics and still have small form factors (about 5-6cm x 6-8cm) with about 3W maximum
power consumption. The Intel Edison may not be the ideal choice for a device application that is
intended to be installed permanently in a laboratory room, with no power consumption restrictio ns
neither miniaturization requirements and is intended to remain making exhaustive usage of two
wireless interfaces. In this case, a device such as the Raspberry Pi 3 would meet all requirements at
half the price with the added benefit of providing video support and a graphical interface operating
system to enable adding user interface functionalities directly on the SHU. On the other hand, the
Intel Edison provides and exceptional flexibility to integrate it into custom-made PCBs with other
devices, that not any Single-Board-Computers can offer.
10 References

[1] B. Tagger, An Introduction and Guide to Successfully Implementing a LIMS (Laboratory

Information Management System), 2011.

[2] B. Gode, S. Holzmuller-Laue, K. Rimane, M.-Y. Chow, and N. Stoll, Laboratory Informatio n
Management Systems - An Approach as an Integration Platform within Flexible Laboratory
Automation for Application in Life Sciences, 2007 IEEE Int. Conf. Autom. Sci. Eng., pp. 841
845, 2007.

[3] GAMP Good Practice Guide for Validation of Laboratory Computerized Systems. [Online].
Available: http://www.chromatographyonline.com/gamp- good-practice-guide-validatio n-
laboratory-computerized-systems-part-1?id=&sk=&date=&pageID=2.

[4] C. Voegele, L. Alteyrac, E. Caboux, M. Smans, F. Lesueur, F. Le Calvez-Kelm, and P.

Hainaut, A Sample Storage Management System (SMS) for Biobanks., Bioinformatics, vol.
26, no. 21, pp. 27982800, 2010.

[5] T. Triplet and G. Butler, The EnzymeTracker: an open-source laboratory informa tio n
management system for sample tracking, BMC Bioinformatics, vol. 13, no. 1, pp. 112, 2012.

[6] M. List, S. Schmidt, J. Trojnar, J. Thomas, M. Thomassen, T. A. Kruse, Q. Tan, J. Baumbach,

and J. Mollenhauer, Efficient Sample Tracking With OpenLabFramework, Sci. Rep., vol. 4,
p. 4278, Mar. 2014.

[7] P. R. Martin, R. E. Berdychevski, U. Subramanian, W. F. Blakely, and P. G. S. Prasanna,

Sample tracking in an automated cytogenetic biodosimetry laboratory for radiation mass
casualties, Radiat. Meas., vol. 42, no. 67, pp. 11191124, Jul. 2007.

[8] Bar-Code Technology Is Not Cheaper Than RFID, RFID J.

[9] Measurement of Power Consumption on Intel Edison on Different Operation Modes.

[Online]. Available: https://geektimes.ru/company/intel/blog/262398/.

[10] A. B. Edge, A. Tian, A. Octa, B. Pro, B. Black, B. Green, B. G. Wireless, F. Fireprime, A. Srl,
A. Srl, A. Srl, and N. Thing, Comparison of 81 open-spec, hacker friendly SBCs -- June,
2016, pp. 810, 2016.

[11] I. Giancarlo Fortino, University of Calabria, U. Giuseppe Di Fatta, University of Reading, and
C. Sergio F. Ochoa, University of Chile, Cyber-physical Systems (CPS), Internet of Things
(IoT) and Big Data, Elsevier , Futur. Gener. Comput. Syst.
[12] O. N. Smart and S. Integration, STRATEGIC RESEARCH AGENDA, EPoSS - Eur.
Technol. Platf. SMART Syst. Integr., no. June, 2013.

[13] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci, Wireless sensor networks: a

survey revisited, Comput. networks, vol. 38, no. 4, pp. 393422, 2002.

[14] S. Labs, The Evolution of Wireless Sensor Networks, White Pap., pp. 15, 2013.

[15] 802.15.4-2015 -IEEE Standard for Low-Rate Wireless Personal Area Networks (WPANs),
IEEE Std 802.15.4-2015 (Revision of IEEE Std 802.15.4-2011). pp. 1709, 2016.

[16] S. Hossen, A. F. M. S. Kabir, R. H. Khan, and A. Azfar, Interconnection between 802 . 15 .

4 Devices and IPv6: Implications and Existing Approaches, J. Comput. Sci., vol. 7, no. 1, pp.
1931, 2010.

[17] I. F. Akyildiz and M. C. Vuran, Wireless Sensor Networks, in Wireless Sensor Networks,
Chichester, UK: John Wiley & Sons, Ltd, 2010, pp. 116.

[18] F. Shanin, ZigBee and IEEE 802.15.4 Protocol Layers. Elsevier-Newnes, 2008.

[19] MaxStream, XBee TM / XBee-PRO T M OEM RF Modules, MaxStream, no. 801, pp. 133,
2005.

[20] Robert_Faludi, Building wireless sensor networks. .

[21] C. Intel, Intel Edison Kit for Arduino, no. Febrero, p. 19, 2015.

[22] I. Corporation, Intel Edison Kit for Arduino *, no. September, pp. 119, 2014.

[23] Digi International Inc., XBee Multipoint, pp. 8586, 2015.

[24] D. Products, Modules for Oems.

[25] Intel Corporation, Intel Galileo Board , Intel Galileo Gen 2 Board , and Intel Edison
Board Shield Test Report, vol. 2, no. October, pp. 1309, 2014.

[26] S. Ab and D. Bartholomew, MariaDB vs . MySQL Similarities Between MariaDB and

MySQL, pp. 16, 2012.

[27] L. W. and L. Thompson, PHP and MySQL Web Development. 2003.

[28] MySQL.com, MySQL 5.7 Reference Manual, vol. 2014, 2014.

[29] C. Bell, Mysql Connector , no. July, 2015.

11 Table of Figures

Figure 1Front and back images of the Edison compute module .............................................. 7
Figure 2 Odroid-C2 ................................................................................................................ 10
Figure 3 Raspberry Pi 3 Model B .......................................................................................... 10
Figure 4 Block Diagram example for WSN Smart Sensor .................................................... 12
Figure 5 IEEE 802.15.4 protocol stack .................................................................................. 15
Figure 6 ZigBee Protocol Stack ............................................................................................. 16
Figure 7 Network topologies supported by IEEE 802.15.4 ................................................... 18
Figure 8 Network topologies supported by ZigBee ............................................................... 18
Figure 9 ZigBee packet structure [16] ................................................................................... 19
Figure 10 XBee Pro trough-hole module with RPSMA antenna connector (Left), XBee SMT
module (Right) ................................................................................................................................... 20
Figure 11 : UART data packet as transmitted through the RF module [17]. ......................... 21
Figure 12 XBee Internal data flow diagram [17] ................................................................... 22
Figure 13 Data transfer model End Device-Coordinator in a non-beacon enabled network . 24
Figure 14 Operation modes of a XBee module ..................................................................... 28
Figure 15Intel Edison Breakout Kit for Arduino ................................................................... 29
Figure 16 Arduino pinout [20] ............................................................................................. 30
Figure 17 Front and back side of an 802.15.4 S1 XBee module ........................................... 30
Figure 18 Arduino XBee shield ............................................................................................. 32
Figure 19 XBee shield mounted on the Arduino Breakout board, ........................................ 33
Figure 20 XBee USB adapter................................................................................................. 33
Figure 21 Labroom Top-Level System Architecture ............................................................. 38
Figure 22 Network Topology of the System.......................................................................... 39
Figure 23 Distributed database Architecture ......................................................................... 44
Figure 24 Main Database's EER Diagram ............................................................................. 46
Figure 25 Structure of Sample table ...................................................................................... 47
Figure 26 Structure of SHR table........................................................................................... 47
Figure 27 Structure of STU table ........................................................................................... 47
Figure 28 Structure of SHU table .......................................................................................... 48
Figure 29 Trigger on Sample Selection Stored in the Main Database................................... 49
Figure 30 Cloud-Local Database SHU Operations................................................................ 51
Figure 31 Data flow for the UART- interfaced XBee RF link between the SHU and SHR. . 54
 Figure 32 Three SHUs Operating three overlapping networks configured with different PAN
IDs ...................................................................................................................................................... 55
Figure 33 Start-Up Script ....................................................................................................... 59
Figure 34 State Diagram of the SHU Software Driver .......................................................... 60
Figure 35 Initialization Procedure Flowchart ........................................................................ 62
Figure 36 Reboot Procedure Flowchart ................................................................................. 65
Figure 37 Development Workflow Chart .............................................................................. 67
Figure 38 Using PuTTY to establish console communication. ............................................. 72
Figure 39 First boot of the Edison board on updated Image.................................................. 73
Figure 40 Options for the configure_edison command ......................................................... 74
Figure 41 Available Wi-Fi networks configure_edison wifi................................................ 75
Figure 42 Wi-Fi network configuration ................................................................................. 75
Figure 43 Http connection to Intel Edison over LAN............................................................ 76
Figure 44 Intel Edison automatically connected to network after system boot. .................... 77
Figure 45 Editing usb0.network file for SSH connection to the Edison board ...................... 78
Figure 46 Remote connection to Edison for OTA programming using Eclipse Intel IoT IDE
............................................................................................................................................................ 78
Figure 47 Backing up Edison image ...................................................................................... 79
Figure 48 Loading cloned Edison image ............................................................................... 79
Figure 49 Message of MariaDB is up and running ................................................................ 83
Figure 50Structure of NodeList table in MariaDB database ................................................. 83
Figure 51Structure of NodeList table in the MySQL database on the Main server. ............. 84
Figure 52Contents of NodeList table in MariaDB database. ................................................. 84
Figure 53 Users table of MariaDB database .......................................................................... 85
Figure 54 Configuration of users privileges ......................................................................... 86
Figure 55 Port forwarding configuration on a Technicolor TC7200 router. ......................... 88
Figure 56 Desired bidirectional communication over simulated WAN within the SHU and
remote server, and from the SHU to itself (NAT router needed). ..................................................... 90
Figure 57 Equivalent topology for the implementation of the SQL databases ...................... 91
Figure 58 Simulating SQL queries over the WAN from a client to a remote server within the
same LAN .......................................................................................................................................... 92
Figure 59 Results of a remote SQL SELECT query to NodeList table ................................. 92
Figure 60 Simulating SQL queries over the WAN to the SHU from a remote client within the
same LAN. ......................................................................................................................................... 93
 Figure 61 Replicant user added on master MySQL server, granted access from any host. ... 95
Figure 62 File and position details of the master status ......................................................... 96
Figure 63 simulating a network discovery-triggered insert event into the remote server ..... 97
Figure 64MariaDB database on SHU side successfully mirrored upon insert event on remote
server side. ......................................................................................................................................... 98
Figure 65 Serial monitor output of programmatically querying MySQL Nodelist from the
SHU.................................................................................................................................................... 99
Figure 66Serial monitor output of programmatically querying MariaDB Nodelist from the
SHU.................................................................................................................................................. 100
Figure 67 Detail of the MySQL Workbench Panel to connect to local and remote databases.
.......................................................................................................................................................... 101
Figure 68 Selecting and executing single queries in MySQL Workbench within the SQL
script................................................................................................................................................. 101
Figure 69 Privileges on SHU 'Edison1'................................................................................ 103
Figure 70 Query Execution Times against the Local Federated Tables .............................. 103
Figure 71 Results of query to the main Database by a local connection ............................. 104
Figure 72 Results of query to the Main DB using the Federated tables created on the MariaDB
mySQL server on the SHU (Edison1) ............................................................................................. 105
Figure 73 Photo of two XBee modules used to test the Communication between the SHU and
a STU emulator ................................................................................................................................ 106
Figure 74 Manual Additon of the Radio Modules ............................................................... 109
Figure 75 Coordinator Module Discovered by XCTU ........................................................ 109
Figure 76 Configuring the XBee modules on XCTU .......................................................... 110
Figure 77 XBee Modules connected to a PC by using the USB adapter. ............................ 111
Figure 78Coordinator (COM17), End device (COM18) ..................................................... 111
Figure 79 Java function to Retrieve XBee data using Intel UPM XBee library. ................. 112
Figure 80 Class Diagram of the Model Package ................................................................. 113
Figure 81 Class Diagram of the Controller Package ........................................................... 114
Figure 82 SHU Class contained in the View package ......................................................... 114
Figure 83 STU emulator receiving turnoff messages. ........................................................ 115
Figure 84 STU emulator receiving turnon messages........................................................... 116
Figure 85 STU Emulator sending update messages ............................................................ 116
Figure 86 STU Emulator action upon NWD packet reception. ........................................... 117
Figure 87 XCTU Captured Packets ..................................................................................... 117
 Figure 88 SHU Console Verbose: Turnon messages sent to STUs (blue) and STU ACKs
(white) .............................................................................................................................................. 119
Figure 89 STU Console Verbose: SHRs Retrieval countdown after sending Turnon message
acknowledgement............................................................................................................................. 120
Figure 90 STU Console Verbose: SHR UPDs sent on User retrieval (white) and received
ACKs from SHU (purple) ................................................................................................................ 121
Figure 91 XBee communication between SHU and the STU.............................................. 121
Figure 92 SHR Disassociation from their SHU/STU and Status change ............................ 122
Figure 93 Payload of the XBee packed containing the UPD messages sent to the SHU. ... 123
Figure 94 SHU Console Verbose: Processing UPD Messages............................................ 123
Figure 95 XCTU Monitored Communication on SHR Update events ................................ 124
Figure 96 Main Database SHR Table showing updated SHRs placed back on cooling area.
.......................................................................................................................................................... 124
Figure 97 SHU Console Verbose: Reboot Procedure .......................................................... 125
Figure 98 SHU Status changed to offline during reboot procedure. .................................... 125
Figure 99 Status of the STUs associated to the rebooting SHU changed to offline............. 125
Figure 100 SHU Console Verbose of a Successful Initialization Routine .......................... 126
Figure 101 Contents of SHU Table before SHU Initialization. ........................................... 127
Figure 102 Contents of SHU Table after SHU Initialization. .............................................. 127
Figure 103Contents of STU table before SHU Initialization. .............................................. 127
Figure 104Contents of STU table after SHU Initialization. ................................................ 127
Figure 105 Local Database Objects dynamically created during SHU Initialization .......... 128
Figure 106 Overview of the mixed statuses of the SHRs on the Initial conditions of the test.
.......................................................................................................................................................... 129
Figure 107 Query: Select count(*) as Number_of_cooled_SHRs from SHR where
status='cooled'; ................................................................................................................................. 129
Figure 108 Query: select count(*) as Number_of_floating_SHRs from SHR where
status='floating'; ............................................................................................................................... 129
Figure 109 SHU ACK responses to UPD packets ............................................................... 130
Figure 110 floating SHRs successfully switched to cooled ................................................. 130
Figure 111 cooled SHRs successfully switched to floating ................................................. 130
Figure 112 Overview of the Initial SHR database content. ................................................. 131
Figure 113 SHU turnon messages (blue) and STU ACK replies (white) ............................ 132
 Figure 114 SHU Resending unacknowledged messages. STU sending UPD messages to SHU
.......................................................................................................................................................... 133
Figure 115 Massive Sample Selection result: STU and SHU disassociating, floating status
.......................................................................................................................................................... 134
Figure 116 All SHRs in the database were switched to floating status. .............................. 134
 12 APENDIX I: Table Comparison of "Open-Spec Single-Board-Computers and
Computer-On-Modules by June 2016

The following table includes a list of community-backed Single-Board-Computers and Computer-On-Modules featuring, on the majority
of them, extensive specifications and schematics at least for the shield-stacking part of the hardware, as well as open-source OS such as Linux or
Android. The name of each board is a hyperlink for further details. [10].

Product Price () Vendor Processor Cores 3D GPU MCU RAM S torage LAN Wireless HDMI or US B Expansion OS
DP-out ports
86Duino Zero 34 DMP Vortex86EX 1x x86 @ 300MHz no no 128MB no Fast no no 1 headers Linux

A20-OlinuXino-Lime 33 Olimex Allwinner A20 2x A7 @ 1GHz Mali-400 no 512MB SATA Fast no yes 3 other Linux,
Android

A20-OlinuXino-Lime2- 54 Olimex Allwinner A20 2x A7 @ 1GHz Mali-400 no 512MB 4GB

eMMC
GbE no yes 3 other Linux,
Android
EMMC
A20-OlinuXino-Micro 54 Olimex Allwinner A20 2x A7 @ 1GHz Mali-400 no 1GB opt. 4GB
NAND
Fast no yes 3 other Linux,
Android

Andromeda Box Edge 66 Marvell,

Arrow
Marvell IAP140 4x A53 @ 1.2GHz Vivante no 1GB 8GB
eMMC
no WiFi, BT yes 3 96Boards Brillo

GC7000UL

Arduino Industrial 101 34 Arduino Srl Qualcomm

AR9331
1x MIP S @
400MHz
no ATmega32u4 64MB no Fast WiFi no 1 Arduino OpenWrt

Arduino Yn Mini 53 Arduino Srl Qualcomm

AR9331
1x MIP S @
400MHz
no ATmega32u4 64MB no opt. WiFi no opt. Arduino OpenWrt

Arduino Tian 87 Arduino Srl Qualcomm

AR9432
1x MIP S @
560MHz
no SAMD21G18 64MB no yes WiFi, BT no 1 Arduino OpenWrt

Arndale Octa 175 InSignal,

P yrustek
Samsung Exynos
5420
4x A15 @ 1.8GHz
+ 4x A7 @ 1.3GHz
Mali-T628 no 3GB opt. EMMC Fast opt. yes 2 other Linux,
Android

Banana Pi M2 51 SinoVoip Allwinner A31 4x A7 @ 1GHz P owerVR

SGX544 MP2
no 1GB no GbE WiFi, BT yes 4 P i 40 Linux,
Android

Banana Pi M2+ 33 SinoVoip Allwinner H3 4x A7 @ 1.6GHz Mali-400 MP2 no 1GB 8GB

eMMC
GbE WiFi, BT yes 2 P i 40 Linux,
Android
 Product Price () Vendor Processor Cores 3D GPU MCU RAM S torage LAN Wireless HDMI or US B Expansion OS
DP-out ports
Banana Pi M3 62 SinoVoip Allwinner A83T 8x A7 @ 2GHz P owerVR
SGX544 MP1
no 2GB 8GB eMMC,
SATA
GbE WiFi, BT yes 3 P i 40 Linux,
Android

Banana Pro 42 LeMaker Allwinner A20 2x A7 @ 1GHz Mali-400 MP2 no 1GB SATA GbE WiFi, BT yes 3 P i 40 Linux,
Android

BeagleBone Black 42 BeagleBoard.

org
TI Sitara
AM3358
1x A8 @ 1GHz P owerVR
SGX530
P RU 512MB 4GB
eMMC
Fast no yes 2 Bbone Linux,
Android

BeagleBone Green 34 SeeedStudio TI Sitara

AM3358
1x A8 @ 1GHz P owerVR
SGX530
P RU 512MB 4GB
eMMC
Fast no no 2 Bbone, Grove Linux,
Android

BeagleBone Green 40 SeeedStudio TI Sitara

AM3358
1x A8 @ 1GHz P owerVR
SGX530
P RU 512MB 4GB
eMMC
Fast WiFi, BT no 5 Bbone, Grove Linux,
Android
Wireless
Bubblegum-96 78 uCRobotics Actions S900 4x A53 @ 1.8GHz P owerVR
G6230
no 2GB 8GB
eMMC
no WiFi, BT yes 3 96Boards Linux,
Android

Chip 8 Next Thing Allwinner R8 1x A8 @ 1GHz Mali-400 no 512MB 4GB

eMMC
no WiFi, BT opt. 2 other Linux

MainBit 53 LittleBits Freescale

i.MX233
1x ARM9 @
454MHz
no no 64MB 4GB microSD no WiFi no 0 LittleBits Linux

Creator CI40 137 Imagination

Tech.
Imagination
CXT200
2x MIP S @
550MHz
no no 256MB 512MB
NAND
Fast WiFi, BT no 1 P i 40, Linux,
OpenWrt
,
MikroBus Brillo

Cubieboard3 76 Cubieboard.or
g
Allwinner A20 2x A7 @ 1GHz Mali-400 no 2GB opt. NAND or
TSD, SATA
Fast WiFi, BT yes 3 other Linux,
Android

Cubieboard4 110 Cubieboard.or

g
Allwinner A80 4x A15 @ 2GHz +
4x A7 @ 1.3GHz
P owerVR
G6230
no 2GB 8GB
eMMC
GbE WiFi, BT yes 5 other Linux,
Android

Cubieboard5 87 Cubieboard.or
g
Allwinner H8 8x A7 @ 2GHz P owerVR
SGX544MP1
no 2GB SATA GbE WiFi, BT yes 3 other Linux,
Android

DPT-Board 49 DP Technics Qualcomm

AR9331
1x MIP S @
400MHz
no no 64MB no 2x Fast WiFi no 2 other OpenWrt

DragonBoard 410c 66 Qualcomm,

Arrow
Qualcomm
Snapdragon 410
4x A53 @ 1.2GHz Adreno 306 no 1GB 8GB
eMMC
no WiFi, BT yes 3 96Boards Linux,
Android

Firefly FirePrime 87 Firefly Rockchip

RK3128
4x A7 @ 1.3GHz Mali-400 MP2 no 1GB or
2GB (S+)
8GB NAND
(eMMC on
GbE WiFi, BT yes 5 other Linux,
Android
S+)

Firefly-RK3288 140 Firefly Rockchip

RK3288
4x A17 @ 1.8GHz Mali-T760 no 2GB (4GB
on P lus)
16GB eMMC GbE WiFi, BT yes 3 other Linux,
Android
(32GB on
P lus)

Firefly-RK3288 Reload 166 Firefly Rockchip

RK3288
4x A17 @ 1.8GHz Mali-T760 no 2GB 16GB eMMC,
SATA
GbE WiFi, BT yes 4 other Linux,
Android

Galileo Gen 2 49 Intel Intel Quark

X1000
1x x86 @ 400MHz no no 256MB no Fast no no 2 Arduino, Linux
 Product Price () Vendor Processor Cores 3D GPU MCU RAM S torage LAN Wireless HDMI or US B Expansion OS
DP-out ports
mini-P CIe

Gizmo 2 166 AMD,

GizmoSphere
AMD G-Series
GX210HA
2x x86 @ 1GHz Radeon 800 no 1GB mSATA. 2X
SATA
GbE no yes 6 5x P CIe Linux

HiKey 66 LeMaker,
96Boards.org
HiSilicon Kirin
6220
8x A53 @ 1.2GHz Mali-450 MP4 no 1GB or
2GB
8GB
eMMC
no WiFi, BT no 3 96Boards Linux,
Android

HobbitBoard 61 Wandboard.or
g
NXP I.MX6 UL 1x A7 @ 528MHz no no 256MB 4GB
eMMC
Fast WiFi, BT no 2 MikroBus Brillo

HummingBoard-Base 62 SolidRun NXP i.MX6 1x/2x/4x A9 @ up

to
Vivante
GC355
no 512MB to
2GB
no GbE opt. yes 2 other Linux,
Android

1.2GHz

HummingBoard-Pro 75 SolidRun NXP i.MX6 1x/2x/4x A9 @ up

to
Vivante
GC355
no 512MB to
2GB
mSATA GbE opt. yes 2 Mini-P CIe Linux,
Android

1.2GHz

HummingBoard-Edge 90 SolidRun NXP i.MX6 1x/2x/4x ARM @

up
Vivante
GC355
no 512MB to
4GB
4GB eMMC, GbE opt. yes 4 Mini-P CIe Linux,
Android

to 1.2GHz mSATA, M.2

HummingBoard-Gate 62 SolidRun NXP i.MX6 1x/2x/4x ARM @

up
Vivante
GC355
no 512MB to
4GB
no GbE opt. yes 4 Mini-P CIe,
MikroBus
Linux,
Android

to 1.2GHz

Inforce 6410Plus 126 Inforce Qualcomm

Snapdragon 600
4x A15 @ 1.7GHz Adreno 320 no 2GB 4GB eMMC,
SATA
GbE WiFi, BT yes 3 other Linux,
Android

Intel Edison Kit for 77 Intel Intel "Tangier"

Atom
2x x86 @ 500MHz
+ Quark
no Quark 1GB 4GB eMMC no WiFi, BT no 2 Edison 70- Linux

Arduino

pin, Arduino

LeMaker Guitar 40 LeMaker Actions S500 4x A9 @ 1.6GHz P owerVR

SGX544
no 1GB or
2GB
8GB eMMC Fast WiFi, BT yes 3 P i 40 Linux,
Android

LinkIt Smart 7688 11 SeeedStudio,

MediaTek
MediaTek
MT7688AN
1x MIP S @
580MHz
no opt. 128MB 32MB no WiFi no 2 opt. Arduino OpenWrt

ATmega32U4 and Grove

 Product Price () Vendor Processor Cores 3D GPU MCU RAM S torage LAN Wireless HDMI or US B Expansion OS
DP-out ports
LinkSprite Acadia V3 105 LinkSprite NXP i.MX6
Quad
4x A9 @ 1.2GHz Vivante
GC355
no 1GB SATA GbE no yes 3 Arduino Linux,
Android

LinkSprite Arches 84 LinkSprite Allwinner A80 4x A15 @ 2GHz +

4x A7 @ 1.3GHz
P owerVR
G6230
no 2GB 8GB eMMC GbE WiFi, BT yes 3 Linux,
Android

MarsBoard AM335x 66 HaoYu,

MarsBoard.or
TI AM3358 1x A8 @ 1GHz P owerVR
SGX530
no 512MB 4GB eMMC Fast no yes 2 Bbone Linux,
Android
g

MarsBoard RK3066 51 HaoYu,

MarsBoard.or
Rockchip
RK3066
2x A9 @ 1.6GHz Mali-400 no 1GB 4GB eMMC Fast no yes 5 other Linux,
Android
g

MarsBoard RK3066 Pro 123 HaoYu,

MarsBoard.or
Rockchip
RK3066
2x A9 @ 1.6GHz Mali-400 no 1GB 4GB eMMC Fast no yes 5 Arduino Linux,
Android
g

MinnowBoard Max 123 Intel, ADI, Intel Atom

E3826
2x x86 @ 1.46GHz Intel HD
Graphics
no 2GB SATA GbE no yes 2 other Linux,
Android
Turbot
Minnowboard.
org

NanoPC-T3 53 FriendlyARM Samsung

S5P 6818
8x A53 @ 1.4GHz Mali-400 MP no 1GB or
2GB
8GB eMMC GbE WiFi, BT yes 5 other Linux,
Android

NanoPi M1 10 FriendlyARM Allwinner H3 4x A7 @ 1.2GHz Mali-400 MP2 no 512MB or

1GB
no Fast no yes 3 P i 40 Linux

NanoPi M2 22 FriendlyARM Samsung

S5P 4418
4x A9 @ 1.4GHz 3D GPU no 1GB no GbE no yes 3 P i 40 Linux

NanoPi M3 31 FriendlyARM Samsung

S5P 6818
8x A53 @ 1.4GHz Mali-400 MP no 1GB no GbE WiFi, BT yes 3 P i 40 Linux,
Android

NanoPi2 Fire 20 FriendlyARM Samsung

S5P 4418
4x A9 @ 1.4GHz 3D GPU no 1GB no GbE no yes 2 P i 40 Linux,
Android

Odroid-C0 24 Hardkernel Amlogic S805 4x A5 @ 1.5GHz Mali-450 no 1GB opt. EMMC no no yes 5 P i 40 Linux,
Android

Odroid-C1+ 28 Hardkernel Amlogic S805 4x A5 @ 1.5GHz Mali-450 no 1GB Opt. EMMC GbE no yes 5 P i 40 Linux,
Android

Odroid-C2 35 Hardkernel Amlogic S905 4x A53 @ 2GHz Mali-450 MP2 no 2GB Opt. EMMC GbE no yes 5 P i 40 Linux,
Android

Odroid-XU4 65 Hardkernel Samsung

Exynos5422
4x A15 @ 2GHz +
4x A7 @1.4GHz
Mali-T628
MP 6
no 2GB opt. SATA GbE opt. yes 3 other Linux,
Android

Orange Pi Lite 11 Shenzhen

Xunlong
Allwinner H3 4x A7 @ 1.2GHz Mali-400 MP2 no 512MB no no WiFi yes 3 P i 40 Linux,
Android

Orange Pi One 9 Shenzhen

Xunlong
Allwinner H3 4x A7 @ 1.2GHz Mali-400 MP2 no 512MB no Fast no yes 2 P i 40 Linux,
Android
 Product Price () Vendor Processor Cores 3D GPU MCU RAM S torage LAN Wireless HDMI or US B Expansion OS
DP-out ports
Orange Pi PC / PC Plus 13 Shenzhen
Xunlong
Allwinner H3 4x A7 @ 1.6GHz Mali-400 MP2 no 1GB opt. (8GB Fast no yes 4 P i 40 Linux,
Android

Orange Pi PC / PC Plus Shenzhen

Xunlong
Allwinner H3
Allwinner H3
4x A7 @ 1.6GHz
4x A7 @ 1.6GHz)
Mali-400 MP2
P owerVR
no
no
1GB
2GB
eMMC on
P lus)
Fast
GbE
no
WiFi
yes
yes
4
5
P i 40
P i 40
Linux,
Android
Orange Pi Plus2 / Shenzhen SGX544 MP2 Linux,
Xunlong Android
Pluse2E 43 8GB eMMC,
SATA

Parallella 87 Adapteva Zilinx

Zynq7020/7010
2x A7 @ 667MHz
+ FP GA
no no 1GB no GbE no yes 2 other Linux

pcDuino Lite / Lite 26 LinkSprite Allwinner A10 1x A8 @ 1GHz Mali-400 no 512MB opt. 2GB (Lite
WiFi)
Fast opt. WiFi yes 0 Arduino Linux

WiFi
pcDuino3 Nano / Nano 35 LinkSprite Allwinner A20 2x A7 @ 1GHz Mali-400 no 1GB 4GB flash, GbE no yes 3 Arduino Linux,
Android
Lite
pcDuino3 Nano / Nano LinkSprite
LinkSprite
Allwinner A20
Allwinner H8
2x A7 @ 1GHz
8x A7 @ 2GHz
Mali-400
P owerVR
no
no
1GB
1GB
SATA GbE
GbE
no
no
yes
yes
3
2
Arduino
Arduino
Linux,
Android
Lite SGX544 Linux,
Android
pcDuino8 Uno 43 no

Pine A64 13 P ine64 Allwinner A64 4x A53 @ 1.2GHz Mali-400 MP2 no 512MB to
2GB
no Fast
or
no yes 3 P i 40 Linux,
Android

Pine A64 P ine64

Code
Allwinner A64
NXP i.MX6
4x A53 @ 1.2GHz
4x A9 @ 1GHz
Mali-400 MP2
Vivante
no
no
512MB to
2GB
no
SATA
GbE no
WiFi, BT,
yes
yes
3
3
P i 40
opt. P CIe
Linux,
Android
PixiePro 88 Quad GC355 2GB opt. Linux

PixiePro Code
Radxa
NXP i.MX6
Quad
4x A9 @ 1GHz
4x A9 @ 1.6GHz
Vivante
GC355
no
no
2GB
1GB or
SATA
4GB or 8GB
opt.
Fast
etc. yes
yes
3
3
opt. P CIe
other
Linux
Linux,
Radxa Rock Lite / Rock 52 Rockchip Mali-400 2GB NAND WiFi (BT Android
RK3188
Pro
Radxa Rock Lite / Rock Radxa
Radxa
Rockchip
RK3188
4x A9 @ 1.6GHz
4x A17 @ 1.6GHz
Mali-400
Mali-T764
no
no
1GB or
2GB
4GB or 8GB
NAND
Fast
GbE
on P ro) yes
yes
3
4
other
other
Linux,
Android
Pro Rockchip 2GB or 16GB or Linux,
RK3288 4GB 32GB Android
Radxa Rock 2 Square
114 WiFi, BT

Radxa Rock 2 Square Radxa

Rpi Trading
Rockchip
RK3288
4x A17 @ 1.6GHz
1x A8 @ 1GHz
Mali-T764
VideoCore IV
no
no
2GB or
4GB
eMMC,
SATA
GbE
no
WiFi, BT
no
yes
yes
4
2
other
P i 40
Linux,
Android
Raspberry Pi Zero Broadcom 512MB Linux
BCM2835
Radxa Rock 2 Square 12 Radxa
Rpi Trading
Rockchip
RK3288
4x A17 @ 1.6GHz
1x A8 @ 1GHz
Mali-T764
VideoCore IV
no
no
2GB or
4GB
no GbE
no
WiFi, BT
no
yes
yes
4
2
other
P i 40
Linux,
Android
Raspberry Pi Zero Rpi Trading Broadcom 4x A7 @ 900MHz VideoCore IV no 512MB Fast no yes 5 P i 40 Linux
BCM2835 1GB Linux
Raspberry Pi 2 Model B 31
Broadcom
no
BCM2836
 Product Price () Vendor Processor Cores 3D GPU MCU RAM S torage LAN Wireless HDMI or US B Expansion OS
DP-out ports
Raspberry Pi 3 Model B 31 Rpi Trading Broadcom
BCM43437
4x A53 @ 1.2GHz VideoCore IV no 1GB no Fast WiFi, BT yes 5 P i 40 Linux

Rico Board 87 MYIR TI AM437x 1x A9 @ 1GHz P owerVR

SGX530
no 512MB (or 4GB eMMC GbE no yes 2 other Linux

Rico Board MYIR

Newark,
TI AM437x
NXP i.MX6 Solo
1x A9 @ 1GHz
1x A9 @ 1GHz
P owerVR
SGX530
no
Kinetis K20
256MB or 4GB
eMMC
GbE
GbE
no
no
yes
yes
2
5
other
other
Linux
Linux,
RioTboard RioTboard.org Vivante 4GB eMMC Android
GC355
Rico Board MYIR
Newark,
TI AM437x
NXP i.MX6 Solo
1x A9 @ 1GHz
1x A9 @ 1GHz
P owerVR
SGX530
no
Kinetis K20
1GB) 4GB
eMMC
GbE
GbE
no
no
yes
yes
2
5
other
other
Linux
Linux,
RioTboard 70 RioTboard.org Actions S500 4x A9 @ 1.6GHz Vivante no 1GB 4GB Fast no yes 4 P i 40 Android
Roseapplepi.o GC355 eMMC Linux,
Roseapple Pi 44 rg P owerVR 256MB 4GB Android
SGX544 eMMC

SAMA5D4 Xplained 83 Newark,

Atmel
Atmel
SAMA5D4
1x A5 @ 528MHz no no 512MB 512MB
NAND
Fast no yes 3 Arduino Linux

Seeeduino Main 62 SeeedStudio Qualcomm

AR9331
1x MIP S @
400MHz
no ATmega32u4 64MB 64MB
NAND
Fast WiFi no 2 Arduino, Grove Linux

Snickerdoodle 55 Krtkl Xilinx

Zynq7010/7020
2x A9 @ 667MHz
+ FP GA
no STM32 512MB or
1GB
no opt. WiFi, BT opt. 1 opt. Arduino Linux

Udoo Neo 44 Udoo (Seco) NXP i.MX6

SoloX
1x A9 @ 1GHz) Vivante
GC355
Cortex-M4 512MB or
1GB
no Fast opt. yes 2 Arduino Linux,
Android

Udoo Quad/Dual/Dual 87 Udoo (Seco) NXP i.MX6

Dual/Quad
2x/4x A9 @ 1GHz Vivante
GC355
SAM3X8E
(M3)
1GB opt. SATA
(Quad)
opt. opt. yes 4 Arduino Linux,
Android
Basic
USB Armory 114 Inverse P ath NXP i.MX53 1x A8 @ 800MHz no no 512MB no no no no 1 headers Linux

Wandboard 70 Wandboard.or
g
NXP i.MX6 1x, 2x, or 4x A9 Vivante
GC355
no 512MB to
2GB
opt. SATA
(Quad)
GbE opt. yes 2 other Linux,
Android

Wandboard Wandboard.or
g
NXP i.MX6
Xilinx
@1GHz Vivante
GC355
no
no
512MB to
2GB
opt. SATA
(Quad)
GbE
GbE
opt.
no
yes
yes
2
2
other
other
Linux,
Android
Z-turn Board MYIR Zynq7010/7020 no 1GB no Linux

Wandboard 87 Wandboard.or
g
NXP i.MX6
Xilinx
2x ARM @
667MHz + FPGA
Vivante
GC355
no
no
512MB to
2GB
opt. SATA
(Quad)
GbE
GbE
opt.
no
yes
yes
2
2
other
other
Linux,
Android
Z-turn Board MYIR Zynq7010/7020 no 1GB no Linux