SEVENTH FRAMEWORK PROGRAMME

traderainSoftware and s/w Development

Aug 15, 2012 (4 years and 11 months ago)

910 views

SEVENTH FRAMEWORK PROGRAMME

THEME


ICT

[Information and Communication Technologies]





Contract

Number:


224395

Project Title:


Integrated Platform for Autonomic Computing

Project Acronym
:


IPAC


C
C
C
ipa


Deliverable Number:





D21


Deliverable Type:








Contractual Date of Delivery:




31 July 2008


Actual Date of Delivery:





05 August 2008
…….

Title of Deliverable:






State of the Art


Work
-
Package contributing to the Deliverable:


WP2

Nature of the Deliverable:





Report

Author(s
):


C. Anagnostopoulos,
G. D'Angelo
, J.
-
D.

Decotignie
,
K. Gerakos, S.

Hadjiefthymiades,
C.

Kassapoglou
-
Faist
,
K.

Kolomvatsos, D. Kotsakos
, C. Panayiotou
, V. Papataxiarhis
,
T.

Raptis, G. Samaras
, O. Sekkas, D.

Spanoudakis
,
A.

Rongas
,

V.

Tse
tsos


Abstract:

A general and extensive survey
presenting

the relevant enabling technologies. Such
technologies include sensor equipment, communication systems, autonomic computing
,
frameworks and languages for building service creation environments, etc.
Moreover, some state
-
of
-
the
-
art algorithms and research works in the area of context
-
aware computing and information
dissemination are presented
.


Keyword List:

Communication technologies, GUI frameworks, middleware technologies, data
modelling





Copyrig
ht by the IPAC Consortium


(Co
-
ordinator)

Siemens A. E. Electrotechnical Projects and Products

SAE

Greece

Contractor

National and Kapodistrian University of Athens

NKUA

Greece

Contractor

Centre Suisse
d’Electronique

et de Microtechnique SA

CSEM

Switzerla
nd

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

2
/
56

Contractor

CENTRO RICERCHE FIAT S.C.p.A.

CRF

Italy

Contractor

Hellenic Ministry of Defence

HMOD

Greece

Contractor

University of Cyprus

UCY

Cyprus




Table of Contents

1

Introduction

................................
................................
................................
................................
............

3

2

Short range communications technology

................................
................................
...............................

3

2.1

IEEE 802.11

................................
................................
................................
................................
..

3

2.2

Bluetooth (IEEE 802.15.1)

................................
................................
................................
.............

4

2.3

IEEE 802.15.4 and Zigbee

................................
................................
................................
............

4

2.4

DECT

................................
................................
................................
................................
.............

6

2.5

Wireless HART

................................
................................
................................
..............................

6

2.6

Wireless Sensor Networks

................................
................................
................................
............

6

2.7

Wisenet

................................
................................
................................
................................
.........

6

2.8

DSRC

................................
................................
................................
................................
............

7

3

Sensor management

................................
................................
................................
.............................
10

3.1

IEEE 1451 OVERVIEW

................................
................................
................................
................
11

3.2

SensorML overview

................................
................................
................................
......................
12

4

Data modelling technologies based on the XML standard

................................
................................
....
14

4.1

Features of XML

................................
................................
................................
...........................
14

4.2

Strengths of XML

................................
................................
................................
..........................
15

4.3

Weaknesses of XML

................................
................................
................................
.....................
15

4.4

Data modelling with XML

................................
................................
................................
..............
16

5

Service Creation Environments

................................
................................
................................
.............
17

5.1

Development platforms, GUI frameworks and

technologies for SCEs
................................
..........
18

5.1.1

Development Platforms for SCEs

................................
................................
........................
18

5.1.2

Emulators
................................
................................
................................
.............................
19

5.1.3

Service Description Languages

................................
................................
...........................
21

5.1.3.1

Various XML
-
based Service Description Languages

................................
...........................
21

5.2

Relev
ant and Popular Service Creation Environments

................................
................................
.
24

6

Services/Middleware technologies

................................
................................
................................
........
28

6.1

Middleware Technologies

................................
................................
................................
.............
28

6.1.1

Development Platforms

................................
................................
................................
.......
28

6.1.2

Java Virtual Machines for Embedded and Mobile Systems

................................
.................
30

6.1.3

OSGi (Open Service Gateway initiative)

................................
................................
..............
31

6.1.4

Technologies, Protocols and Frameworks for Agent
-
based Systems

................................
..
32

6.2

IPAC
-
like middleware frameworks

................................
................................
................................
33

6.2.1

Sensor Computing
-
oriented Middleware

................................
................................
..............
35

6.3

Autonomic and Reconfigurabl
e Systems

................................
................................
......................
36

6.4

Technologies for the Embedded Knowledge Plane

................................
................................
......
39

6.4.1

Knowledge Representation Languages

................................
................................
...............
39

6.4.2

Language Serialization Modes

................................
................................
.............................
41

6.4.3

Policy Representation Languages

................................
................................
.......................
42

6.4
.4

Mobile Reasoning Techniques and Tools

................................
................................
............
42

6.4.5

Models for Autonomic Computing Platforms

................................
................................
........
43

7

Information dissemination and co
llective context awareness algorithms

................................
...............
45

7.1

Information Dissemination in Nomadic Environments

................................
................................
..
45

7.2

Context Dissemination for
Collaborative Context
-
awareness

................................
.......................
47

8

Similar past and existing EU projects

................................
................................
................................
....
48

9

Conclusion

................................
................................
................................
................................
............
52


July 31, 2008

Report

IPAC ICT
-
2008
-
224395

3
/
56


1

I
ntroduction

This report is presenting a general and extensive survey regarding the relevant enabling technologies for
advanced context awareness. This survey will help in selecting

the appropriate enabling technologies for the

development of the IPAC sys
tem, after the
detailed analysis and specification of the IPAC platform
requirements
has

be
en

done
.

The relevant technologies include sensor equipment, communication systems, autonomic computing, etc.
Enabling technologies for each component w
ere

examined.

Such technologies include among others:



Short range c
ommunication technologies



Sensor management



GUI frameworks like the Eclipse and NetBeans platforms



Data
m
modelling

technologies based on the XML standard



Services/Middleware technologies such as OSGI, J
2ME or other java technologies appropriate for
handheld devices



Information dissemination and collective context awareness algorithms
.

The survey is completed by some assessment of suitable technologies to build the IPAC nodes and the
application creation
environment.

Moreover, an extensive scientific survey for past and existing European projects, related to IPAC,
has

be
en

performed, in order to investigate the possibility of exploiting their results and use them as a guide for
achieving the IPAC’s objecti
ves.

2

Short
range communic
ations

technology

2.1

IEEE 802.11

IEEE 802.11 is an ISO/IEC international standard (ISO/IEC 8802
-
11) originally defined by the IEEE. It is a
wireless LAN for use in the SOHO (Small Office and Home) environment although experiments have

been
made for transmission up to 30 Km. The standard only defines the physical and medium access control
layers. The former originally came in three versions: a basic version with a raw bit rate of 1 and 2Mbit/s, an
extended version (802.11b) at 11 Mbit/s

and a high speed version (802.11a) at bit rates up to 54 Mbit/s. The
first two operates in the 2.4 GHz band while the latter uses the 5 GHz ISM band. More recently, extensions
to 54 Mbit/s (802.11g) and 270Mbits/s (802.11n) in the 2.4GHz band have been re
leased.

The original version of the standard specified
i
nfrared transmission as well frequency
-
hopping and direct
sequence spectrum (DSSS) techniques on radio channels. Nowadays, on the DSSS technique is available.
The high speed version physical layer us
es orthogonal frequency division multiplexing (OFDM) on 52
subcarriers modulated with binary or quadrature phase shift keying (BPSK / QPSK), 16
-
QAM (Quadrature
Amplitude Modulation) and 64 QAM.

