2017 IEEE 23rdInternational Symposium for Design and Technology in Electronic Packaging (SIITME)

Tele-measurement with Virtual Instrumentation

using Web-Services
Dan Nicolae ROBU, Vlad Paul FERNOAGA, George-Alex STELEA, Florin SANDU
Department of Electronics and Computers, ”Transilvania” University
Brasov, Romania
robu.dan@unitbv.ro , vlad.fernoaga@unitbv.ro , george.stelea@unitbv.ro , sandu@unitbv.ro

Abstract—The web-services for tele-measurement are
approached by REST (Representational State Transfer) as the
unified representation of states-transition-events that enables a
true integration of resource management in a distributed
environment by simplifying the algorithmic state machines
associated with both services and behavioral patterns of
instruments. Each of the sensors we used got an own ESP8266-
based Wi-Fi micro-system to publish its specific values in the
Cloud. Forwarding from the public address of the router to the
Intranet address is monitored by a National Instruments Web-
Shared Variables server. Data produced by the sensors,
accompanied by their presentation methods are taken-over by a
web-based "thin client", a dynamic and adaptive content-to-
terminal "Control Board" developed to manage and connect the
tele-measurement services, using a graphical user interface, with
simple browser access and without the need to install additional
third party modules and plugins.
Keywords— REST, ESP8266 Wi-Fi tag, direct hotspot
publishing, web-shared variables, virtual instru-mentation, content-
to-terminal adaption
I. INTRODUCTION
In instrumental IT (represented in this paper by
implementations including virtual tools) it has begun a
thoroughly transposition of all connections (not only in the
Internet but also locally within the virtual instruments) and all
exchanges of data and commands as simple HTTP messages.
Thus, one and the same transaction structure and the same
service logic can be deployed (including the automation of
Cloud integration) independent of distance and / or position.
The "instantiation" decision to allocate resources,
including resource management as a service, can be
"stateless", "connectionless", "serverless", with new
optimization criteria, such as the efficiency of costs and,
nevertheless, security.
In REST [1], simplified demand-response mechanisms are
built to create-read-update-delete (”CRUD”) appropriate
resources on the Internet (fig.1).
These actions represented in HTTP also envisage another
simplification (of securing measures - such as the restriction
on the number of ports that must be opened at instruments in-
and-out).
II. TRANSMISSION OF DATA FROM INTELLIGENT SENSORS
For the transmission of tele-measurements to the Cloud we
have chosen ESP8266, produced by Espressif Systems, a cost-
effective and very popular Wi-Fi chip with a full TCP/IP stack
integrated, governed by an embedded 32-bit RISC micro-
controller -Tensilica Xtensa L106 operating at 80 MHz, based
on instructions stored in 64 KiB of RAM. Programs can be
retrieved from an external flash memory of up to 16 MiB via
QSPI.
The radio part has an IEEE 802.11b Wi-Fi b/g/n interface,
with a T/R switch and an integrated "balun" antenna, LNA for
receiving, respectively a power amplifier and impedance
adapter for transmitting.
What was decisive in our choice of ESP8266 is an
integrated 10-bit ADC where any sensor can be connected.
For our demonstrator we have used a temperature sensor
LM35 (Texas Instruments).
In order to keep the advantage of miniaturization, restricted
sets of configurations and connections recommended by the
producer of ESP8266 are grouped into a series of modules –
we have chosen module 12 that has a direct access to the
analog-to-digital converter able to acquire data from a wide
range of sensors (fig. 2).

Fig. 2: ESP module12 by AI THINKER

The module is mounted on a mini development board Wemos

D1 (fig. 3) with firmware written in Lua, and resources
available in the open-source IoT platform NodeMCU,
Fig. 1: Example of National Instruments LabVIEW support for RESTful
programmable in the Arduino environment.
Web Services – ”Temperature” can be noticed as Web Shared Variable

