Design
From the analysis of the solutions adopted for the different network technologies, a common pattern is emerged as far as the architecture layering is concerned for the sensor networks integration. With few differences the architecture is typically organized upon three layers, as depicted in Figure 1: namely the Access, Abstraction and Integration layers. 
The Access Layer is usually composed of a number of technology drivers, sometime already integrated in the operating system with well defined API (e.g. Bluetooth), sometime written from scratch or with ad hoc solution if standardized API are not available (e.g ZigBee, KNX).
There are two approaches generally followed to use the drivers API. In case of vertical solutions, where the interest is mainly related to the integration of few specific devices (e.g. a medical devices monitoring some physiological parameter), a controller is written that interacts directly with the specific remote devices through the drivers, and sometime provides a user interface to configure the device. We can always talk about a three-layered model, but with different meaning from that one reported by the figure, and more similar to a Model-View-Controller pattern. In the case of more general approach, the Driver API are used to provide an object-oriented style of interaction, by creating proxies, written in some programming language of the remote devices. The developer is not more bored to know the Driver API, or to know the data format of the packet, this information is hidden and encapsulated within the proxies. The creation of proxies can be automatized whether the technology supports a discovery mechanism, and notification of new devices joining/leaving the sub-network is provided. This is the case of modern technology like UPnP, DPWS (for more info: http://en.wikipedia.org/wiki/Devices_Profile_for_Web_Services), Zigbee which are based on plug and play concepts. Other technologies like Konnex or X10 are based on configuration tools used for (certifying) the installation. Thus, the access to a configuration file or DB, created by the technician, is needed to retrieve the real displacement of the devices. In any case the proxies are simple reproduction of the remote devices with few additional properties derived by the specific configuration they assume during the installation. Semantic annotation of such proxies is often realized manually with the user intervention. Information like the name of room where the switch is installed must be provided by the user.
The Abstraction layer of the figure is associated to this kind of semantic abstraction. In general this layer transforms the proxies, which are a flat and raw representation of the physical networked nodes installed in the environment, to more significant device objects, with an easier and intuitive interface for the developers. Thus the layer is another set of proxies that refine those proxies instantiated by the Access Layer. This layer can be quite complex with different kind of transformations obtained by combining the original information in several way: aggregating, splitting, filtering. Here some examples:
- A number of sensor nodes may be used to aggregate and derive information from the environment. For instance the set of radio sensors, which use the radio signal strength (RSS) to estimate the position of radio tag, represent an infrastructure that is used only to calculate the position estimation and it is hidden to the upper layers by exposing only a sensor representing the user’s position.
- A set of sensors may be integrated into a physical node in order to reduce production costs. However the sensors on the same board (same network address) may offer very different functionalities. So they can be represented as distinct sensor devices in the abstraction layer.
- A virtual sensor can represent the average value of a measured physical entity (i.e. temperature) computed with several sensors dislocated in the environment.
- Hybrid system composed of different technologies can calculate their information by merging the information coming from different kind of sensor (e.g. user position estimated by using radio sensor combined with infrared camera)
- Unified model can be used to represent sensors, which belong to different subsystems or technologies, but offer the same services or functionalities (e.g Konnex or ZigBee light devices represented as generic light devices )
KNX is a standardized (EN 50090, ISO/IEC 14543), OSI-based network communications protocol for intelligent buildings. The KNX standard is administered by the KNX Association, which, as of May 2012, had over 270 members/manufacturers from 33 countries (the complete list can be found at knx.org).
One of the strengths of the KNX system, is that any product labeled with the KNX trademark is based on conformity testing carried out by KNX accredited test labs. This results in devices of different manufacturers and different applications that can be combined to a working installation.
The KNX Association member companies have almost 7000 KNX certified product groups in their catalogues. This wide range of products allow, for example, the integration of: Lighting control, Heating/ventilation & Air Conditioning control, Shutter/Blind & shading control, Alarm monitoring, Energy management & Electricity/Gas/Water metering and Audio & video distribution.
KNX defines several physical communication medias: Twisted pair wiring, Powerline networking, Radio, Infrared and Ethernet. It is designed to be independent of any particular hardware platform. A KNX Device Network can be controlled by anything from an 8-bit microcontroller to a PC, according to the needs of a particular implementation.
Due to this facts and the high market penetration of KNX the LDDI group will develop a structured and adaptable framework to integrate KNX installations in universAAL.
ZigBee is a specification for small, low-power digital radios based on an IEEE 802 standard for personal area networks. Applications include wireless light switches, electrical meters with in-home-displays, and other consumer and industrial equipment that requires short-range wireless transfer of data at relatively low rates. The technology defined by the ZigBee specification is intended to be simpler and less expensive than other WPANs (wireless personal area networks), such as Bluetooth. ZigBee is targeted at radio-frequency (RF) applications that require a low data rate, long battery life, and secure networking.
The ZigBee Alliance is a group of companies that maintain and publish the ZigBee standard.http://www.zigbee.org/About/AboutAlliance/TheAlliance.aspx The term ZigBee is a registered trademark of this group, not a single technical standard. The Alliance publishes application profiles that allow multiple OEM vendors to create interoperable products.
The main components for integration of ZigBee standard in universAAL are provided by the ZB4OSGi project. The integration of the ZigBee protocol with the OSGi platform is of general interest for many application domains and its development will be separated from the specific artifacts adapted for the universAAL projects. The LDDI SVN repository is linked with the ZB4OSGi repository so that development, building and testing of ZB4OSGi components can be easily shared with universAAL specific roadmap.
The aim of this wiki section is to make available a technical guide to enable universAAL developers community in general and LDDI experts group in particular to start developing Ambient Assisted Living (AAL) services thanks to the wireless and low-cost Bluetooth technology through the Continua Health Alliance http://www.continuaalliance.org/ certified devices (also called agents or sources) in the healthcare domain. The Continua Health Alliance is a non-profit, open industry organization of technological companies joining together in collaboration to improve the quality of personal healthcare and provide the opportunity to develop personalized health and wellness management applications. There are more than 220 member companieshttp://www.continuaalliance.org/?q=node/250 and 50 compliant devices from different manufacturers and categories http://www.continuaalliance.org/products/product-showcase nowadays. On the other hand, the Continua Health Alliance relies on the ISO/IEEE 11073 Personal Health Data standard for addressing the interoperability of its manufactured Personal Health Devices (PHDs). The x073 generic data types, architectures, state machines, messages and communication models are described in the ISO/IEEE 11073-20601 (Optimized exchange protocol) framework and the data model for each PHD in the appropriate device specialization document (ISO/IEEE 11073-104xx).
In the universAAL Project it is planned to integrate at least two Continua-certified devices namely a Weighing Scale and a Blood Pressure Monitor. Both from A&D Medical and both transmitting over Bluetooth Health Device Profile (HDP). Furthermore, the Continua-proposed standard for in-home sensors measuring user activity, so called Independent Living Activity Hub (ISO 11073-10471) is adopted for sensor integration in universAAL.
FS20 is a simple wireless protocol developed by the german company ELV http://www.elv.de for the low-cost market segment of home appliances. It's main advantage is the cheap price of hardware devices. Though the protocol is not that robust than comparable protocols in this domain (e.g. KNX or ZigBee).
The protocol is based on the exchange of simple events/commands between event-receiver and event-sender (more technical info: http://fhz4linux.info/tiki-index.php?page=FS20%20Protocol).
In the universAAL project the integration of FS20 is done based on existing software/driver components from the Soprano project.