CSMA with collision avoidance is used as a medium access contr
ol. Collisions are partially avoided by
sending reservation frames (RTS) that are acknowledged by the receiver using a CTS frame. Both frames
include the reservation duration. When receiving one or both of these frames, all other stations refrain from
requ
esting any traffic. This mode of operation corresponds to the DCF (Distributed Coordination Function).
In this mode, there is no temporal guarantee. When guarantees are required, the PCF (Point Coordination
Function) can be used. A special node, the point
coordinator, is used to create a cycle in the traffic. This
cycle is split in two parts. In the first part, there is no contention and medium access control is managed by
the point coordinator. In the second part, all nodes can compete as in the previous m
ode. None of the
currently available products implement PCF which is now obsolete. 2007 has seen the approval of a QoS
oriented version of the standard (802.11e) that adds new rules to the medium access control while keeping
compatibility. It defines 4 cla
sses of traffic and an equivalent of the PCF called HCF (Hybrid Coordination
Function). IEEE 802.11e keeps the compatibility with the previous versions.

IEEE 802.11 operates in two different modes, ad
-
hoc and infrastructure. In the infrastructure mode, spe
cial
nodes, access points, are connected to conventional networks (typically Ethernet) and act as coordinators
for the traffic on the wireless side and bridges between the wired and the wireless parts. In such a mode,
wireless nodes associate to an access
point and all traffic either originate or goes the access point. In the
ad
-
hoc mode, wireless nodes may communicate directly from node to node in direct visibility, all nodes
being equal.

The standard also defines encryption to protect the transmissions.

IEEE 802.11 is possibly the most widely spread wireless local area network technology. It suffers from two
main drawbacks, its high power consumption and the absence of a good solution for mesh networks. Mesh
July 31, 2008

Report

IPAC ICT
-
2008
-
224395

4
/
56

networks may be supported if all nodes become r
outers. Solutions are often based on IP with limited
resulting performances. There is also an emerging IEEE 802.11n standard that plans to provide multi
-
hop
communications at the link layer. There is however no satisfactory solution for the time being.

2.2

Blu
etooth (IEEE 802.15.1
)

Bluetooth is an industry standard for short
-
range radio in office and home environment
s
. The initial version
(V1.1) has served as a basic for IEEE 802.15.1. Bluetooth uses the 2.4GHz ISM license free band available
worldwide (althoug
h with some restriction in some countries). Bluetooth networks are composed of piconets.
Interconnected piconets in the same geographical area form a scatternet. A piconet has a single master and
up to 7 active slaves. Many more slaves may be

synchronised

with the piconet traffic but cannot participate
actively (park mode). Bluetooth operates in the 10 meter range with extensions to longer distances (similar
to 802.11). It uses a frequency hopping spread spectrum technique on 79 carrier frequencies. Each ho
pping
sequence lasts approximately 24 hours. The raw bit rate is 1Mbit/s (3 Mbit/s in the extended mode). Traffic
is master slave with the piconet master polling a single slave in one hop. The slave has to answer in the next
hop. This transaction is repeat
ed in case of error. The order in which slaves are polled is not defined by the
protocol but depends on the pending traffic. Besides this sporadic traffic, Bluetooth support
s

real
-
time
isochronous traffic. Each isochronous connection uses one third of the
available bandwidth and up to 3
isochronous connections can be established. A node can participate in more than a single piconet but
cannot be the master on both as the hopping sequence and its phase are defined by the master identity and
clock phase. Comm
unication between piconets (scatternet) is provided by nodes that participate in 2
piconets and forward the information from one piconet to the next one. This aspect is not

standardised
.

Bluetooth offers authentication and ciphering to protect the communic
ation.
It also includes a service
discovery protocol that allows to find a node with a given capability.
Higher layers are based on a serial link
emulation (RFComm) and the PPP/IP/TCP
-
UDP suite as well as the object exchange protocol OBEX.
Besides the isoc
hronous traffic which cannot be used between more that 3 devices, Bluetooth does not offer
temporal guarantees. The limitation in the number of devices can be overcome by regularly swapping nodes
from active to park mode and vice versa. The fact that traff
ic is master slave is certainly a problem for
distributed application. Bluetooth strength lies in its robustness and absence of preconfiguration as well as
the relatively low cost. The major drawbacks are the long connection time and the strong limitation
in terms
of multihop communications with the absence of a corresponding standard.

2.3

IEEE 802.15.4 and
ZigBee

As the other IEEE 802 standard, IEEE 802.15.4 defines the physical layer and the medium access control
sublayer. It operates in 3 bands, 2.4 GHz (16
channels), 915 MHz (30 channels in the US) and 868 MHz (3
channels in Europe). Extensions to other bands are planned in some countries. The standard defines
different modulation techniques and

signalling

rates as described in

Table
Error! No text of specified style
in document.
-
1
Error! Reference source not found.
.


Table
Error! No text of specified style in document.
-
1

802.15.4 signalling rates


IEEE 802.15.4 makes the distinction between full
-
function devices (FFD) and reduced
-
function devices
(RFD). FFDs may become coordinator. O
ne of the coordinators of a PAN (Personal Area Network) will
function as a PAN coordinator. This is typically the first coordinator that starts. RFDs may not communicate
directly. They need to use one FFD as a relay. The purpose of this distinction is to
have very simple devices
with very low power consumption being able to participate in a more complex wireless network.

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

5
/
56

At the MAC layer, IEEE 802.15.4 draws from IEEE 802.11. In the beacon
-
enabled operation, time is divided
into intervals of fixed duration
,

called

beacon intervals, that start with a beacon frame followed by a period
during which nodes may contend for access using a slotted version of CSMA/CA. At the end of this period,
there may be an optional contention
-
less period during which nodes are a
ssigned time slots by
configuration. The beacon interval ends with an inactive period during which nodes may sleep to save
energy. This is one of the different techniques used to keep power consumption of non
-
coordinator nodes as
low as possible. Indirect
communication is a second. A node may sleep at its will and wake from time to time
to look for possible incoming traffic. The beacon sent by a coordinator contains an indication of pending
traffic with a list of addressed nodes. When the sleeping node wake
s
-
up, it waits for a beacon and can check
if there is some pending traffic for him. If this is the case, it may request the data from the coordinator during
the contention period. It may then go back to sleep. This procedure implies that the coordinator bu
ffers the
pending traffic waiting for some poll from the destination node. Direct traffic is also possible from a node to a
coordinator or vice
-
versa. The standard does not explicitly preclude direct traffic from node to node but as
there is no provision f
or

neighbourhood

discovery at MAC level this would enter in conflict with the routing
protocols.

When all nodes have a direct visibility to the PAN coordinator, IEEE 802.15.4 offers a simple and efficient
solution. For more complex networks, when multihop
communication is necessary to read all nodes, IEEE
802.15.4 supports a tree
-
like topology. The root is the PAN coordinator to which a number of nodes in direct
visibility associate. One or more of the theses nodes may serve as coordinators to extend the sp
an of the
network. Nodes that does not see the PAN coordinator but see one of the coordinators will associate to this.
The same procedure may be repeated to create a tree
-
like network. Each coordinator will manage a beacon
interval. To avoid interferences,

all beacon intervals in a PAN should be identical and each coordinator is
given an offset from the beginning of the interval (see Figure below) that defines the time at which it has to
send its beacon.


Figure
Error! No text of specified s
tyle in document.
-
1

Relationship between incoming and outgoing
beacons

The calculation and the distribution of the offsets to the different coordinators are not defined in the
standard.
One may comment that this solution will not be able to support mobility in an effi
cient way because
all offsets would need to be recalculated when a coordinator moves. All associations would also be
changed. Note that routing from coordinator to coordinator is clearly not defined in the standard (this is
routing).