978-1-5386-1626-0/17/$31.00 ©2017 IEEE  26-29 Oct 2017, Constanța, Romania

 2017 IEEE 23rdInternational Symposium for Design and Technology in Electronic Packaging (SIITME)
B.The TCP-based tele-measurement

Data collection from the remote sensors, implemented on

the above-mentioned LabVIEW virtual machine, was
accomplished via the VI (Virtual Instrument [3],[4]) presented
in Fig.5.

Fig. 3: Connecting the LM35 temperature sensor (Texas Instruments) – from

upper left, opposite clock-wise: ADC in / power supply / GND.

In fig.4 there is a code extract from the web-publishing HTTP

GET based method. The advantage of this solution is the
direct use of any domotic or industrial simple Wi-Fi router.
One of the main classes we used from the Arduino IDE
(Integrated Development Environment) is the Wi-Fi Client
class that creates the TCP connection using
client.connect(host, httpPort)
#include <ESP8266WiFi.h>
const char* ssid = "<WiFi hotspot >";
const char* password = "<passwd>";
const char* host = "< public IP address >"; Fig. 5.a: The panel of the TCP retrieval VI
[...]
WiFiClient client; We have implemented a HTTP message monitor and a sub-
constinthttpPort = < in-coming port >;
[...] string “filtering” of the intrinsic sensor data. As seen in the
// read the from the analog input: diagram of Fig.5.b, a TCP connection is opened, listening to
float voltage = sensorValue; the forwarded <local IP address >:< in-coming port >. The
// creating the urlfor the http get web request read TCP data (displayed in the panel for monitoring purpose)
String url = "/testwifi/index.html&temp=" + String(voltage); is parsed (with substring extraction of the intrinsic sensor data,
// send the http request to server
client.print(String("GET ") + url + " HTTP/1.1\r\n" + after and before appropriate tags, HTTP/1.1 and = ,
"Host: " + host + "\r\n" + respectively). The TCP connection is closed by writing the
"Connection: close\r\n\r\n"); HTTP/1.1 200 OK post-amble to the remote peer. In our
Fig. 4: Code snippet from the web-publishing HTTP GET based method [2]
example, the tele-measured temperature is written in the
homonym web-shared variable (discussed in detail in the
following paragraphs). “Time-stamping” of this tele-
III. DATA COLLECTION IN THE CLOUD measurement is also provided in our VI (a string web-shared
variable, Device Time, is con-catenated out of date and time
local information).
A. The Cloud server

The Cloud computing infrastructure is based on the Citrix IV. ARCHITECTURE OF THE PROPOSED WEB-SERVICES SYSTEM
XenServer hypervisor running on a consolidated server farm
After the Cloud collection of tele-measured data, we have to
of 6 Dell Power Edge 1950 blades. Remote access is based on
discuss the main aspects of our web-services solution.
the SoftEther VPN solution and the Intranet is based on Cisco
Gigabit router. The National Instruments (NI) software bundle
(centered on LabVIEW) is running on a virtual host on the A.Benefits of presenting the data via RESTful services
XenServer. To enable public access to the server, the
necessary ports (“in-coming” and “out-going”) are forwarded RESTful presentation of data opens new opportunities for
from the public host to the LabVIEW Windows virtual the easy management and maintenance of the sensors
machine. resources [5].

978-1-5386-1626-0/17/$31.00 ©2017 IEEE  26-29 Oct 2017, Constanța, Romania

 2017 IEEE 23rdInternational Symposium for Design and Technology in Electronic Packaging (SIITME)
