Design
The tasks that this group handles can be classified in the following categories:
- Enumeration of the sensors/actuator technologies used in uSpace domain: We should consider which technologies and/or devices are integrated by existing solutions with respect to the sensor and actuator that are actually installed in uSpace. In particular, we should at least take into account the technologies used by the following domain: domotic system, eHealth, entertainment, and Smart Energy.
- Integration model for data access and control of sensor nodes: It is important to identify the way the existing solutions allow the access to device, which may impact on the deployment of a real environment and the usability for external components that try to access to the such an abstraction layer. Many access models and protocols can be considered: restful, web services, RPC, adapters, gateways and surrogates.
- Data format and representation of information: We should encourage the usage of portable data format (i.e.: Ontology) when describing the devices and we must pay attention on the data representation provided by candidate solutions which may require effort to be translated to other formats. High level context information is usually associated and managed by the upper level of a context-aware architecture, but sometime it is useful to bind and save such information at low level, inside the sensor node (e.g. the node is portable and may traverse different uSpaces).
-
Common issues on integration of sensor subsystem: The integration provided by LDDI should cope with common problems such as
- Discovery of devices: for instance by automatic discovery vs manual installation of each device. This might depend on the technology being abstracted. But in any case it should be aware of the device status (device management: e.g. autom. reconnection)
- Configuration of devices: depending on the device it may require a configuration for optimizing battery-life, avoiding network overloading, and other aspects which the LDDI should provide
- Update/upgrade of the subsystem: in case of a sensor which the user bought out-of-the-shelf when he installs in a uSpace, how does LDDI react to the new device? The LDDI should allow hot changes either in terms of changes to the configuration and the devices which is integrating
- Security aspects: data captured by the networked sensors may represent personal information (i.e.: health values) , the same security level defined by the sensor networks should be offered when networks are integrated together. The group should cooperate with Security Expert Group to highlight possible problems and solutions.
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.
LDDI uses the SAIL three-tier architecture. There are clear interfaces between access, abstraction and integration layer. The OSGi Device Access Specification (OSGi DAS) is used to manage the coupling of OSGi services between the three layers. Existing software projects are used (Apache Felix DeviceAccess) which implement the matchmaking process for devices and drivers registered on the OSGi registry. This is a standardized API within the OSGi framework which give developers clear guidelines to develop additional device drivers for the universAAL platform. Furthermore, OSGi DAS enforces components to be exchangeable (e.g. usage of different drivers for devices). This approach follows also the project reviewers recommendation to have standardized APIs.
The matchmaking between an OSGi device service (representing one KNX group address, and registered in the OSGi registry) and the OSGi KNX device driver provided by other bundles, is done by Apache Felix DeviceManager which is currently available as 0.9.0 Snapshot version here. There is a dependency to an additional bundle, namely Apache Felix DependencyManager which is available here.
To make the device-driver matchmaking work for LDDI-KNX artifacts, both of these bundles must be activated in your OSGi framework at runtime!
The universAAL KNX integration design provides a common standardized abstraction model for sensor hardware (ISO 11073-10471) to enforce interoperability. Integration of personal health devices follow specifications of the same Standards family (ISO 11073), as proposed by the Continua Healthcare Alliance. (full name of the standard: CEN ISO/IEEE 11073 Health informatics - Medical / health device communication standards -- Part 10471: Device specialization: Independent living activity hub)
KNX components are not aware of the ISO 11073 standard. No KNX components exist that implement an so called ISO Agent. universAAL KNX integration design tries to integrate non-ISO11073-aware sensor technologies. Besides KNX there are other sensor technologies that can be integrated on the universAAL node using the same data model.
The current design does not foresee fully Agent-Manager communication from the base standard ISO 11073-20601, because this would be a massive overhead with little benefit for HA component integration. But, by following this design, it will be easier to integrate future products which cover this standard (available products are listed on the Continua homepage http://www.continuaalliance.org/products/product-showcase). Only the nomenclature (domain model and notation) is implemented yet, which is an essential component in the abstraction layer to enable interoperability between different HA technologies.
ISO 11073 Domain Information Model consists of definitions for:
- Sensortypes
- Event/Messagetypes
- Locations
There is also an alternative for developers who don't want to use another abstraction model but want to integrate their devices straight into the universAAL platform. The Access Layer component can be directly coupled to the Integration Layer component because both coupling borders (Access/Abstraction Layer and Abstraction/Integration Layer) are managed by OSGi DAS.
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.
This specification (Doc. 0755360r15) provides standard interfaces and device descriptions to allow inter-operability among ZigBee devices produced by various manufacturers of health care products. The specification adds restrictions at network and application level by changing the default setting of some conventional parameters, however the ZHC profile reuses, like the home automation profile, different clusters already defined in the Zigbee Cluster Library (ZCL).
- Cluster: A collection of related attributes and commands, which together define a communications interface between two devices. The devices implement server and client sides of the interface respectively.
- Attribute: A data entity which represents a physical quantity or state. This data is communicated to other devices using commands.
- Device Description:A collection of clusters and associated functionality implemented on a ZigBee endpoint. Device descriptions are defined in the scope of an application profile.
Clusters of particular relevance are the Generic Tunnel and 11073 Protocol Tunnel belonging to the Protocol Interfaces functional domain. They are used to be compliant to the ISO 11073 family standards.
Finally, the Voice over Zigbee cluster of the Telecommunications functional domain is used mainly in scenarios where the user needs to be in touch with remote operators for some emergency.
Notice that the last two clusters are not included in the ZCL specification yet. Every device belonging to the ZHC profile must implement the following ZHC Device Mandatory Clusters:
- Basic: used to hold read-only information of the device (e.g. model, manufacturer name, etc.)
- Identify: used to put the device in identification mode, in which a device uses for example a sound or blinking light to indicate to an observer where it is.
- Generic Tunnel: a set of attributes and commands needed to tunnel any protocol
- 11073 Protocol Tunnel: for tunneling data conforming to the IEEE 11073 protocol
The real description of ZHC devices is delegated to the IEEE Health informatics standard to which each ZigBee device is aligned, based on the subsections of standard ISO/IEEE P11073: 10404, 10407, 10408, 10415, 10417, 10419, 10421, 10441, 10442, 10471, 10472.
The 11073 Protocol Tunnel is the major cluster used to communicate according the above protocols. The commands provided from this cluster are:
- Transfer APDU: its payload is a byte array of variable length representing the Application Protocol Data Unit of the ISO 11073 standard. It is the only mandatory command.
- Connect Request: it specifies the IEEE address target and endpoint of the Data Management device transmitting the tunneled data
- Disconnect request: to terminate the tunneling
- Connection Status Notification: generated by the agent device for connection status change
| Data Management | |||
| Data Collection Unit | |||
| Multifunction | |||
| Multifunction Healthcare Device | |||
| Disease Management | |||
| Pulse Oximeter | ECG | Blood Pressure | Thermometer |
| Weight Scale | Glucose Meter | International normalized ratio | Insulin Pump |
| Peak Flow Monitor | |||
| Health and Fitness | |||
| Fitness and activity monitor | Strength fitness equipment | Physical Activity Monitor | Step counter |
| Sensors for Aging Independently | |||
| Activity Hub | Adherence | Fall | PERS |
| Smoke | CO | Water | Gas |
| Motion | Property Exit | Enuresis | Contact |
| Usage | Switch | Dosage | Temperature |
The task of configuring devices and networks to achieve the needs of the specific installation is known as commissioning. There are a wide range of tasks around the commissioning:
- Preliminary steps: Survey of the radio environment, Survey of the physical environment, Placement of devices
- Network configuration: Configurations of parameters, Application binding, Optimization of network, Testing and verification of correct operation
- Membership: Devices included (excluded) from a specific network
- Group and Bindings: How devices are logically connected to each other, or belong in groups where different logical connections are required
- Application: Application-specific settings to be set
- Restart Device Request (mandatory): It is sent by a tool (or a device, maybe a gateway for remote commissioning) instructing a device to restart with a specific set of attributes (SAS – startup attribute set): Startup control / EPID of the network / Channel mask / Security information
- Reset Startup Parameters Request (mandatory): Restore default configurations
- Save Startup Parameters Request (optional): It allows for the current attribute set to be stored under a given index in a non-volatile way on ZigBee node (max 256 sets)
- Restore Startup Parameters Request (optional): It allows to restore one of the stored configurations
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 we 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.
According to ISO/IEEE 11073 technical standard, an agent (source) collects health user information and transfers it to a manager (sink) for storage, display and/or possible later transmission to remote services for further analysis. The connection between the agent and a manager is always point-to-point. In spite of the ISO/IEEE 11073 has been defined from origin as a transport agnostic standard (define the messages that travel between agents and managers but not how those messages should be transmitted), the most popular and widespread transport protocol employed by those x073 certified devices available currently in the market is the Bluetooth wireless technology with its Health Device Profile (Bluetooth Health Device profile, HDP). Bluetooth HDP uses the Multi-Channel Adaptation Protocol (MCAP) for managing connections, disconnections as well as reconnections of the Logical Link Control and Adaptation Protocol (L2CAP). HDP and MCAP enable the establishment of one or more L2CAP Data Channels to support the exchange of device-specific data between sources and sinks.
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.