The second mode of op
eration is the beaconless mode. In this mode, coordinators are still present but their
role is limited to managing indirect traffic.
In direct traffic, nodes may send packets at any time using the
CSMA/CA protocol (non slotted).
When indirect traffic is us
ed to reach a node, that node may sleep most of
the time and wake
-
up from time to time to poll a coordinator for possible traffic. Note that beacons may still
be transmitted on request to discover the

neighbourhood
. This means that direct traffic is only p
ossible from
or to a coordinator. However, nothing precludes all nodes to become coordinators.
When power
consumption must be kept low, this must be discouraged because coordinators must be in the receiving
mode most of the time and this one of the most po
wer consuming tasks.
Note that hop by hop is only
possible using the coordinators and some routing protocol.

IEEE 802.15.4 also defines different levels of packet encryption. Key management is left to higher layers.

In summary, IEEE 802.15.4 is the only
standard that addresses low power wireless communications at the
time of writing. In the contact of IPAC, the tree
-
like topology, which is the most power
-
efficient option, cannot
be used because it does not scale and does not support mobility. The beacon
-
l
ess is power hungry and
does not support well mobility.

ZigBee is an industry standard that governs routing, service description and discovery as well as security
management. While we may reuse part of a ZigBee, its main component, the network (routing) pa
rt cannot
because one of the objectives of the project is to define new routing techniques more adapted to distributed
systems.

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

6
/
56

2.4

DECT

DECT (Digital Enhanced Cordless Telephone) is an ETSI (European Telecommunications Standards
Institute) that defines an in
-
door wireless extension to ISDN. It operates in a reserved band in more than 100
countries. DECT uses 10 frequency channels. On each channel, cycles of 10 ms duration are repeated.
Each cycle contains 24 time slots. A single connection uses 2 slots, one fo
r the uplink and one for the
downlink. Up to 120 connections may be established from a single base station. The information is sent at
1Mbit/s which means that each slot can accommodate 320 bits for a voice channel or 256 bits for a data
channel. For a dat
a connection, up to 23 slots can be used in one direction if asymmetric traffic is
necessary.

Multiple cells (multiple base stations) can coexist without configuration. The 120 channels need however to
be shared among the cells. Through the static assignm
ent of a channel, traffic can be guaranteed.
Furthermore, the use of a protected band makes DECT immune to other sources of perturbation.

Despite the official support of data communication in the standard, all implementations we know off do not
implement
it. It thus cannot be used in the project.

2.5

Wireless HART

WirelessHART is an industry initiative to develop a wireless solution for process control automation. It
complies with the IEEE 802.15.4 physical layer specification at 2.4 GHz (16 channels). Contrar
y to IEEE
802.15.4 and similar to Bluetooth, it uses slow frequency hopping to mitigate multipath fading and
interferences. A WirelessHART network contains a Network Gateway, a Network Manager, one of more
Access Point and end devices that include a router

function. The Gateway is the connection point to other
networks. The Manager is in charge of the network configuration. The Gateway and the Manager are usually
collocated. Mesh topologies are preferred but trees and stars are supported as special cases. F
or
dependability reasons, routes from the end devices to the Gateway are redundant thanks to the mesh
topology. Exchanges are

organised

in Superframes that repeat periodically. Each superframe is further
divided into slots. All slots have the same duration
, enough time to transmit a packet and get the
acknowledgement plus some margin for time

desynchronisation
. Slots of a superframe are transmitted on
different channels. To accommodate traffic with multiple periods, multiple superframes may coexist with the

only restriction that two slots of two different superframes must be temporally aligned. Based on the traffic
needs, the Network manager assigns (schedules) the exchanges into superframes and slots. When a
message needs to be routed, the Network Manager a
ssigns a slot for the relaying of the message to the
next hop. This slot is contiguous to the slot during the message is received. In general, a message produced
by an end device is transmitted through two different routes to the Gateway and the Network Ma
nager
assigns slots accordingly. A slot may be defined for a point
-
to
-
point transmission from a given device to
another one or for broadcast transmission. It may also be left open to contention. In such a case, CSMA/CA
with a backoff technique is employed.

Once ready, the schedule is loaded into all devices. Schedule
changes are possible during operations. This is usually done by loading a new superframe definition.

Wireless HART is an interesting solution in its market. Process control application operates

cyclically and
thus a pure fixed TDMA schedule is a good solution. As all nodes know the schedule, low
-
power operation is
possible. By construction, Wireless HART solves some of drawbacks of ZigBee, sensitivity to interferences
and multipath fading as wel
l as high power consumption.

2.6

Wireless Sensor Networks

IEEE 802.15.4 together with ZigBee and Wireless HART are the two standard proposals for wireless sensor
networks. Some IEEE groups are working on new proposals. There are however a number of other
propo
sals from the industry, Zwave (Ember, Zensys), Xmesh (Crossbow), SmartMesh (Dust Networks),
Millenialnet and the open source community (TinyOS). Most of the industrial systems do not come with any
technical description of the solution. It is thus impossibl
e to describe them here.

The developments available within or around TinyOS attract a lot of attention because the hardware is
relatively inexpensive and the software freely available. However, most sources report the inefficiency of the
solutions.

2.7

Wisenet

Wisenet is a wireless sensor network project developed at CSEM since 2002. The WiseNET system
includes an ultra low
-
power system
-
on
-
chip (SoC) hardware platform and WiseMAC, a low power medium
access control protocol (MAC) dedicated to duty
-
cycled radio.
Both elements have been designed to meet
the specific requirements of wireless sensor networks and are particularly well suited to ad
-
hoc and hybrid
July 31, 2008

Report

IPAC ICT
-
2008
-
224395

7
/
56

infrastructure networks. The WiseNET radio offers dual
-
band operation (434
-
MHz and 868
-
MHz) and runs
from a

single 1.5
-
V battery. It consumes only 2.5
-
mW in receive mode with a sensitivity smaller than −108
-
dBm at a BER of 10−3 and for a 100 kb/s data rate. In addition to this low
-
power radio, the WiseNET
system
-
on
-
chip (SoC) also includes all the functions req
uired for data acquisition, processing and storage of
the information provided by the sensor. Ultra
-
low power consumption with the WiseNET system is achieved
thanks to the combination of the low power consumption of the transceiver and the high energy effi
ciency of
the WiseMAC protocol.

The WiseNET solution consumes more than 250 times less power than comparable solutions based on the

IEEE 802.15.4 standard.

WiseMAC is a low power MAC protocol specially developed for WSN [4] in combination with the SoC. It
is a
single channel contention protocol based on non
-
persistent carrier sense multiple access

(CSMA)
.

Non
-
persistent CSMA has been com
b
ined with preamble sampling to mitigate idle listening. The preamble
sampling technique consists in regularly sampling th
e medium to check for activity. All nodes in a network
sample the medium with the same constant period. Their relative sampling schedule offsets are
independent. If the medium is found busy, a node continues to listen until a data packet is received or unt
il
the medium becomes idle again. At the transmitter, a wake
-
up preamble of size equal to the sampling period
is transmitted in front of every data packet to ensure that the receiver will be awake at the start of the data
portion of the transmission. This
technique enables very low power consumption when the traffic is very low
as it is usually the case in WSN. It provides the lowest possible power consumption in the absence of traffic
and for a given wakeup latency using a conventional receiver. The main d
isadvantage of this basic preamble
sampling protocol is that the low power consumption in idle mode is coupled with a high power consumption
overhead both in transmit and receive, due to the wake
-
up preamble. In an ad
-
hoc network, the cost of
reception is
not only paid by the intended destination, but also by all other nodes overhearing the
transmission. The novel scheme introduced by WiseMAC reduces the length of this costly wake
-
up
preamble. It consists in learning and exploiting the sampling schedule of
the direct neighboring nodes.


Figure
Error! No text of specified style in document.
-
2

WiseMAC preamble

To use a wake
-
up preamble of minimized size, as illustrated in
Figure
Error! No text of specified style in
document.
-
2
, the sampling schedule of a neighbor is learned,