Fig. 5.a: The diagram of the TCP retrieval VI
In accordance with the REST concept, data produced by the
sensors is organized in resources that can be uniquely
identified via URI (Uniform Resource Identifiers). Thus, in
order to retrieve a value - measurement (+ time stamp) or
status (often needed to validate the sensor data) that is created
by a sensor installed anywhere in the world - it is enough to
know its URI. Having the address of a sensor, it is only needed
a simple Web Browser in order to retrieve its data via a GET:
<the URI> request.
Another benefit of managing the resources in a RESTful
manner is that such requests are stateless: when asking for
data, no state is created on either server or client side – this
natural way of accessing resources is also crucial for the
maintenance.
B.Layered structure of our solution
Data accessibility via a REST API gives another
opportunity: now it is easy to add a data management layer in
the system – the architecture of our proposed solution is given
in Fig.6.
This is a loosely coupled component that is fully using the
resources provided by the published web services. The scope
of this data management layer is to take the stateless data and
to add user-relevant context. Let’s take the following
example: 10 sensors are installed in a room, each of them in
critical points, under the window, on the floor, at the entrance,
on the ceiling, near the heater etc. With the actual web
services we can easily read the real-time temperature for each
978-1-5386-1626-0/17/$31.00 ©2017 IEEE
sensor. The next step is to transform these temperatures in
user-relevant information.
Here the data management layer comes into play.
This independent layer reads the temperatures (usually
“polling them with a constant sampling frequency), stores
them and thereafter, creates relevant reports: which part of the
room is cooler, where it happens a heat leakage etc.
It also can send alarms to the user: e.g., if the temperature of
the window sensor decreases, it would send a message
“Window forgot open” (important, for instance, if the outside
is frozen, in winter-time).
The multi-layer abstraction [6] was one of the guidelines of
our research: we aimed to create an integrated system where
each layer is independent – providing only REST APIs for its
”north-bound” partner layer that returns only values
(measurement or status).
These layers can easily be changed in future
implementations with a real potential for virtualization.
The NI web service infrastructure was a great choice for our
approach as it provides a robust framework for working with
raw data from all sorts of sensors and publishing it in an up-to-
date manner on the Web.
Data are published in the Cloud only after the interpretation
of the raw real-world signals that are transformed as
independent and ready to use resources.
The software based applications that are running in the
Cloud would take over these resources - without any care on
how they arrived there - and will start manipulating them in
order to add more and more value to the end user.
 26-29 Oct 2017, Constanța, Romania
 2017 IEEE 23rdInternational Symposium for Design and Technology in Electronic Packaging (SIITME)
The web services we implemented have an important
advantage: they provide relevant real-time data, without
forwarding to the next layer overhead information - about data
acquisition processes etc.
Fig.6: The architecture of our tele-measurement web-services solution
C. Key features of our solution in the context of Big Data
It is a fact that we are living in a digital world where each
minute produces more and more data [7]. A lot of this data
comes from different sensors (IoT devices) and most of the
problems are related to the connectivity of our sensors to
upper hierarchy systems in order to be manageable, scalable
and secured.
978-1-5386-1626-0/17/$31.00 ©2017 IEEE
Our solution integrates the HTTP protocol and the REST
methods, having the endpoints isolated via secured
authentication; the second aspect of security is the data storage
on our university proprietary systems (without any
dependence on third-party services to manipulate our data).
Adding the above-mentioned management layer as an
extension, we increase the value of our tool-chain by adding
the key of Big Data: tracking and analytics [8]. All of these
features put together bring the IoT closer to the user needs,
granting him/her full control on the data flow and
accessibility.
Our system architecture has then the advantage of three
completely independent layers: presentation layer, data
management layer, NI web-services. Each layer is consuming
one API and producing another API. It is designed so that
each layer consumes the established API of the “south”
component. But this doesn’t mean the component is depending
on some specific implementation, because each component
will work against a specification.
The presentation layer is designed to interact with the API
of the data management layer with the purpose to create a
user-friendly GUI that can present relevant data that were
already processed by the layer below. At this point we expose
the added value of the User orientation component. Because
by using the API we are able to create user identities in our
system and after this the users can register to the system and
configure their environment, define alerts or reports that are
interesting for them. All these features of user orientation are
becoming useful only when we have a presentation layer that
can make use of them and make them accessible to the world.
Actually this layer is one of the key components because
without this layer we cannot show the information that we
acquired and post processed to the customer.
The data management layer is the middle component of the
system architecture, that has no direct contact with the end
user. The purpose of it is to add context to the data we get
through REST API of the NI web-services. In this part of the
system all the business logic of the data handling happens.
Here we transform the primitive values got form the sensors in
objects full of context (user, place, time information). Also,
this part of the system is responsible of aggregating that data
and creating histories. In this component also data tracking
algorithms can be implemented – this could help the system in
creating predictions and sending statistics for the future to the
users.
The NI web-services layer is the critical part of the system
because form here we get the data to feed the system. This
component is responsible for connecting with the sensors and
publishing the data to this consumers through REST
endpoints. This is the component that has the ability to handle
measurements form the real world.
V. THE WEB-PUBLISHED CONTROL-BOARD
One of the main advantages of our solution is described in
the following: a dynamic, content-to-terminal adaptive
 26-29 Oct 2017, Constanța, Romania
 2017 IEEE 23rdInternational Symposium for Design and Technology in Electronic Packaging (SIITME)
