DELIVERABLE 2.3.
Wearable Platform
-
Requirements Analysis
LIFEWEAR, MOBILIZED LIFESTYLE WITH WEARABLES
COUNTRY
PARTICIPANT
VERSION
DATE
Spain
Tecnalia
0.1
21/06/2012
Spain
Tecnalia, Treelogic,
Deusto
0.2
25/06/2012
Spain
Tecnalia
0.3
27/06/2012
Spain
Tecnalia, UPM, TID
0.4
27/12/2012
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
2
/
39
CONTENTS
1
INTRODUCTION AND OBJ
ECTIVES
................................
................................
................................
.
3
1.1
E
XECUTIVE SUMM
ARY
................................
................................
................................
..........................
3
1.2
O
BJECTIVES
................................
................................
................................
................................
........
3
1.3
O
VERVIEW OF SECTIONS
................................
................................
................................
.......................
3
2
WEARABLE PLA
TFORM ESB
................................
................................
................................
...........
5
2.1
FIRST
STEPS
................................
................................
................................
................................
....
5
2.1.1
Prerequisites
________________________________
_____________________________
5
2.1.2
Instal
lation
________________________________
_______________________________
5
2.1.3
Launching
________________________________
________________________________
6
2.2
I
NSTALLATION OF
L
IFE
W
EAR BUNDLES
/
LIBRARIES
................................
................................
......................
6
2.2.1
WP5 Ontology
________________________________
____________________________
6
3
USAGE OF THE LIFEWEA
R ONTOLOGY API
................................
................................
....................
8
4
USAGE OF THE LIFEWEA
R WEARABLE PLATFORM
................................
................................
.......
12
4.1
D
EPLOYMENT OF PRODUCE
R BUNDLES
................................
................................
................................
...
12
4.1.1
Sarein
–
Tecnalia
________________________________
_________________________
13
4.1.2
UPM
________________________________
________________________________
___
18
4.1.3
Deusto
-
Treelogic
________________________________
________________________
25
4.1.4
Telefonica I+D
________________________________
___________________________
31
4.2
R
EST
SERVICES CONSUMPTION
GUIDE
................................
................................
................................
....
32
5
WEARABLE PLATFORM IN
THE LIFEWEAR REPOSIT
ORY
................................
..............................
36
6
CONCLUSIONS AND FURT
HER STEPS
................................
................................
...........................
38
7
REFERENCES
................................
................................
................................
................................
39
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
3
/
39
1
INTRODUCTION AND OBJ
ECTIVES
1.1
Executive summary
The current document is delivered together with the prototype of the Wearable platform,
which means that b
oth deliveries are complementary. This deliverable can be considered very
valuable, since it provides comprehensive information about how to use and extend the
Wearable Platform. Before explaining the utilization of the platform, the document describes
how
to configure the environment, and more precisely, how to setup the Enterprise Service
Bus (ESB) that is being used as an integration mechanism of the different middleware
platforms used. The ESB is described in detail in D2.2 (“Semantic Middleware Interop
erability”
formerly known as “Requirements Reception”), hence, this document does not provide
technical details about its functionalities and neither the reasons that lead choosing this
solution, since they are already explained in the previously mentioned
deliverable.
This is the final version of the deliverable, and hopefully provides a full description about the
work performed in this work package over the past months.
1.2
Objectives
The main objective of this document is to serve as a User Guide of the prot
otype of the
Wearable platform. This manuscript provides information about how to use the Wearable
Platform, from the first steps and initial configuration to the usage and consumption of the
services provided by the solution. Therefore, this document cont
ains all the information
necessary in order to make the LIFEWEAR Wearable Platform operational in any environment.
This deliverable is complementary to the Software prototype delivery made in D2.4 “Wearable
platform”
;
hence, it is recommendable to use them
combined. Figure 1
-
1 illustrates the
approach followed for the implementation of the Wearable Platform. More concretely, the
figure depicts how the Semantic Middleware interacts with the developments made in another
work packages, since all together confo
rm the Wearable Platform.
Figure
1
-
1
–
Overview of the LifeWear Wearable platform
and its relationships with other
W
P
s
.
1.3
Overview of sections
Section 2
describes how to install, configure and launch the Ent
erprise Service Bus (ESB) that is
used in the project to
integrate the
different existing middleware approaches into the
LIFEWEAR Semantic Middleware. This section also explains the additional libraries that are
necessary to install in the ESB in order to
ensure the correct operational of the provided
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
4
/
39
solution. Section 3 exemplifies how to use the LIFEWEAR Ontology API implemented in WP5
that facilitates methods and function to easily interact with the underlying ontology. Usage of
the Ontology API is mand
atory for each of middleware that are integrated in
LIFEWEAR
(through the ESB), so its installation in the ESB is another step of the working environment
setup procedure.
Later, Section 4 explains how to actually use the LifeWear Wearable Platform. On one
side, it
explains the installation and main characteristics of each of the gateways created for each
specific middleware that is integrated into the LifeWear Wearable Platform. This section also
describes the list of REST (REpresentational State Transfer)
services provided by each of the
middlewares. On the other side, this section provides a general explanation on how to
consume the REST services from the final applications that are being developed in WP4.
Section 5 summarizes how to access to the first
prototype of the Wearable platform in the
project repository. Finally, Section 6 presents the conclusions and the planned steps for the
next version of the Wearable Platform. Additionally, external references are summarized in
Section 7.
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
5
/
39
2
WEARABLE PLATFORM
ESB
The ESB implementation chosen for this project is Fuse ESB
[1]
. Based on Apache ServiceMix
[2]
, Fuse ESB is standards
-
based and built using open source technology. The most important
features a
re that it is lightweight, multi
-
platform, and it uses the OSGi framework, providing a
mechanism that automates creating and maintaining OSGi bundles (FAB, Fuse Application
Bundle).
Fuse ESB supports the Java Business Integration (JBI) specification (JSR
208), JMS, HTTP, HTTPS,
FTP, XMPP, Web services, and a number of other bindings. Fuse ESB connectivity options can
be extended by using routing and integration components and it can be coupled to other
infrastructure services over a wide variety of transpo
rt protocols and data formats.
Finally, Fuse ESB supports event
-
driven architectures. Services deployed into the Fuse ESB
container can be fully decoupled, waiting idle on the bus until an appropriate service request
arrives.
The version of Fuse ESB used
in this project is the 4.4.1. Documentation and installation files
can be found under
their website
[3]
.
2.1
FIRST STEPS
2.1.1
Prerequisites
Java JDK 6 or later
[4]
§
SET
JAVA_HOME
environment variable to
J
DK_folder
installation directory
§
Add
JAVA_HOME /bin
to
PATH
environment variable
Ma
ven
[5]
§
SET
M2_HOME
environment variable to
MAVEN
installation directory
§
Set
MAVEN_OPTS
environment variable to
-
Xmx512M
to give the Ma
ven build more
memory in which to run
§
Add
JDK_MAVEN/bin
to
PATH
environment variable
2.1.2
Installation
2.1.2.1
Windows
Fuse ESB 4.4.1, is packaged either as a .zip file (Windows) or a .tar.gz file (*NIX). Using
a suitable archive tool, such as Zip or Gunzip, unpack
the distribution into a directory
Configuration:
§
Fuse ESB uses Apache Felix OSGi container by default
§
For changing it to Eclipse Equinox, open
etc/config.properties
file, change the
property
karaf.framework
to be:
karaf.framework=equinox
2.1.2.2
Linux
Downlo
ad the Fuse ESB Enterprise archive from the FuseSource Web
[6]
. The archive is
packaged as a tar.gz file. Unpack the archive in the target folder.
Configuration:
§
Fuse ESB uses Apache Felix OSGi container by default
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
6
/
39
§
For ch
anging it to Eclipse Equinox, open
etc/config.properties
file, change the
property
karaf.framework
to:
karaf.framework=equinox
2.1.3
Launching
NOTE: Some hints on how to interact with the ESB console after launching can be found in [1].
2.1.3.1
Windows
Start cmd.exe, go
t to
FUSE_ESB_INSTALLATION/bin
directory
Run the following command:
servicemix.bat
NOTE: Fuse ESB takes some time to load all its components and features, give it some time to
make sure it is started successfully
2.1.3.2
Linux
Open a terminal window and move to
F
USE_ESB_INSTALLATION/bin
directory
Run the following command:
./servicemix
NOTE: Fuse ESB takes some time to load all its components and features. A prompt and the
SERVICEMIX logo will appear when it has been started successfully.
2.2
Installation of LifeWear
bundles/libraries
This step has to be done before installing the specific components that set up the Wearable
Platform and that are introduced in Section 4. This step has also to be done before deploying a
bundle in the ESB with dependencies to the LifeWe
ar Ontology API. It is also mandatory to
follow the order indicated: API and API_Libraries afterward, otherwise unexpected behavior
may occur
.
NOTE: Make sure that the ESB is started, otherwise it’s not possible to deploy any bundle
within it.
2.2.1
WP5 Ontology
2.2.1.1
Ontology model configuration
Create a folder named “/ontologies” within the ESB directory and copy the .owl file containing
the model inside that folder
.
2.2.1.2
API libraries
To install the libraries that are required by the Ontology API, execute the following c
ommand
in the console of the ESB:
karaf@root> install file:[PATH]/API_Libraries.jar
NOTE: Substitute “PATH” with the location of the .jar file in your file systems.
After the execution of the install command and if everything is OK, a message showing the
i
dentifier assigned to the bundle is show in the console. The message should be similar to:
“Bundle id is 1”.
Once installed, the next step is to start the bundle. To do so, execute the following command:
karaf@root> osgi:start [bundleID]
NOTE: Substitute
“bundleID” with the identifier assigned after the installation
.
2.2.1.3
Ontology
API
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
7
/
39
The next step is then to install the bundle that provides the methods to access and interact
with the LifeWear ontology. In order to install it, execute the following command:
k
araf@root> install file:[PATH]/ API.jar
As before, once installed, the next step is to start the bundle using the command:
karaf@root> osgi:start [bundleID]
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
8
/
39
3
USAGE OF
THE
LIFEWEAR ONTOLOGY AP
I
The goal of this section is to describe how to create an execu
table project that consumes the
LifeWear Ontology API functionalities. The explanations given in this section and the pictures
attached to illustrate the process are based in the utilization of Eclipse as development
framework. Using
a
different developmen
t framework (such as Netbeans) is of course also
possible and the steps to reproduce are in essence the same. The objective of the
development is to obtain a deployable JAR file to be installed into the ESB, thus, the
implementation is not linked at all wi
th the development framework.
In order to deploy a bundle that uses the Ontology API into the ESB, the ontology API bundle
and the associated libraries bundle as explained in section 2.2.1 of the document have to be
already installed in the target ESB. Als
o, is also important to make sure that the ESB also
contains the ontology .owl model, otherwise any calls to the Ontology API will not work, since
the ontology semantic model is missing.
The steps to develop an ESB compliant bundle are listed below:
1.
Creat
e a new project of Plug
-
in nature.
2.
Edit the dependencies of the plug
-
in in the Manifest file as illustrated in Figure 3
-
1.
a.
Add a “Required Plug
-
ins” dependency to “OntologyLibraries”.
b.
Add an “Imported Packages” dependency to “context_API_Lifewear”.
NOTE: I
f the dependencies are added manually, Eclipse will report errors, since it is not
able to find the required plug
-
ins. Eclipse does not need to satisfy these requirements
correctly, since the goal is to deploy the jar in the ESB. However, in order to avoid
errors during the
bundle
development, and to make sure that the correct imports are
included and that the code is free of errors, it is possible to solve the errors with the
dependencies. In order to avoid the errors, copy the “OntologyLibraries” and the
“API”
.jar file in the “plugins” folder of Eclipse. Then, restart Eclipse and the errors should be
gone.
Figure
3
-
1
–
Required Ontology API and Ontology Libraries dependencies
1.
Now
it’s
time to use the Onto
logy API in our code. Some usage examples follow below:
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
9
/
39
Modifying context information
:
Modifying context information
: The below code creates a
new person named “
Fani
” and a new activity named “
working
”. Then the created activity
is added to the list of act
ivities that “
Fani
” is doing. This is accomplished as a transaction
.
Reading context information
:
The below code prints all the People concept instances
currently existing in the context model and the Activities instances bein
g performed by
those people
.
Printing all the context information represented in the context model
:
The next code
builds a SPARQL query to obtain all the tuples stored in the model, executes the query and
prints the obtained
results
.
2.
Once the development of the bundle logic has finished, the next step is to export the
project as a JAR in order to test within the ESB.
a.
To export the project select the “JAR file” option as seen on Figure 3
-
2. If you
try to export the project as a deployable plug
-
in the jar will not work in the
ESB.
b.
Configure the JAR name to generate and the export path as seen on Figure 3
-
3.
Select the same options as in the figure and click on the “Next” button (not in
the “Finish”
button).
String sparqlQueryString =
"SELECT ?s ?p ?o WHERE { ?s ?p ?o }"
;
ResultSet results
=Context
Model.executeQuerySELECT(sparqlQueryString);
ResultSetFormatter.out(results);
Con
textModel.transaction_begin(
"READ"
);
List people=Factory.
getAllPerson
(model);
Iterator it_p=people.iterator();
PersonImpl aux;
Iterator it_ac;
while
(it_p.hasNext()){
aux=(PersonImpl) it_p.next();
it_ac= aux.getActivity();
System.
out
.println(
"Activities tha
t "
+ aux.getName() +
" is doing:
"
);
while
(it_ac.hasNext()){
System.
out
.println(
"
\
t"
+((ActivityImpl)it_ac.next()).getName())}
}
ContextModel.
transaction_commit
();
Model model= ContextModel.model;
ContextModel.transaction_begin(
"WRITE"
);
PersonImpl p=(PersonImpl)
Factory.
createPer
son
(
"http://www.pros.com/individuals/Fani"
,
model
);
p.setName(
"Fani"
);
ActivityImpl a= (ActivityImpl)
Factory.
createActivity
(
"http://www.pros.com/ individuals/working"
,
model);
a.setName(
"working"
);
p.addActivity(a);
ContextModel.
transaction_commit
();
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
10
/
39
Figure
3
-
2
–
Option selected to export the Bundle as a JAR file
Figure
3
-
3
–
Configuration of the JAR file main properties
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
11
/
39
c.
Click again in the “Nex
t” button until you see the “JAR Manifest Specification”
option at the top of the window. The “Generate the manifest file” option is
selected by default, but it is necessary to select the “Use existing manifest
from workspace” instead as depicted in Figure
3
-
4, and select the
MANIFEST.MF file already existing in the project. This is
important;
otherwise
the JAR generated will not work in the ESB, because with the default option
the dependencies are not correctly included
.
Figure
3
-
4
–
Configuration of the JAR file Manifest properties
d.
Click on the finish button to generate the JARs file in the specified folder
.
3.
Now, the bundle is ready to be used in the ESB. Just install the file, start it and it should
be wo
rking and functional.
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
12
/
39
4
USAGE OF THE LIFEWEA
R WEARABLE PLATFORM
The integration of multi
-
disciplinary and heterogeneous devices in the Wearable platform is
internally performed by the means of integrating already existing middleware solutions as
depicted
in Figure 4
-
1. These different middleware solutions are also integrated in the ESB
following the same approach, which is to define a bundle gateway for each one in order to
make them “LIFEWEAR compliant”. Then, the LIFEWEAR ontology defined in WP5 provides
a
common interface to the Wearable Platform to share the information. Finally, the Applications
developed in WP4 connect to the ESB and consume the information available in the LIFEWEAR
ontology through the utilization of REST services
.
Figure
4
-
1
–
Overview of the LifeWear Wearable Platform internal Architecture
The approach of the
LIFEWEAR
Wearable Platform illustrated in Figure 4
-
1 is explained into
detail in D2.2 “Semantic Middleware Interoperability”.
Please refer to the mentioned
document to obtain more technical deta
i
ls about it, since the current document is concretely
focused on how to use the Wearable Platform.
The following subsections explain how to utilize the Wearable Platform at different le
vels.
First, subsection 4.1 explains how to integrate the date collected by the final devices in the ESB
thorough the utilization of intermediate middleware solutions. Secondly, subsection 4.2
explains how to utilize the REST services that are provided by
the Wearable Platform. It can be
said that this part is what really represents the essence of the Wearable Platform. Any final
user that wants to interact with the platform, should do it through these services, so it does
not matter how the platform intern
ally works. In order to define a new final application a user
can directly consume the data provided by the REST services or create a new ESB bundle that
uses the Ontology API
.
4.1
Deployment of producer bundles
This section explains how to install and deplo
y the gateways bundles defined for each
intermediate middleware in the ESB of the Wearable Platform. For each middleware the main
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
13
/
39
characteristics, the devices connected to it and also the data provided by these devices are
described, which are finally REST
services
.
4.1.1
Sarein
–
Tecnalia
The middleware provided by Tecnalia is being used in the Ubiquitous Computing
scenario/demonstrator. For the time being, this producer bundle only provides sensors values.
The sensor measurements gathered are Temperature, Ambie
nt Light (both indoor and
outdoor, since there is more than one sensor deployed) and Weight Measurements taken from
a Weight Scale. These values are used in the scenario as additional sources of information in
order to generate the recommendations that ar
e presented to the user. For example, if the
outdoor temperature sensor detects a very high value, the recommendation to the user would
be to practice indoor exercise in order to avoid suffering sunstroke and the subsequent
problems that may affect the hea
lth of the person. User weight is taken into consideration
when recommending the type of exercise to perform.
The integration of the Tecnalia middleware in the ESB is divided in two steps. On the one side,
a bundle that serves as a gateway to the middlewa
re and makes the information provided by
the middleware LIFEWEAR compliant through the utilization of the LIFEWEAR Ontology
(storing also the data within it). On the other side, a bundle that connects to the Ontology and
offers the REST services associated
with the information of the devices provided by the
underlying middleware. The Figure 4
-
1 below illustrates the described process
.
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
14
/
39
Figure
4
-
2
Tecnalia Middleware integration with ESB
4.1.1.1
Prerequisites
4.1.1.1.1
Devices
For the time being, t
he device that is currently being utilized in this producer bundle is the
SunSPOT World Kit
[7]
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
15
/
39
Figure
4
-
3
–
SunSPOT Java Development Kit
This kit include
s wire
-
free sensor boards that provide different sensors measurements. The
boards can be combined in several ways to create complex networks of sensors.
The other element used is the weight scale from TaiDoc, model TD
-
2551.
Figure
4
-
4
-
TaiDoc Weight Scale
The weight scale provides measurements about weight and BMI. Communication with it is
granted thanks to an API provided by TaiDoc, but no more data can be provided because a
non
-
disclosure agreement bet
ween Tecnalia and TaiDoc was signed
regarding
this subject.
4.1.1.1.2
Libraries
No additional libraries are necessary to install in the ESB in order to make the
bundles run
correctly.
4.1.1.2
Bundles installation and configuration
As explained before, this solution is divi
ded in two different bundles that
have to be deployed
in the ESB in the following order:
-
Gateway bundle
This bundle is used to translate the ontology terms used in Tecnalia middleware
to the ones used in the ontology API, since they are different ontologie
s, a
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
16
/
39
translator is needed. It used the ontology API to create the correspondent
LIFEWEAR ontology concepts. The name of the file is “
kp.integrator.plugin.jar
”.
The command to install the bundle in the ESB is the following:
karaf@root> osgi:install file:[PA
TH]:/ kp.integrator.plugin.jar
NOTE: Substitute “PATH” with the actual location of the jar in the
filesystem.
After executing the command the ESB associates a bundle Id to the element
just installed. Now, in order to
get the bundles
working
its
necessary t
o start it
using the following command:
karaf@root> osgi:start [bundleID]
-
REST interface bundle
This project depends on MAVEN
[5]
in order to provide the REST services
through the ESB. Since this bundle access the information a
vailable in the
LIFEWEAR Ontology in order to generate the REST services using JSON
messages, it is necessary to make sure that the Ontology API and the Ontology
Libraries have been previously installed in the corresponding MAVEN libraries
folder. The comm
ands to install these required bundles in the Maven
repositories are listed below:
cmd> mvn install:install
-
file
-
Dfile=20120524113250API_Libraries.jar
-
DgroupId=org.lifewear
-
DartifactId=20120524113250API_Libraries
-
Dpackaging=jar
-
Dversion=1.0.0
cmd> mvn
install:install
-
file
-
Dfile=API.jar
-
DgroupId=org.lifewear
-
DartifactId=API
-
Dpackaging=jar
-
Dversion=1.0.0
Once the bundles have been installed in MAVEN, the next step is to install the
bundles in ESB. The name of the file is “
lifewear.as.rest.json.jar
”
. The steps to
install and start this bundle are the same as explained before:
karaf@root> install file:[PATH]:/ lifewear.as.rest.json.jar
karaf@root> osgi:start [bundleID]
4.1.1.3
List of REST provided services
The previously explained bundles offer the following
REST services:
-
Outdoor Temperature.
-
Indoor Temperature.
-
Outdoor Light.
-
Indoor Light.
-
Weight
-
Scale.
In order to consume these services, it’s very important to know in advance the [IP] and [Port]
that is utilized by the server to expose the services. +
Out
door Temperature
The URI to consume the service is as follows:
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
17
/
39
http://
[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/temperature_outdoor.json
The format of the answers proved is the following:
The possible measurements units f
or this value are: Celsius,
Fahrenheit
and Kelvin. By default
the temperature value is provided in Celsius
.
Indoor Temperature
The service can be reached at the following URI:
http://
[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/temperature_indoor.json
The format of the answer is as follows:
The possible measurements units for this value are: Celsius,
Fahrenheit
and Kelvin. By default
the temperature value is provided in Celsius
.
Outdoor Light
The URI to consume the servic
e is:
http://
[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/light_outdoor.json
The format of the answer is the following:
{
light_outdoor_value:
"X"
light_outdoor_unit: "X"
}
{
temperature_indoor_value: "X"
temperature_indoor_unit: "X"
}
{
temperature_outdoor_value: "X"
temperature_outdoor_unit: "X"
}
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
18
/
39
The possible measurements units for this value are:
Luminance, Candela and Lux
. By default
the temperat
ure value is provided in Luminance
.
Indoor Light
The service is available at the URI below:
http://
[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/light_indoor.json
The format of the answer is as follows:
The possible measure
ments units for this value are:
Luminance, Candela and Lux
. By default
the temperature value is provided in Luminance
.
Weight Scale
The service is available at the URI below:
http://
[IP]:[PORT]
/cxf/lifewear/LifewearServices/get/scale_weight.json
The for
mat of the answer is as follows:
The possible measurements units for this value are: Kilograms and Pounds. By default the
weight value is provided in Kilograms.
4.1.2
UPM
UPM middleware is used in the Ubiquitous Computing scenario.
This middleware produces
both context (room temperature) and user´s physiological parameters (body temperature,
breath rate and heart rate). These values are utilized in the scenario as additional sources of
information in order to generate the recommenda
tions that are presented to the user. These
{
scale_weight_value: "X"
scale_weight_unit: "X"
}
{
light_indoor_value: "X"
light_indoor_unit: "X"
}
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
19
/
39
values are also used for alarms generation (
e.g.
: when the heart rate exceeds a specified value,
an alarm is sent to the user recommending stopping the exercise).
Alarms can be presented in a wide range of wearab
le devices:
smart phones
, WIMM Android
Watch
[10]
, etc.
The integration of the UPM middleware in the ESB is composed by a single bundled deployed
inside the ESB. This bundle acts a gateway between the WSN and the REST interface
offered to
access the services. The ontology is also used to store the data collected. A general overview of
the architecture is shown in next figure
.
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
20
/
39
Figure
4
-
5
UPM Middleware integration with ESB
4.1.2.1
Prerequisites
4.1.2.1.1
Devices
The WSN is composed by SunSpot nodes, from Oracle
[7]
.
The device used to monitor user´s physiological data is the
Zephyr Bioharness
[11]
.
This device
is able
to collect several physiological data (heart rate, acceleration, position, breath data,
temperature, ECG, etc.). This bundle uses the heart rate, breath rate and body temperature.
4.1.2.1.2
Libraries
A standard Fuse/ESB installation includes all the required librar
ies for the UPM bundle.
4.1.2.2
Bundles installation and configuration
It is only necessary to install and start the UPM
-
Lifewear bundle:
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
21
/
39
osgi:install lifewearUPM
(This command installs bundle in the ESB)
osgi:start [bundle ID]
(This command starts the bundle
)
4.1.2.3
List of REST provided services
UPM lifewear bundle offers the following REST services:
-
Room Temperature.
-
Body Temperature.
-
Breathing rate.
-
Heart rate.
-
Alarms.
Room Temperature
The URI to consume the service is as follows:
http://
[IP]:[PORT]
/
cxf/crm/li
fewear/temp/[room_ID]
The JSON answer is as follows:
The possible measurements units for this value are: Celsius or
Fahrenheit
.
Body Temperature
The URI to consume the service is as follows:
http://
[IP]:[PORT]
/
cxf/crm/lifewe
ar/bodyTemp
The JSON answer is as follows:
{
"transport": "j2me.radiogram",
"envelope": "JSON
-
2.0",
"target": "[destination_addres
s]",
"origin": "[source_address]",
"response":
{
"operation": "temp",
"parameters": [ C , 0 ] ,
"result": "VALUE"
}
}
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
22
/
39
Measurement unit: Celsius.
Breathing Rate
The URI to consume the service is as follows:
http://
[IP]:[PORT]
/
cxf/crm/lifewear/breathRate
The JSON answer is as follows:
Measurement unit: Breathings per minute.
{
"transport": "j2me.radiogram",
"envelope": "JSON
-
2.0",
"target": "[destination_address]",
"origin": "[source_address]",
"respon
se":
{
"operation": "breathRate",
"parameters": [ VOID ] ,
"result": "VALUE"
}
}
{
"transport": "j2me.radiogram",
"envelope": "JSON
-
2.0",
"target": "[destination_address]",
"origin": "[sourc
e_address]",
"response":
{
"operation": "bodytemp",
"parameters": [ VOID ] ,
"result": "VALUE"
}
}
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
23
/
39
Heart Rate
The URI to consume the service is as follows:
http://
[IP]:[PORT]
/
cxf/crm/lifewear/HeartRate
The JSON answer is as follows:
Measurement unit: Beats per minu
te.
Alarms service
The URI to consume the service is as follows:
http://
[IP]:[PORT]
/
cxf/crm/lifewear/alarm
The JSON answer is as follows:
{
"transport": "j2me.radiogram",
"envelope": "JSON
-
2.0",
"target": "[destination_address]",
"origin": "[source_address]",
"response":
{
"operatio
n": "HeartRate",
"parameters": [ VOID ] ,
"result": "VALUE"
}
}
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
24
/
39
4.1.2.4
Security mechanisms
The middleware also includes some security mechanisms in order to
guarantee that only
authorized nodes are able to publish or consume data. The security system is based on trust
domains, and it is composed by several elements, which are presented below.
The Security Manager (SM) is the principal actor of the security m
odel, and should be an
external host able to generate symmetric and asymmetric keys securely. The ESB is the perfect
candidate for this task, but it is open for other elements depending on the implementation.
Several nodes (N) sharing the same Domain Key (
DK) and some aspects in common (mission,
localization, capabilities, etc.) define a Trust Domain (TD). Each TD has a Trust Policy (TP),
including the behaviors, measures, actions and other aspects regarding the life
-
cycle of a Trust
Domain. Also a Domain K
ey Server (DKS) exists in each TD.
The DKS
is a special node in charge
of distributing the Domain Key when needed. A single node can act as a DKS if the Security
Manager decides it.
Every
node in the network has its own Node
unique identification
(NID)
and
an individual Node Key (NK). The ciphering methods and keys sizes used when ciphering a
message are defined inside the Ciphering Suite (CS).
Since WSN nodes have several limitations, a full and robust Public Key Infrastructure
(PKI)
should not fit these
nodes. For this reason, a hybrid PKI and symmetric keys schema has been
used in this project.
Two types of keys are used in PKI cryptography: Public Key (Kp), the part of
the key assumed to be freely distributed, and Private Key (Ks), the part of the key t
o be kept in
secret and not distributed. In this security model,
PKI is used for the communication between
special nodes (Security Manager and Domain Key Server), and a simple
-
but
-
secure AES
symmetric key is used for the
regular
nodes. Size of this AES key
is constricted by the nodes
computing power and, thinking in a scalable architecture, is defined by a Ciphering Suite field
in the ciphered data packets, in order to determine the length of the key or select a new
algorithm (such as RC5, etc.).
Trust Doma
ins definition can be done following several policies: number of nodes per domain,
node localization, domains for specific functionality (e.g.: temperature measurement, intrusion
detection, environmental monitoring, etc.) or any other distribution demanded
by a specific
application.
{
"transport": "j2me.radiogram",
"envelope": "JSON
-
2.0",
"target": "[destination_address]",
"origin": "[source_address]",
"response":
{
"operation": "alarm",
"para
meters": "ALARM_TYPE" ,
"result": "VALUE"
}
}
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
25
/
39
For each Trust Domain defined, a Domain Key Server is assigned (either in deployment or run
time) and a Domain Key is shared. Any node participating in a TD can assume the DKS role if
the former DKS has been compromised. If the
compromise affects only a simple node, a re
-
keying method is enough: DKS asks SM for a new DK, and then this new key is sent to all nodes
but the compromised one, using each Node Key.
Domain Key Server stores its own pair of public and secret keys (and als
o the public key of the
Security Manager, so as to communicate with it), the Domain Key (to communicate with nodes
participating in the domain) and the security policy for the domain.
The other nodes also need to keep some important information: the node
id and key, the
Domain Key, the public key of the Security Manager (used if Security Manager assigns the role
of the former Domain Key Server to a new node)
.
Cryptographic information shared by nodes has been reduced to a minimum, in order to
minimize the
risk when a node is compromised. In
this
security model
, if a single node or a DKS
is compromised, just the Domain Key is evidenced (as the public key of the SM can be revealed
without security issues). Re
-
distributing a new DK or designating a new DKS wil
l be enough to
recover the
confidence
.
4.1.3
Deusto
-
Treelogic
Deusto
–
Treelogic bundle is the bundle developed in healthcare demonstrator. This bundle
manages the connection and data exchange between the ESB and the University of Deusto
middleware: Otsopack
[13]
. It is integrated in the ESB as an OSGI
-
bundle and it consists in an
Otsopack node that consumes data from the middleware as long as it receives REST petitions
from the application layer
.
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
26
/
39
Figure
4
-
6
Deusto
–
Treelogic Middleware integration with ESB
4.1.3.1
Prerequisites
4.1.3.1.1
Devices
The devices used in this bundle are the following ones:
Zephyr HxM
[12]
–
This device can monitor heart rate, instant speed dis
tance… but in this
bundle development, it only has been considered the following parameter:
Heart Rate
Zephyr Bioharness
[11]
–
This device is able to collect data form ECG, heart rate, acceleration,
position, breath data, tempe
rature… but in this bundle development, it only have been
considered the following parameters:
Heart Rate
Breath Rate
Electrocardiogram
Breathing Wave
4.1.3.1.2
Libraries
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
27
/
39
With the bundle installation, all required libraries are included, the only one that needs to
be
installed as an OSGI bundle is the
Ostopack library
[2
]
. It is required because an Ostopack
middleware’s node is integrated in the bundle.
This library must be installed from the ESB console with the next command:
osgi:install
–
s wrap:file:///
fileURL
Th
is command installs the library as a bundle in the ESB.
4.1.3.2
Bundles installation and configuration
The Deusto
-
Treelogic bundle is a Maven project and it has been developed with an open
source IDE, Eclipse. For this reason, the Eclipse
plug
-
in
“Maven Integra
tion for Eclipse” is
required. It can be downloaded from here:
http://marketplace.eclipse.org/content/maven
-
integration
-
eclipse
Once Eclipse is configured and ready for Maven,
these are the required steps for installing the
bundle in the ESB:
1)
The bundle must be compiled and installed in the Maven local repository. Because of
this, user should execute the following Maven instructions in the bundle Eclipse
project in the followin
g order.
i.
Maven Clean
ii.
Maven Generate
-
Sources
iii.
Maven Install
2)
Once the bundle has been installed in the Maven local repository, user must execute
these commands in the ESB console to deploy the OSGI bundle in the ESB.
a.
Installing the bundle in the ESB from the
Maven repository
osgi:install mvn:
groupId/artifactId
groupId
-
org.apache.servicemix.lifewearOSTO
artifactId
-
lifewearOSTO
After this installation command, the ESB assigns a “bundle ID” to the bundle.
This ID is required to manage the bundle (Start, Stop
, Delete).
b.
Starting the bundle execution
osgi:start
bundleID
Once the bundle has been started, it is ready to manage the REST requests. It
can be Stopped and Deleted with the following commands
osgi:stop
bundleID
osgi:uninstall
bundleID
3)
If the bundle proje
ct is modified, it will be necessary to repeat step 1) in the Eclipse
project, and update the bundle in the ESB with this command:
osgi:update
bundleID
4.1.3.3
List of REST provided services
Deusto
-
Treelogic bundle, offers the following REST services:
Heart Rate
service
Breath Rate service
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
28
/
39
Breathing Wave service
Electrocardiogram service
With these descriptions:
Heart Rate service
This service allows users to check the instant Heart Rate value received from the devices.
Its response is a JSON with multiple paramet
ers, but the Heart Rate value is contained in
the “
service_value
” tag. The rest of the JSON information contains the service units, the
service type, a timestamp the device name, the user name… This parameter can be read
from both devices (HxM and Bioharne
ss), so there is a parameter that allows users to
choose which device they want to use (if they want to specify any).
URI
–
http://
[IP]:[PORT]
/lifewear/example/pulse?device=
[DEVICE]
&callback=?
[IP]:[PORT]
: It is the IP direction and port of the ESB serve
r.
[DEVICE]
: It allows choosing the device to monitor the heart rate. It has three possible values,
with three possible responses.
“bioharness”
: JSON Response structure
?({
1:{
service_name
:
"Instant Heart Rate"
,
service_state
:
""
,
(active/inactive)
se
rvice_timestamp
:
""
,
(number of packet)
device_name
:
"Bioharness"
,
person_name
:
""
,
(not used yet)
service_type
:
"float"
,
service_units
:
"bps"
,
service_value
:
value
},
})
“hxm”
: JSON Response structure
?({
1:{
service_name
:
"Instant Heart Rate"
,
servi
ce_state
:
""
,
(active/inactive)
service_timestamp
:
""
,
(number of packet)
device_name
:
"Zephyr HxM"
,
person_name
:
""
,
(not used yet)
service_type
:
"float"
,
service_units
:
"bps"
,
service_value
:
value
},
})
“all”
: JSON Response structure
?({
1:{
serv
ice_name
:
"Instant Heart Rate"
,
service_state
:
""
,
(active/inactive)
service_timestamp
:
""
,
(number of packet)
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
29
/
39
device_name
:
"Bioharness"
,
person_name
:
""
,
(not used yet)
service_type
:
"float"
,
service_units
:
"bps"
,
service_value
:
value
},
2: {
servic
e_name
:
"Instant Heart Rate"
,
service_state
:
""
,
(active/inactive)
service_timestamp
:
""
,
(number of packet)
device_name
:
"Zephyr HxM"
,
person_name
:
""
,
(not used yet)
service_type
:
"float"
,
service_units
:
"bps"
,
service_value
:
value
}
})
This paramet
er is the only one which can be obtained from both devices. For this reason,
its JSON response (device=all) is composed by two JSON responses.
Breath Rate service
This service allows users to check the instant Breath Rate value received from the Zephyr
B
ioharness. Its response is a JSON with multiple parameters, but the Breath Rate value is
contained in the “
service_value
” tag. In the same way as Heart Rate service, the rest of
the JSON information contains the service units, the service type, a timestamp
the device
name, the user name…
URI
–
http://
[IP]:[PORT]
/lifewear/example/brate?callback=?
[IP]:[PORT]
: It is the IP direction and port of the ESB server
JSON Response structure
?({
service_name
:
"Instant Breathing Rate"
,
service_state
:
""
,
(active/
inactive)
service_timestamp
:
""
,
(number of packet)
device_name
:
"Bioharness"
,
person_name
:
""
,
(not used yet)
service_type
:
"float"
,
service_units
:
"bps"
,
service_value
:
value
})
Electrocardiogram service
This service allows users to check the user’s
Electrocardiogram (ECG) received from the
Zephyr Bioharness. Its response is a JSON with multiple parameters, but the ECG array is
contained in the “
service_values
” tag. This tag is an array with the user’s ECG in a
temporal window of 2 seconds long aprox.
As the rest of the REST services, the rest of the JSON information contains the service
units, the service type, a timestamp the device name, the user name…
URI
–
http://
[IP]:[PORT]
/lifewear/example/ECG?callback=?
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
30
/
39
[IP]:[PORT]
: It is the IP direction and
port of the ESB server
JSON Response structure
?({
service_name
:
"ECG"
,
service_state
:
""
, (active/inactive)
service_timestamp
:
""
,
(number of packet)
device_name
:
"Bioharness"
,
person_name
:
""
,
(not used yet)
service_type
:
"float"
,
service_units
:
"
mV"
,
service_initial_time
:
""
,
service_time_step
:
0.004
,
service_num_values
:
504
,
service_values
:
[
Value0,
Value1
,
Value2
,
…
Value503
]
})
Breathing wave service
This service allows users to check the user’s Breathing wave (BWave) received from the
Zephyr
Bioharness. Its response is a JSON with multiple parameters, but the BWave array
is contained in the “
service_values
” tag. This tag is an array with the user’s breathing
wave in a temporal window of 5.9 seconds long aprox.
As the rest of the REST services
, the rest of the JSON information contains the service
units, the service type, a timestamp the device name, the user name…
URI
–
http://
[IP]:[PORT]
/lifewear/example/bwave?callback=?
[IP]:[PORT]
: It is the IP direction and port of the ESB server
JSON Re
sponse structure
?({
service_name
:
"Breath Rate Array"
,
service_state
:
""
, (active/inactive)
service_timestamp
:
""
,
(number of packet)
device_name
:
"Bioharness"
,
person_name
:
""
,
(not used yet)
service_type
:
"float"
,
service_units
:
"Amplitude"
,
serv
ice_initial_time
:
""
,
service_time_step
:
"0.05556"
,
service_num_values
:
108
,
service_values
:
[
Value0,
Value1
,
Value2
,
…
Value107
]
})
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
31
/
39
4.1.4
Telefonica I+D
In order to integrate applications in L
IFEWEAR
project, an ESB has been provided via an OSGI
bundle. Thank
s to this bundle, the applications developed by consortium partners may be
integrated in a single platform.
In our case (group training application) we have not used most of the functionalities provided
by the ESB. The main functions used are hardware and
location abstraction for the data server
and the client application, i.e. The ESB is mainly used between the server and the client as a
bridge. This is shown in
the following figure:
Figure
4
-
7
TID ESB int
egration into LIFEWEAR platform
T
he exchange of data between the client
PC
, the OSGI server
bundle
–
the ESB
-
and the
server
providing the data
can be seen
with more detail in
the following figure
.
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
32
/
39
Figure
4
-
8
Client
-
Server interaction detail
One of the main advantages of the ESB approach is the possibility to use resources provided by
other partners or entities, thus being able to use data coming from different sensors such as
outdoor temperature, humid
ity, etc.
By using the ESB we could also combine data from different sensors to obtain more complex
services. For instance, we could compose the data provided by an ambient measuring device
with the data provided by a vital constants measuring device to ob
tain other not so evident
data such as instant performance, performance evolution, tiredness,
health risk detection,
illness, etc.
4.2
R
est services
consumption
guide
Most of the data exposed by the LIFEWEAR framework can be consumed by making queries
using a
REST interface that, when responding, offers the data using the well
-
known JSON
format. The current section, servers as a general purpose user guideline on how to consume
and interact with REST services that provides an answer in the JSON format. To see t
he
concrete list of REST services provided by the Wearable Platform, check the subsections
named “List of REST provided services” that are part of the previous section.
Using JSON implies having to parse or deserialize the response obtained when querying t
o the
LIFEWEAR PLATFORM for data into a specific data representation that varies depending on the
programming language: Javascript, Java, C++, ObjC, etc. Most of the times the objective of the
parsing procedure is to obtain a representation of the response
as an instance of a pre
-
defined
class in the programming language selected.
For instance, if a user of the LIFEWEAR PLATFORM asks for temperature outside a room or
building, most surely this implies that there is a class with concepts such as
:
location
m
easurement
user
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
33
/
39
Etc...
After querying for the data, if there is data existent, response could be something like this:
The message itself needs to be parsed into
an
object representation in most languages, a
process known as “d
ecoding” or “parsing”. There are many ways to achieve this, but most of
them comprise the use of third
-
party libraries that ease the coding/decodin
g JSON messages.
To name a few:
Java
C
C++
C#
PHP
Simple
-
json
Gson
Flexjson
JSONlib
Jettison
org.json
CJSON
json
-
c
Jansson
JSON_checker
jsoncpp
libjson
JSONKit.
ThorsSerialize
r
JsonBox
rapidjson
fastJSON
LitJSON
JsonFx
JSONShar
fluent
-
json
Manatee Json
json
Services_JSON
Zend_JSON
Solar_Json
Obviously there are differences among those libraries, but an analysi
s on those differences is
out of the scope of this document. An example using one of the most famous Java JSON
libraries, Gson, will depict how to parse an incoming JSON message.
Gson converts Java objects into a JSON message and vice
-
versa, is capable of
converting a
JSON message into a Java object. It can even work with objects pre
-
defined, where the source
of t
hese objects is not available.
Let us suppose a developer that uses the LIFEWEAR PLATFORM receives the JSON message
depicted before:
{"message": {
"user": "John Doe",
"measurement": "temperature",
"location": "outdoor",
"value": "32.5",
"unit": "Celsius",
}
}
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
34
/
39
Using Java, Gson and supposing there is
a class named Message, which
could look like this:
The process to transform the received JSON message into an instance of the Message class
could not be simple thanks t
o Gson, as depicted below:
public class Message {
private String USER;
private String MEASUREMENT;
private String LOCATION;
private String VALUE;
private String UNIT;
@Override
pu
blic String toString() {
String ret = new String();
ret = “Message received from “ + USER + “ type “ + MEASUREMENT +
“ in “ + LOCATION + “ with value “ + VALUE + “ expressed as “ +
UNIT;
return ret;
}
}
{"message": {
"user": "John Doe",
"measurement": "t
emperature",
"location": "outdoor",
"value": "32.5",
"unit": "Celsius",
}
}
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
35
/
39
Once Gson converts the JSON message into an
instance
of Message, the developer has full
access to the object properties for further process (storage, reasoning, etc). Clearly this is a
quite straight
forward and simple way to decode JSON messages. This was a simple example,
but Gson can also handle complex object structures, such as those that have lists or arrays
in
the fields section or even
other classes, thanks to the use of Java Reflection.
That
said, a user/developer of the LIFEWEAR PLATFORM has a wide array of
possibilities
to
choose from, selecting the programming language and the associated JSON parsing library in
order to be able to consume the information/services provided by the LIFEWEAR PL
ATFORM.
The usage of a REST interface with JSON responses allows a platform independent data
consumption
and unified
way to ac
cess
that
services/information
although it requires a slight
effort in the developer side for the composition of services.
import java.io.IOException;
import jav
a.io.InputStreamReader;
import java.io.Reader;
import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
public class JsonToJava {
public static void main(String[] args) throws IOException {
Reader reader = new InputStreamReader(JsonToJava.c
lass
.getResourceAsStream("Server.json"));
Gson gson = new GsonBuilder().create();
Message m = gson.fromJson(reader, Message.class);
m.toString();
reader.close();
}
}
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
36
/
39
5
WEARA
BLE PLATFORM IN THE
LIFEWEAR REPOSITORY
The assets that form part of the prototype of the Wearable Platform are available at the
Project management and Wiki website in the following location:
http://lifewear
.info/pm/index.php
NOTE: In order to obtain a username and password to enter this internal website, ask for
credentials to Mobilera, which is in charge of the website.
Once you enter the website, select the “Files” menu option, and at the right side of th
e page
you will see the following menu that contains folders for all the work packages of the project
and also for the demonstrators:
Figure
5
-
1
–
LifeWear project website Files area
The contents of the Wea
rable Platform prototype are located under the “wp2” folder, and
more concretely in the “D2.4 Wearable Platform”
sub
-
folder within it. As depicted in Figure 5
-
2, this folder contains additional folders with the aim to organize the information as described
in the current deliverable, with the aim to facilitate the identification of the different assets.
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
37
/
39
Figure
5
-
2
–
Wearable Platform Prototype contents
These folders contain the libraries and jar bundles me
ntioned along the documents. Sections
2.2.1, 4.1.1.2, 4.1.2.2 and 4.1.3.2 give detailed instructions on how to install the bundles in
order to start working with them.
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
38
/
39
6
CONCLUSION
S
AND FURTHER STEPS
This document represents the final delivery of the LIFEWE
AR Wearable Platform, and is
distributed together with the Platform SW Prototype, with the aim to serve as a usage manual
for the potential users. The installation, configuration and first steps of the different assets
that constitute the Wearable Platform
are described along the document. The development of
the Wearable Platform is finished at this time.
The demonstrators and scenarios defined in WP1 and WP6 play a key role in the development
of the Wearable Platform. To some
extent
, it can be said that th
e development of the Platform
is somehow driven by the evolution of the defined demonstrators. The explanation of this is
that the demonstrators serve to test the robustness and performance of the implemented
solution. The demonstrators have evolved (and c
ontinue evolving) to include new devices and
functionalities, and the different assets that are deployed in Platform ESB have to be updated
accordingly to give support to the new required functionalities.
Thus, this documents
summarizes
all the work devel
oped in WP2 regarding the LIFEWEAR
Wearable Platform. The platform itself should be ready to use in the rest of LIFEWEAR work
packages
.
LifeWear, Mobilized Lifestyle with Wearables
©
LifeWear
39
/
39
7
REFERENCES
[1]
Fuse ESB
http://fusesource.com/product
s/enterprise
-
servicemix/
[2]
Apache Service Mix
http://servicemix.apache.org/
[3]
Fuse ESB enterprise
http://fusesource.com/products/fuse
-
esb
-
enterpris
e
[4]
Java Oracle
http://www.oracle.com/technetwork/java/javase/downloads/index.html
[5]
Maven
http://maven
.apache.org/download.html
[6]
Fuse ESB 4.4.1
http://fusesource.com/products/fuse
-
esb
-
enterprise.Fuse ESB 4.4.1
[7]
SunSpots
http://www.s
unspotworld.com/
[8]
TaiDoc Weight Scale
http://www.taidoc.com/weight
-
scales
-
TD
-
2551.html
[9]
ESB Console commands reference documentation
http://fusesource.com/docs/esb/4.2/command_ref/ESBintro.html
[10]
WIMM One Watch
http://www.wimm.com/
[11]
Zephyr BioHarness
http
://www.zephyr
-
technology.com/team
-
performance/bioharness
-
3/
[12]
Zephyr HmX
http://www.zephyranywherestore.com/corporate/dp/B009I08RB2
[13]
Otsopack Library
http://code.google.com/p/otsopack/
- Αρχική
- Περιήγηση
- Όλες οι Κατηγορίες
- Internet και Εφαρμογές Web
- Αποθήκευση
- Ασφάλεια
- Βιοτεχνολογία
- Δίκτυα και Επικοινωνίες
- Διακομιστές
- Διαχείριση
- Διαχείριση Δεδομένων
- Επιχειρησιακές Εφαρμογές
- Ηλεκτρονική - Συσκευές
- Ημιαγωγοί
- Κινητά – Ασύρματες Τεχνολογίες
- Λογισμικό & κατασκευή λογ/κού
- Μηχανική
- Περιβαλλοντική Τεχνολογία
- Πετρελαϊκά και Εξόρυξη
- Πολεοδομικά Έργα
- Τεχνίτη Νοημοσύνη και Ρομποτική
- Τηλεπικοινωνίες
- Ψυχαγωγία
- Κοινότητα
- Μεταφόρτωση
Σχόλια 0
Συνδεθείτε για να κοινοποιήσετε σχόλιο