or refreshed, during every data exchange by
piggybacking in the acknowledgement messages the remaining time until the next sampling instant. Every
node keeps a table of sampling time offsets of all its usual destinations up
-
to
-
date. Since a node will have

only a few direct destinations, such a table is manageable even with very limited memory resources. The
duration of the wake
-
up preamble must cover the potential clock drift between the clock at the source and at
the destination. This drift is proportiona
l to the time since the last re
-
synchronization (i.e. the last time an
acknowledgement was received). It can be shown that the required duration of the wake
-
up preamble is
given by TP = min(4θTC, TW), where θ is the frequency tolerance of the time
-
base qua
rtz, TW is the
sampling period and TC the interval between communications. A transmission is scheduled such that the
middle of the wake
-
up preamble coincides with the expected sampling time of the destination.

Systematic collision situations eventually int
roduced by this synchronization are mitigated using a wake
-

up
preamble of randomized size.

2.8

DSRC

DSRC

(Dedicated Short Range Communications)

is a new, short
-
to
-
medium
-
range wireless communication
protocol that is meant to complement cellular communications

in application domains where high data rates
and low latency are critical and where communication zones are relatively small. It has been specifically
July 31, 2008

Report

IPAC ICT
-
2008
-
224395

8
/
56

designed for automotive applications, namely automatic road toll collection, road safety and traffic
man
agement in the context of ITS (Intelligent
Transportation

Systems). DSRC supports Public Safety and
Private operations by
establishing

communication links between moving cars (vehicle
-
to
-
vehicle) or between
a car and the roadside (vehicle
-
to
-
infrastructure
), as shown in
Figure
Error! No text of specified style in
document.
-
3
.


Figure
Error! No text of specified style in document.
-
3

DSRC Component Architecture

DSRC involves both mobile and fixed units, establishing a highly
-
dynamic, adhoc, multi
-
hop network. Using
frequenc
y bands at 5.8 GHz (Europe) and 5.9 GHz (USA), the range can be up to 1000 meters, data rates
from 3 to 27 Mbps, latency smaller than 50ms. It supports car speeds up to 200 km/
h and

a relative car
speed up to 500km/h.

In order to specify high
-
speed communi
cations between vehicles and service providers, and to harmonize
communications interfaces between different automotive manufacturers, standards for DSRC are
developed, in the USA by IEEE, ASTM (American Society for Testing and Materials), ITS (
Intellige
nt

Transportation

Systems), in Europe by CEN (Comité Européen de Normalisation) and ETSI ISO. Different
standards apply for different geographic regions (USA, Europe,
and Japan
) but there is an effort for
harmonization.

The IEEE standards for DSRC are comp
osed of:



IEEE 802.11p: an amendment to IEEE 802.11, in order support wireless access for high speed
nodes, under development. Current applications in the USA use IEEE 802.11a.



the IEEE 1609 Family of Standards for Wireless Access in Vehicular Environments
(WAVE), under
development:

o

IEEE 1609
-
1: Resource Manager

o

IEEE 1609
-
2: Security

o

IEEE 1609
-
3: IP Network Services

o

IEEE 1609
-
4: Medium Access Control Extension Services

The CEN standards are the following:



EN 12253:2004 Dedicated Short
-
Range Communication
-

P
hysical layer using microwave at 5.8
GHz



EN 12795:2002 Dedicated Short
-
Range Communication (DSRC)
-

DSRC Data link layer: Medium
Access and Logical Link Control



EN 12834:2002 Dedicated Short
-
Range Communication
-

Application layer



EN 13372:2004 Dedicated S
hort
-
Range Communication (DSRC)
-

DSRC profiles for RTTT
applications

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

9
/
56



EN ISO 14906:2004 Electronic Fee Collection
-

Application Interface

DSRC defines two types of communication entities: on
-
board units (OBUs) and roadside units (RSUs). An
RSU is a fixed
WAVE device that supports communication and data exchange with OBUs, usually in a one
-
hop (often line
-
of
-
sight), centralized scheme. An OBU is a mobile, portable WAVE device that supports
information exchange with RSUs and other OBUs, in the latter case i
n a distributed
-
coordination, multi
-
hop
scheme. The flow of information is bi
-
directional: from the infrastructure to the vehicles as well as between
two vehicles.

The IEEE standards define seven channels, one for control and six for the services, as shown

in
Figure
Error! No text of specified style in document.
-
4
. By default, WAVE devices operate on the control
channel, which is reserved for short, high
-
priority application and system control messages. The RSU uses
the control channel in order to regularly send service adver
tisements (the available services and their
channel) to the OBUs within range, at a rate of 10 advertisements per second. In order to receive
information, an OBU monitors the control channel until a service advertisement is received that utilizes a
specifi
ed service channel.

In order to send information,
an OBU chooses to utilize a particular service
channel, based on the WAVE announcement frames it transmits over the control channel. At any case,
WAVE devices must monitor the control channel for additional

safety or private service advertisements
during specific intervals, even if this requires the suspension of a transaction in progress over a service
channel. This requires that WAVE devices that are not able to listen on the control channel and exchange
data on a service channel at the same time, be synchronized to each other and to an absolute time
reference, UTC, in order to know when to cease monitoring the control channel. UTC time is commonly
provided by GPS, but can also be obtained from other devic
es (the accuracy requirements allow to do so).


Figure
Error! No text of specified style in document.
-
4

DSRC channels

As depicted in
Figure
Error! No text of specified style in document.
-
5
, WAVE
accommodates

two
protocol families: standard IP and the WAVE Short Message P
rotocol (WSMP), designed for optimized
wireless operation in the vehicular environment. WAVE short messages can be exchanged on any channel,
while IP traffic is allowed only on a service channel. Applications have the choice to send their data in the
form
of WSMs on the control channel or to initiate/participate at a WBSS (Wave Base Service Set) on a
service channel and use either IP or WSMs. A WBSS supports traffic to/from specific applications and its
presence is
announced

for other devices with compatibl
e applications to join. Typically, a RSU or a OBU
(service provider) initiates a WBSS by sending a service advertisement on the control channel, after which
both the service provider and the service user (one or more OBUs) are free to generate data packets

for
transmission on the associated service channel, in a connectionless scheme (see
Figure
Error! No text of
specified style in document
.
-
6
). The WBSS can be persistent or of limited duration. It remains active until
it is locally terminated (local notification that there
is no more traffic), but there is no protocol exchange over
the air confirming its termination.

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

10
/
56


Figure
Error! No text of specified style in document.
-
5

The WAVE protocol stack (IEEE 1609)


Figure
Error! No text of specified style in document
.
-
6

R
SU Service Information Exchange Scheme

Data transmission can be unicast or broadcast. Service
announcements

are secured and the service user
checks the provider's d
igital signature before joining

a WBSS. The exchanged data are prioritized, according
to acc
ess category (8 priority levels).

3

Sensor management

Sensors

are devices that measure a physical attribute or a physical event. They output a functional reading
of that measurement as an electrical, optical or digital signal. That signals are data that can

be transformed
by other devices into information. The information can be used by either intelligent devices or monitoring
individuals to make intelligent decisions and maintain or change a course of action.

Smart sensors

are simply ones that handle their
own acquisition and conversion of data into a calibrated
result in the units of the physical attribute being measured. For example, a traditional thermocouple simply
provided an analog voltage output. The voltmeter was responsible for taking this voltage a
nd transforming it
into a meaningful temperature measurement through a set of fairly complex algorithms as well as an analog
to digital acquisition. A smart sensor would do all that internally and simply provide a temperature number as
data. Smart sensors
do not make judgments on the data collected unless that data goes out of range for the
sensor