presentation “Control Board” built not as installed apps but as They and are queried with the following HTTP request:
a web-based "thin client" available via general purpose, GET /LVWSSysAdmin/GetAllUserServices HTTP/1.1
popular web browsers. The “Control Board” we developed in - from a common web-browser, the corresponding URL is:
order to connect and manage centrally the tele-measurement http:// < public IP address > :< out-going port >
services is consisting of a graphical user interface (GUI) that /lvwssysadmin/getalluserservices
can be engaged by accessing a web URL without the need to
install additional modules and third party plugins [9] – these
can generate security breaches, can create un-necessary
resources consumption and can make the user experience
troublesome and complicated due to additional dependencies.

A. The web technologies involved

The technologies (HTML5, CSS3, JavaScript/jQuery) we

have used to develop and execute the Control Board are
standardized and the open-source libraries needed are natively
integrated in every modern web browser or “WebView”
system component that allows mobile apps to process and
display RIA (Rich Internet Application) content directly inside
an application.
As nowadays an application can be accessed from a variety
of terminals with a wide diversity of resolutions, we
developed the Control Board using the Bootstrap Framework,
that acts as a web engine, in order to maintain the concept of
responsive design [10], to support the wide range of terminals
for a single application and to ensure the usability and the Fig.7: The connection screen of the Control Board
expected QoE (quality of experience).
The thin client web interface we developed aims to adapt to
multiple resolutions using media queries; thus, it is possible to
view and operate it on both desktop, notebook or mobile
terminals (tablets or smartphones), across the entire screen, in
response to the resolution with which it is defined.
Due to security restrictions and to minimize the
communication tasks, server load and response time, the
balancing of execution concept – between client-side scripting
(JavaScript) and server-side scripting (PHP) – was used to
perform the control functions and web service parsing object-
oriented web interfaces inside the application.
To perform the “device” (generic name for remote sensors)
Call and Poll actions, the AJAX (Asynchronous JavaScript
and XML) .load() [11] method was used to load server data to
the HTML5 application's interfaces, without having to refresh
the web browser in order to set the content of the specified
items with the returned data.

B. Implementation of the presentation web-services

Fig.8: Displaying the published tele-measurement web-services
The first Control Board screen (Fig.7) is designed to
connect to the Cloud server. Here it is an example of the HTTP response:
After the connection is established, the Control Board was HTTP/1.1 200 OK
programmed to offer a list of the published web-services on <UserServices>
the Cloud server (Fig.8). <WSName>VlabWS1</WSName>
The NI Services invoked by the remote Control Board <WSName>VlabWS2</WSName>
belong to the LabVIEW System Administration set <WSName>VlabWS3</WSName>
(“LVWSSysAdmin”). </UserServices>
A service “Info” button can display a short description (fig.9).