Because of the diversity of the transducer market, manufacturers are always looking for ways to build low
-
cost, networked smart transducers. The Institute of Elec
trical and Electronics Engineers (IEEE) in
conjunction with the National Institute of Standards and Technology (NIST) addressed this issue by creating
a family of standards to aid in the design and development of smart networked transducers.

The ultimate
goal of the standards is to achieve transducers to network interchangeability and transducer to
networks interoperability. This is done by defining a set of common communication interfaces for connecting
transducers to microprocessors, i
nstruments and fiel
d networks.

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

11
/
56

This chapter concentrates on the approved IEEE 1451 standards, in which inter
-
chip communications are
eliminated yielding a speed improvement over the implemented solutions to date.

Finally an overview of
SensorML is given which provides a hig
h level description of sensors and their usage.

3.1

IEEE 1451 OVERVIEW

The standards were first proposed in September 1993, when NIST and the IEEE's Technical Committee on
Sensor Technology of the Instrumentation and Measurement Society co
-
sponsored a meeting
to discuss
smart sensor communication interfaces and the possibility of creating a standard interface. The response
was to establish a common communication interface for smart transducers. Since then, a series of
workshops has been held and seven technical

working groups have been formed to address different
aspects of the interface standard. Currently, all working groups under the IEEE 1451 umbrella provide
standard interfaces for sensors on tethered networks.

A wireless IEEE 1451 standard should provide
seamless connectivity among sensors and users, no matter
what distance separates them. And it must do this without requiring the installation of new wires and with
reasonable cost and size additions at each sensor node
. Figure 3.1 shows
the NIST
-
supported
IEEE 1451
standard based system.

The general requirements of any wireless network include throughput, range, reliability, and power
consumption. Some users need tens of megabits per second while others require only a few bits per day.
Also, the sizes of th
e networks vary from a few feet to several miles.

The Wireless Sensing Workshop in Chicago on 2001, tried to determine the interest and requirements for
wireless interfaces for sensor
-
based networks, especially in the industrial community. An informal surv
ey
showed that most industrial users needed 32 or fewer nodes per network and typically <300 bps per node,
or an aggregate data rate of <10 kbps for the network. At the same time, the industrial users generally
wanted network ranges of a few kilometres, no
t just tens of meters. While this sampling population was too
small to be statistically accurate, the results showed that at least one of the physical layer options must offer
long
-
range operation, but perhaps fewer throughputs would be acceptable. Worksho
p panellists also
discussed reliability. Some asserted that potential users of wireless sensors must sacrifice some reliability to
go wireless; others wanted a network protocol that optimized the reliability of the link.

One way or another, physical layer
s chosen for a wireless IEEE 1451 system must address
data
transmission reliability
.

Within this context, the concept of reliability has several possible definitions, depending on the application.
These include the probability that a message will get throu
gh; the probability that a message will get through
within a given amount of time; or the probability that errors in messages will be detected. Other reasons for
using IEEE 1451 are



There

are more than 3,000 global sensor manufacturers. Trying to use a v
ariety of sensors from a
number of different manufacturers together in a data acquisition system can be very complex and
require expensive customization by the integration team.



A

conventional sensor system has a lot of analog wiring and extensive switchi
ng. IEEE 1451
systems will greatly simplify development and installation of smart sensor systems.



IEEE 1451 compliant systems will cost significantly less to install than conventional sensor
systems.



Intechno Consulting forecasts the global sensor to gr
ow from $32.5 Billion a year in 1998 to $50.6
Billion a year in 2008. Some of the big players, such as Intel, are betting that this is “the next big
thing” to drive both information technology and corporate profits. Several factors make IEEE 1451
the righ
t standard at the right time to capitalize on this extremely high growth rate. Semiconductor
manufacturing techniques can make a wide variety of sensors far easier and cheaper to
manufacture in quantity. These techniques can also be applied to nano develo
pment and
manufacturing. Low
-
power and power scavenging sensors can be wirelessly deployed, reducing
the cost of installation. IEEE 1451 can enable networks of smart sensors to communicate and
even to set up ad hoc networks.

The following part of this cha
pter goes into detail about the different standards.

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

12
/
56


Figure
Error! No text of specified style in document.
-
7


IEEE 1451

Block diagram

IEEE 1451

is a planned set of standards for smart sensors that will make it easier and cheaper to deploy a
wide varie
ty of sensors.





IEEE 1451.0


This portion of the standard defines the structure of the TEDS (Transducer
Electronic Data Sheets) the interface between .1 and .X, message exchange protocols and the
command set for the transducers.



IEEE 1451.1


Specifies

collecting and distributing information over a conventional IP network.



IEEE 1451.2


Wired transducer interface


12 wire bus working on a revision which will put IEEE
1451 on RS
-

232, RS
-
485 and USB.



IEEE 1451.3
-

This is the information to make multi
-
drop IEEE 1451 sensors work within a network.



IEEE 1451.4


This portion of the standard specifies the requirements for TEDS (Transducer
Electronic Data Sheets). This is software only.



IEEE 1451.5


This section of the standard specifies information th
at will enable 1451 compliant
sensors and devices to communicate wirelessly, eliminating the monetary and time costs of
installing cables to acquisition points. The IEEE is currently working on three different standards,
802.11, Bluetooth and
ZigBee
.



IEEE

1451.6


This is the information required for the CAN (consolidated auto network) bus.

Currently,



IEEE 1451.1 and IEEE 1451.4 have become published standards.



IEEE 1451.3 has been approved and is awaiting publication.



IEEE 1451.2 is awaiting revisio
n.



IEEE 1451.4 has commercially available products, largely because National Instruments has
enthusiastically backed this standard and is encouraging its clients and alliance members to take
advantage of the synergies it provides


Different companies aro
und the world are very interested in the development of test and measurement. After
several years of research, it has been determined that one of the most promising areas of development for
test and measurement are smart sensors.

IEEE 1451 promises excel
lent communications, data reduction and intelligent data development. In short,
1451 promises to save money on deployment save money in operations and provide actionable intelligence
so that users are not buried in data but have the opportunity to make ef
ficient, effective and intelligent
decisions based on accurate and analyzed data.

3.2

SensorML overview

In essence SensorML is an XML dialect that is used to describe sensors, sensor capabilities and sensor
uses. In detail, SensorML
(SensorML core Specificatio
n)
provides standard models and an XML encoding
July 31, 2008

Report

IPAC ICT
-
2008
-
224395

13
/
56

for describing any process, including the process of measurement by sensors and instructions for deriving
higher
-
level information from observations. Processes described in SensorML are discoverable and
execu
table. All processes define their inputs, outputs, parameters, and method, as well as provide relevant
metadata. SensorML models detectors and sensors as processes that convert real phenomena to data.


In 1998, under the auspices of the international Commi
ttee for Earth Observing Satellites (CEOS), Dr. Mike
Botts at the Earth System Science Center at the University of Alabama in Huntsville began development of
an XML
-
based Sensor Model Language for describing certain properties of dynamic remote sensors. In

2000, SensorML was brought under the oversight of the Open Geospatial Consortium (OGC) where it
served as a catalyst for the OGC Sensor Web Enablement (SWE) initiative. The continued development of
SensorML has been supported by the Interoperability Progr
am of OGC, as well as the US Environmental
Protection Agency (EPA), the US National GeoSpatial
-
Intelligence Agency (NGA), the US Joint
Interoperability Test Command (JITC), the US Defense Information Systems Agency (DISA), SAIC, Crystal
Data International,

General Dynamics, Northrop Grumman, Oak Ridge National Labs, and NASA. SensorML
was approved by OGC as an international, open Technical Specification on June 23, 2007. The Open
Geospatial Consortium (OGC) is an international voluntary consensus standards
organization. In the OGC,
more than 330 commercial, governmental, non
-
profit and research organizations worldwide collaborate in an
open consensus process encouraging development and implementation of standards for geospatial content
and services, GIS data

processing and exchange. It was previously known as Open GIS Consortium. In
summary, SensorML is good for:



Electronic Specification Sheet (
for sensor components and systems).




Discovery of sensor, sensor systems, and processes.




Lineage of Observations.




On
-
demand processing of Observations.




Support for tasking, observation, and alert services.



Plug
-
N
-
Play, auto
-
configuring, and autonomous sensor networks.




Archiving of Sensor Parameters.


The essential elements
of SensorML
are:



Component
.

A p
hysical atom
ic process

that transforms information from one form to another. For
example, a Detector typically transforms a physical observable property or phenomenon to a digital
number. Example Components include detectors, actuators, and physical filters.



System
.

A c
omposite physically
-
based model of a group or array of components, which can
include detectors, actuators, or sub
-
systems. A System relates a process to the real world and
therefore provides additional definitions regarding relative positions of its com
ponents and
communication interfaces.



Process Model
.

An a
tomic non
-
physical processing block usually used within a more complex
Process Chain. It is associated to a Process Method which defines the process interface as well as
how to execute the model. It

also precisely defines its own inputs, outputs and parameters.



Process Chain
.

Composite non
-
physical processing block consisting of interconnected sub
-
processes, which can in turn be Process Models or Process Chains. A process chain also includes
possibl
e data sources as well as connections that explicitly link input and output signals of sub
-
processes together. It also precisely defines its own inputs, outputs and parameters.



Process Method
.

A d
efinition of the
behaviour

and interface of a Process Model
. It can be stored
in a library so that it can be reused by different Process Model instances. It essentially describes
the process interface and algorithm, and can point the user to existing implementations.



Detector
.

An a
tomic component of a composite M
easurement System defining sampling and
response characteristic of a simple detection device. A detector has only one input and one output,
both being scalar quantities. More complex
s
ensors such as a frame camera which are composed
of multiple detectors c
an be described as a detector group or array using a System or Sensor. In
SensorML a detector is a particular type of Process Model.



Sensor
.

A s
pecific type of System representing a complete Sensor. This could be
,

for example
,

a
complete airborne scanner
which includes several Detectors (one for each band).

SensorML could be utilised in IPAC for the description, advertisement and discovery of sensors embedded
in IPAC nodes. In fact SesnorML provides a powerful standard that can enable IPAC
nodes to utiliz
e
sensors found on different nodes. What is needed is the storage of sensor descriptions in SensorML and a
reasoning mechanism that utilizes this information. In this way, IPAC nodes can easily be aware of the
sensing capabilities of neighbouring nodes and

how these capabilities could be used. Also having an open
and well known standard for describing sensing capabilities, leads to the easier incorporation of new IPAC
nodes in the system. The node provider does not need to learn a new (possibl
y

proprietary)

standard in
order to enable hardware for use within the IPAC middleware. Even better if a hardware sensing node
already has been described in
SensorML the step of sensor description in order to incorporate this device
into IPAC can be skipped.

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

14
/
56

4

Data modell
ing technologies based on the XML standard

The purpose of data modelling is to develop an accurate model, or graphical representation, of the client's
information needs and business processes. In general there are three main types of data models: the
conce
ptual schema which describes the semantics of a domain, the logical schema which describes the
semantics represented by a particular data manipulation technology and the physical schema which
describes the physical storage of the data.

Moreover there are
many available technologies for data modelling with each one having specific
advantages over given types of applications. For example, for relational database design Entity
-
Relational
models (logical) along with Relational models (physical) are the dominat
ing technologies. This is so because
those models are very good at describing data that are structured and (more or less) complete. However,
when dealing with semi
-
structured or incomplete data (data instances do not always contain all the
information) the
se models do not cope as well. Currently the dominating technology for dealing with semi
-
structured data is XML (Extensible Markup Language). In fact, one of the driving forces behind the creation
of XML was to cover this specific weakness (modelling and s
toring self
-
describing, semi
-
structured data)
that became obvious with the ever increasing use of the web for displaying/exporting data. Additionally the
usage of text format (instead of binary) for XML files promoted the interoperability between heterogen
eous
systems. This is especially true for applications running on mobile and limited (regarding memory and
processing) devices.

Data exchanged within and utilized by the IPAC middlew
are

will be semi
-
structured, sometimes incomplete,
should be self
-
describi
ng and need to be supported by heterogeneous and mobile devices. Thus XML
seems to be ideal for storing and processing data in IPAC. Since XML can also be used for modelling data it
is natural to adopt it for all the data related requirements (modelling be
ing one of them) of the IPAC
middleware.

The Extensible Markup Language (XML) is a W3C (World Wide Web Consortium)
-
recommended general
-
purpose markup language for creating special
-
purpose markup languages, capable of describing many
different kinds of dat
a. In other words: XML is a way of describing data and an XML file can contain the data
too, as in a database. It is a simplified subset of Standard Generalized Markup Language (SGML). Its
primary purpose is to facilitate the sharing of data across differe
nt systems, particularly systems connected
via the Internet
(Bray T. et al., 2006
)
)
.

There are two levels of correctness of an XML document:



Well
-
formed
. A well
-
formed document conforms to all of XML's syntax rules. For example, if a
start
-
tag appears with
out a corresponding end
-
tag, it is not
well
-
formed
. A document that is not
well
-
formed is not considered to be XML; a
conforming parser

is not allowed to process it.



Valid
. A valid document additionally conforms to some semantic rules. These rules are eith
er user
-
defined, or included as an XML schema

(
W3C XML Schema
)

or DTD. For example, if a document
contains an undefined element, then it is not
valid
; a
validating parser

is not allowed to process it.

4.1

Features of XML

XML provides a text
-
based means to desc
ribe and apply a tree
-
based structure to information. At its base
level, all information manifests as text, interspersed with markup that indicates the information's separation
into a hierarchy of character data, container
-
like elements, and attributes of
those elements. In this respect,
it is similar to the LISP programming language's S
-
expressions, which describe tree structures wherein each
node may have its own property list.

The fundamental unit in XML is the character, as defined by the Universal Char
acter Set. Characters are
combined in certain allowable combinations to form an XML document. The document consists of one or
more entities, each of which is typically some portion of the document's characters, encoded as a series of
bits and stored in a t
ext file.

The ubiquity of text file authoring software (word processors) facilitates rapid XML document authoring and
maintenance, whereas prior to the advent of XML, there were very few data description languages that were
general
-
purpose, Internet protoc
ol
-
friendly, and very easy to learn and author. In fact, most data interchange
formats were proprietary, special
-
purpose "binary" formats (based foremost on bit sequences rather than
characters) that could not be easily shared by different software applica
tions or across different computing
platforms, much less authored and maintained in common text editors.

By leaving the names, allowable hierarchy, and meanings of the elements and attributes open and definable
by a customizable schema, XML provides a synt
actic foundation for the creation of custom, XML
-
based
markup languages. The general syntax of such languages is rigid


documents must adhere to the general
rules of XML, assuring that all XML
-
aware software can at least read (parse) and understand the re
lative
arrangement of information within them. The schema merely supplements the syntax rules with a set of
constraints. Schemas typically restrict element and attribute names and their allowable containment
July 31, 2008

Report

IPAC ICT
-
2008
-
224395

15
/
56

hierarchies, such as only allowing an element na
med 'birthday' to contain 1 element named 'month' and 1
element named 'day', each of which has to contain only character data. The constraints in a schema may
also include data type assignments that affect how information is processed; for example, the 'mo
nth'
element's character data may be defined as being a month according to a particular schema language's
conventions, perhaps meaning that it must not only be formatted a certain way, but also must not be
processed as if it were some other type of data.

I
n this way, XML contrasts with HTML, which has an inflexible, single
-
purpose vocabulary of elements and
attributes that, in general, cannot be repurposed. With XML, it is much easier to write software that accesses
the document's information, since the dat
a structures are expressed in a formal, relatively simple way.