978-1-5386-1626-0/17/$31.00 ©2017 IEEE  26-29 Oct 2017, Constanța, Romania

 2017 IEEE 23rdInternational Symposium for Design and Technology in Electronic Packaging (SIITME)
Once the web-based Control Board retrieved this data,
accompanied by the corresponding presentation method, the
“tele-measurement customer” (not a developer or a solution
architect but a person oriented on the industrial relevance of
the collected data) can get the values of the variables and
interpret them.
This customer can choose “a theme” (“a skin”) of the
presentation and “an action” – e.g. a simple call (or, as an
alternative action, a repetitive polling) like in Fig.10.

Fig.9: Displaying a short description for a published web-services

After the available web-service (e.g. “Virtual Laboratory

Web Service number 3”, VlabWS3) is chosen, a powerful NI
Service can be invoked from the Cloud server, to retrieve a
RESTful description (“lvwsdsc” – LabVIEW Web Service
Description) of the variables (name and type) and their
associated methods and keys.
This is implemented via the following HTTP request:
GET /VlabWS3/WebService.lvwsdsc HTTP/1.1
- from a common web-browser, the corresponding URL is:
http:// < public IP address > :< out-going port >
/vlabws3/webservice.lvwsdsc
The response is in XML format describing the service – for
our example the preamble (pointing to the .xsd i.e. XML
Fig.10: Presentation choice – an example of actions, units etc
schema definition – of the interrelationship between
the elements) is:
HTTP/1.1 200 OK
<?xml version="1.0" encoding="utf-8"?> VI. DISCUSSION ON THE IMPLEMENTATION ALTERNATIVES
<WebService Name="VlabWS3" Version="1.1"
xmlns="http://www.ni.com/LVWebServiceDescription.xsd">
The NI Shared Variables were based, for many years, on the
In a browser, the corresponding output is:
very robust PSP (Publish and Subscribe Protocol) that was
used intensively in the Intranet of many industries.
For the modern “web-plants”, the network administrators
can “extend” this Intranet by opening the dedicated ports (for
PSP or DSTP - Data Socket Transfer Protocol etc) in all the
interconnected remote sites.
The alternative to a real Internet publishing of the Shared
Variables is the common Port 80 (for HTTP).
We have used the Web-Shared Variables in our proof-of-
concept implementation structured like in Fig.11.
Web-publishing of the Shared Variables is simply granted
by the deployment of a VlabWS3 RESTful Web Service after
it is built on a simple VlabWS3 web service.vi that is dealing
with the data of a given “device” (remote sensor) – e.g.
“subscribed” with the number 163, like in Fig.12.

978-1-5386-1626-0/17/$31.00 ©2017 IEEE  26-29 Oct 2017, Constanța, Romania

 2017 IEEE 23rdInternational Symposium for Design and Technology in Electronic Packaging (SIITME)

Fig.13: Continuous web-publishing of tele-measured data

Fig.11: The project structure with the VlabWS3 data.lvlib (LabVIEW library)

VII.CONCLUSIONS AND FURTER DEVELOPMENT

Our research was focused on the web-services for tele-

measurement and enhanced presentation of Cloud collected
data.
Based on our particular LabVIEW web-services solution,
data acquisition can trigger the delivery of both static HTML
content and JS (java script) methods [12]. This way, data
transmission can include information on their further possible
processing.
This important feature has the advantage to enable the
authoring of HTML5 pages that present the tele-measurement
sensors data in a user-friendly way.
The dynamic GUI (Graphical User Interface) of our “thin
client” Control Board can be further developed to accept not
only the main commands (”Call”, ”Poll” etc) in order to get
updated values (measurement or status) but also some
commands that can change (via Java “PrimeFaces” etc) the
appearance and arrangement of ”panel instrument displays”
indicators/controls (the ”skin”) and/or the units (e.g.
Fahrenheit instead of Celsius) etc.
In our perspective, “raw” tele-measured data can be
retrieved together with accompanying own processing
methods. They can also be completed with “meta-data” on
significance or representation. Such meta-data can be
modified in a single place (e.g. on the server, being
automatically updated on all the clients.
In order to avoid methods to become an overhead for the
intrinsic tele-measured values, „caching” could be ensured
including in the header of the GET request a kind of time-
stamping „not modified since”.
Fig.12: A simple VI “consuming” the web-published
variables shared by device (sensor) 163

As long as this VI is deployed into the files of a web- Acknowledgment

service, the latter becomes “stand-alone” and publishes
continuously the tele-measured data from the remote sensor The research presented in this paper was funded in the EU
(device 163), as it can be seen in Fig,13. AAL project "NOAH - NOt Alone at Home", registration
number AAL-2015-2-115 / contract number 71-2016.

978-1-5386-1626-0/17/$31.00 ©2017 IEEE  26-29 Oct 2017, Constanța, Romania

 2017 IEEE 23rdInternational Symposium for Design and Technology in Electronic Packaging (SIITME)
References
[1] R. Fielding - REST: Architectural Styles and the Design of Network-
based Software Architectures - University of California, Irvine,
Doctoral dissertation, 2000
[2] www.arduino.cc/en/Reference - The Arduino IDE (Integrated
Develop-ment Environment)
[3] P. Cotfas; D. Cotfas; C. Gerigan - Simulated, hands-on & remote
laboratories for studying the solar cells - Intl Conf on Optimization of
Electrical & Electronic Equipment (OPTIM 2015), Brasov, Romania
[4] I.Iliescu, T.Balan, O.Garoiu, S.Zamfir - Thin Client for Real -Time
Monitoring of Communication Infrastructure – Intl Conf on
Scientific Research and Education in the Air Force-AFASES 2016,
Brasov, Romania
[5] D. Guinard, I. Ion, and S. Mayer “In Search of an Internet of Things
Service Architecture: REST or WS-*? A Developers’ Perspective” -
https://www.vs.inf.ethz.ch/publ/papers/dguinard-rest-vs-ws.pdf
[6] J. Y. Zhu, J. Xu and V. O. K. Li, "A Four-Layer Architecture for
Online and Historical Big Data Analytics," 2016 IEEE 14th Intl Conf
on Dependable, Autonomic and Secure Computing, 14th Intl Conf on
Pervasive Intelligence and Computing, 2nd Intl Conf on Big Data
978-1-5386-1626-0/17/$31.00 ©2017 IEEE
Intelligence and Computing and Cyber Science and Technology
Congress(DASC/PiCom/DataCom/CyberSciTech), Auckland, 2016,
pp. 634-639.
[7] J. Gantz D. Reinsel "The digital universe in 2020: Big data bigger
digital shadows and biggest growth in the far east" IDC iView: IDC
Analyze the Future 2012.
[8] L. Xiao-Hong, "Research and Development of Web of Things
System Based on Rest Architecture," 2014 Fifth International
Conference on Intelligent Systems Design and Engineering
Applications, Hunan, 2014, pp. 744-747.
[9] C. Myers, Responsive Web Design Patterns, Packt Publishing,
2015, ISBN-13: 978-1785889981
[10] J. Pamental, Responsive Typography: Using Type Well on the Web,
O'Reilly Media, 2014, ISBN-13: 978-1491907092
[11] A. Mesbah, A. van Deursen, S. Lenselink, Crawling Ajax-Based Web
Applications through Dynamic Analysis of User Interface State
Changes, ACM Transactions on the Web (TWEB) - Volume 6 Issue
1, March 2012 Article No. 3, ACM New York, NY, USA.
[12] https://forums.ni.com/t5/LabVIEW-Web-Development/Getting-
Started-Series-Simple-JavaScript-and-HTML-with-LabVIEW/ta-
p/3503111
 26-29 Oct 2017, Constanța, Romania