XML makes no prohibitions on how it is used. Although XML is fundamentally text
-
based, software quickly
emerged to abstract it into other, richer formats, largely through the use of datatype
-
or
iented schemas and
object
-
oriented programming paradigms (in which the document is manipulated as an object). Such software
might treat XML as serialized text only when it needs to transmit data over a network, and some software
doesn't even do that much.
Such uses have led to “binary XML”, the relaxed restrictions of XML 1.1, and
other proposals that run counter to XML's original spirit and thus garner an amount of criticism.

4.2

Strengths of XML

Some features of XML that make it well
-
suited for data transfer
are:



Its simultaneously human
-

and machine
-
readable format;



It has support for Unicode, allowing almost any information in any human language to be
communicated;



The ability to represent the most general computer science data structures: records, lists a
nd trees;



The self
-
documenting format that describes structure and field names as well as specific values;



The strict syntax and parsing requirements that allows the necessary parsing algorithms to remain
simple, efficient, and consistent.


XML is also
heavily used as a format for document storage and processing, both online and offline, and
offers several benefits:



Its robust, logically
-
verifiable format is based on international standards;



The hierarchical structure is suitable for most (but not all)
types of documents;



It manifests as plain text files, unencumbered by licenses or restrictions;



It is platform
-
independent, thus relatively immune to changes in technology;



It and its predecessor, SGML, have been in use since 1986, so there is extensive

experience and
software available.

These strengths can be easily incorporated and exploited in IPAC. For example XML files could be used to
store and transport information between IPAC nodes or by the middleware itself in order to describe the
nodes and t
heir needs.
Of course the heterogeneous interoperability that is required between IPAC nodes
(and their data exchanges)
can be supported
by
XML
as just having the ability to handle Unicode text is
sufficient for XML to be used for data exchange and storage
.
Furthermore the self explanatory nature of
XML files is an added bonus for IPAC as it is expected that data produced and exchanged between nodes
will not have a fixed form known beforehand, rather than
conform to certain rules. Thus it becomes crucial to

have a way to provide this kind of functionality. Finally, having an easy to use standard that does not
demand the acquisition of extra licences makes the development of IPAC easier (in contrast of using a more
restricted standard). Additionally, the adop
tion and usage of it by third parties also becomes easier (XML is
well known)
.

4.3

Weaknesses of XML

For certain applications, XML also has the following weaknesses:



Its syntax is fairly verbose and partially redundant. This can hurt human readability and appl
ication
efficiency, and yields higher storage costs. It can also make XML difficult to apply in cases where
bandwidth is limited, though compression can reduce the problem in some cases. This is
particularly true for multimedia applications running on cell

phones and PDAs which want to use
XML to describe images and video.



Parsers should be designed to recurse arbitrarily nested data structures and must perform
additional checks to detect improperly formatted or differently ordered syntax or data (this is
because the markup is descriptive and partially redundant, as noted above). This causes a
significant overhead for most basic uses of XML, particularly where resources may be scarce
-

for
example in embedded systems. Furthermore, additional security consid
erations arise when XML
input is fed from untrustworthy sources, and resource exhaustion or stack overflows are possible.

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

16
/
56



Some consider the syntax to contain a number of obscure, unnecessary features born of its legacy
of SGML compatibility. However, an e
ffort to settle on a subset called "Minimal XML" led to the
discovery that there was no consensus on which features were in fact obscure or unnecessary.



The basic parsing requirements do not support a very wide array of data types, so interpretation
somet
imes involves additional work in order to process the desired data from a document. For
example, there is no provision in XML for mandating that “3.14159” is a floating
-
point number rather
than a seven
-
character string. Some XML schema languages add this f
unctionality.



Uses the hierarchical model for representation, which is limited compared to the relational model,
since it only gives a fixed view of the actual information. For example either actors under movies, or
movies under actors.



Modelling overlap
ping (non
-
hierarchical) data structures requires extra effort.



Mapping XML to the relational or object oriented paradigms is often cumbersome.



Some have argued that XML can be used for data storage only if the file is of low volume, but this
is only true

given particular assumptions about architecture, data, implementation, and other
issues.

The weakness could impact IPAC as well. However there are solutions that can be used in order to avoid
theses problems. For example keeping the exchanged data between

nodes in low volumes nullifies most of
the XML associated problems (extreme recursion and redundancy). Even
when having
high volume files,
there
efficient

solutions
,

such as compressi
o
n and offline processing. Furthermore by carefully deciding
when to, an
d when not to, use XML in the various part of IPAC we could also avoid many problematic
situations.

4.4

Data modelling with XML

Data models can be described through an XML Schema (called XSD). XSDs are far more powerful than
DTDs in describing XML languages. T
hey use a rich datatyping system, allow for more detailed constraints
on an XML document's logical structure, and must be processed in a more robust validation framework. An
XSD is itself an XML document but its’ purpose is to provide the grammar used in X
ML documents. Another
difference from plain XML documents is that, in XSDs, there is a set of predetermined tags which is used to
describe the grammar of an XML document. XSD and XML documents are much like database tables which
have a fixed schema provide
d by a model (e.g. ER models) and rows which contain the actual data. The
main difference with databases is that XML Schemas are not so rigid, in the sense that they don’t define the
exact attributes (elements) of the stored data, rather than specifying wh
ich attributes
may

exist in an XML
document. It is possible to infer some restrictions (such as an element may exist only within another element
or the cardinality of those elements) but in general they don’t provide a strict and rigid structure. That is,
a
structure is provided but it describes what data
could

be within an XML document instead of specifying the
exact elements that
should

be in a document.

Having an XML schema allows
for

us
ing

software tools that validate, produce, parse and even query XML
documents using SQL like languages (e.g. XQuery, XPath, etc). Finally, even though an XSD is in essence
a text document which may be produced with any text editor, there are many specialized software tools for
authoring XSDs. These tools provide a graphica
l environment to author and represent an XML schema thus
making the development of XSDs much easier. The standard symbol notations that are used in XML
Schemas are the following:

Element symbols

An XML
-
element is the basic block of any XML document. It is
a piece of text bounded by matching tags.
Inside the tags there may be a combination of text and other elements (see
Figure
Error! No text of
specified style in document.
-
8
). The tags are user
-
defined. And they must be balanced. Furthermore, it is
possible to abbreviate empt
y XML e.g. <married></married> can be abbreviated to <married/>.

July 31, 2008

Report

IPAC ICT
-
2008
-
224395

17
/
56


<
UserInfo
>


<
ID
>
ID_1
</
ID
>


<
FirstName
>
Chris
</
FirstName
>


<
LastName
>
Panayiotou
</
LastName
>


<
Address
AddressIdentifier
="
Home Address
">



<
Street
>
Street Name 10
</
Street
>



<
City
>
Nicosia
</
City
>



<
Area
>
Pallouriotissa
</
Area
>



<
Country
>
Cyprus
</
Country
>


</
Addre
ss
>

</
UserInfo
>


Figure
Error! No text of specified style in document.
-
8

Example of an XML element

The cardinality of the element (0..1, 1 exactly, 0..n, 1..n) is indicated by the border of the elements.

Optional
elements are drawn with a dashed line, required elements with a solid line. A maximum occurrence greater
one is indicated by a two stacked boxes.


Content symbols

The content model of elements is symbolized on the left and right side of the elem
ent boxes. The left side
indicates whether the element contains a simple type (text, numbers, dates, etc.) or a complex type (further
elements). The right side of the element symbol indicates whether it contains child elements or not:

simple content
complex content
complex content
with child elements
no element content(simple type,attributes
only, or empty element )

Model symbols



A sequence of elements. The elements must appear exactly in the sequence in which they appear
in the schema diagram.



A choice of elements. Only a single element from those in the choice may appear at this position.



The "all" model, in wh
ich the sequence of elements is not fixed.

A sequence of elements
A choice of elements
The "all" model

5

Service Creation Environments

Integrated Development Environments (IDEs) are software applications that provide facilities to developers
for software creation. In the usual cases, an IDE ca
n contain a code editor, a compiler, build automation
tools, and a debugger. In some cases, where there is the need of benchmarking, an emulator could be used.
In IPAC there is the need of an environment where applications and services will be created and
tested off
-
July 31, 2008

Report

IPAC ICT
-
2008
-
224395

18
/
56

line before their deployment and execution in IPAC nodes (the so
-
called Application Creation Component).
Hence, in this section of the deliverable, we review the most important IDEs and common Service Creation
Environments (SCEs) and describe th
eir features. Through this, we will be able to recognize which of them
are the most appropriate for our purposes.

5.1

Development platforms, GUI frameworks and technologies for SCEs

An advanced Service Creation Environment (SCE) requires high level languages a
nd tools for the design
and development of the service logic, and powerful code generators for translating the design into the
corresponding implementation code. It should provide to the service developer with models that correspond
to components of the se
rvice architecture that may be reused in the creation of various services. It is also
important to provide capabilities for service code deployment in the target environment. In the following
section we survey existing technologies and platforms for develo
ping such environments.

5.1.1

Development Platforms for SCEs

The platforms described in this section are the most commonly used development environments for SCEs.

Eclipse Platform

The Eclipse Platform (Rivieres & Wiegand, 2004; Eclipse Platform, 2006) is an ope
n
-
source IDE (Integrated
Development Environment), which contains the functionality required to build customized IDEs supporting
various programming languages. It is itself a composition of components. By using a subset of these
components, it is possible
to build arbitrary tools and applications. Although it has a lot of built
-
in
functionality, most of that functionality is very generic. Eclipse Platform is built on a mechanism for
discovering, integrating, and running modules called plug
-
ins.
Figure
Error! No text of specified style in
document.
-
9

A snapshot of the main Eclipse workbench window with only the standard generic
components
shows a screen capture of the main workbench window.


Figure
Error! No text of specified style in document.
-
9

A snapshot of the main Eclipse workbench
window with only the standard generic components

There are two components in

the Eclipse architecture


a small runtime kernel (i.e., Platform Runtime) and a
set of plug
-
ins. Plug
-
ins represent the smallest unit of functionality within Eclipse Platform and the runtime
kernel is responsible for the plug
-
in lifecycle management. Apa
rt from the microkernel, everything else in
Eclipse is a plug
-
in (including the GUI, the tools, etc.). The Eclipse runtime is a small, OSGi microkernel.
The OSGi Service Platform (OSGi Alliance, 2004; Delap, 2006) presents a standardised environment
respon
sible only for plug
-
in management. The Eclipse Platform UI is built around a workbench that supplies
the structures in which tools interact with the user and presents an extensible UI. It is based on editors,
views, and perspectives. When active, an editor

can contribute actions to the workbench menus and tool
bar.

Furthermore, the Graphical Editing Framework (GEF) (GEF, 2008) allows developers to create a rich
graphical editor from an existing application model. GEF employs an MVC (model
-
view
-
controller)
architecture which enables simple changes to be applied to the model from the view. It is an application
July 31, 2008

Report

IPAC ICT
-
2008
-
224395

19
/
56

completely neutral and provides the groundwork to build almost any application, including but not limited to:
activity diagrams, GUI builders, class di
agram editors, state machines, and even WYSIWYG text editors.
The basic components of the GEF framework are:



EditParts
: An EditPart contains all information concerning an editable element of the visual
interface. It is also responsible for controlling chan
ges to the element and to notify other elements
about status changes.



Model
: The model is composed from a number of classes which are responsible for maintaining the
actual status of the edited elements.



Figures
: Figures are the visual representations of

elements which are described in the model.



Policies
: Policies are responsible for mapping user requests to actions on the model.

NetBeans

The NetBeans (NetBeans IDE, 2008) is a free open
-
source IDE for software developers. It provides all the
tools the u
ser needs to create professional desktop, enterprise, web, and mobile applications with the Java,
C/C++, and Ruby languages. The
NetBeans

Platform contains APIs that simplify the handling of windows,
actions, files, and many other things typical in applica
tions. Each distinct feature in a NetBeans Platform
application can be provided by a distinct NetBeans module, which is comparable to an Eclipse plug
-
in.

Some of the basic components of the IDE are the following: a) the Editor, b) the Swing GUI Builder, c
) the
Component Inspector, and, d) the Debugger.

Furthermore, the NetBeans IDE supports the coding, testing and deployment of applications for mobile
devices that support the Java ME, CLDC/MIDP and CDC technologies.

Additionally, NetBeans provides some AP
Is for developing or extending an editor. The NetBeans APIs are
the public interfaces and classes which are available to module writers. Some of them are described in the
following list:



File Type Integration
: It allows the IDE, or any other application bu
ilt on the NetBeans Platform, to
recognize a new file type.



Code Snippet Module
: Used for the creation and addition of code snippets to component palettes.
Code snippets are small pieces of code that can be dragged from a component palette and
dropped in t
he Source Editor. They serve to speed up coding.



Editor Component Palette Module
: Used for the creation of a component palette that provides drag
-
and
-
drop code snippets for a new file type. Hence, the user can create a component palette for a
different fi
le type
-

one that is not recognized by the IDE by default.



Visual Library API
: It is a visualization API, useful in the context of, for example, modelling and
graphs.



XML Editor Extension Module
: Used for the creation of a module that extends the function
ality
offered by one of the IDE's editors. The IDE has several built
-
in editors: XML editor, Java editor,
JSP editor, and SQL editor.

IntelliJ IDEA


IntelliJ IDEA (JetBRAINS, 2008) is a commercial Java IDE proposed by the company JetBrains. It provides
a v
ery user friendly interface and enhances development productivity. Among other features, IntelliJ IDEA
provides close integration with popular open source development tools. It provides the OpenAPI along with
documentation and examples to enable developers

to create their own plug
-
ins.

Platform Comparison

Although
NetBeans

is a potential candidate for the development of services in the framework of IPAC, not
much support is provided for the plug
-
in development. The same holds for the IntelliJ IDEA IDE. In p
ractice,
it is really difficult to create plug
-
ins and even tougher to create special development tasks on these plug
-
ins.

Eclipse is a good IDE candidate for IPAC because it provides an open source platform for creating, at the
easiest possible way, an e
xtensible integrated development environment by allowing anyone to build tools
that integrate seamlessly with the environment and other tools. This seamless integration of tools is done
through the plug
-
ins. With the exception of a small run
-
time kernel, e
verything in Eclipse is a plug
-
in. This
IDE provides all the necessary capabilities for the IPAC project and seems to be the most promising
solution.

5.1.2

Emulators

Emulators help developers to test applications prior to deploying them in the actual devices. Us
ually, these
are distributed as parts of a larger development platform. The aim of an emulator is to mimic the
behaviour

of a specific device. Most of the famous mobile device vendors provide emulators for their products. The use
of an emulation phase in I
PAC is required for providing the desired service reliability and efficiency. The
reason is that after the services creation, the emulation phase will reveal its behaviour in the specified
device before it will be available to every IPAC node. Hence, devel
opers will be able to detect anomalies in
July 31, 2008

Report

IPAC ICT
-
2008
-
224395

20
/
56

service’s execution for the specific devices. In this section, we survey some works and technologies relevant
to emulators.
Some of these

are expected to be

integrated with the IPAC Application Creation Component.

Unified Emulator Interface

(UEI)


UEI (UEI, 2008) is a standard for interaction between IDEs and device emulators (it targets the Java
language). This specification ensures that an IDE developer can efficiently use emulators provided by the
third parties.
Actually, UEI describes the requirements that an emulator must meet in order to cooperate with
a development tool (e.g., which device metadata must be provided to the IDE).

The UEI specification defines a number of commands for emulator handling. An emula