Project Description
HYDRA
Networked Embedded System middleware for Heterogeneous physical devices in a distributed architecture
The Hydra project was a 4½-year Integrated Project that developed middleware for Networked Embedded Systems. The project ended in 2010.
The Hydra middleware allows developers to incorporate heterogeneous physical devices into their applications by offering easy-to-use web service interfaces for controlling any type of physical device irrespective of its network technology such as Bluetooth, RF, ZigBee, RFID, WiFi, etc. Hydra incorporates means for Device and Service Discovery, Semantic Model Driven Architecture, P2P communication, and Diagnostics. Hydra enabled devices and services can be secure and trustworthy through distributed security and social trust components of the middleware.
Due to trademark rights, the name “Hydra” can not be used for the middleware when marketed after the end of the project. So the partners registered a commercial name LinkSmart, which will be used for post-project artefacts, whereas Hydra only refers to project-related events and artefacts.
Rationale
Producers of devices and components are increasingly facing the need for networking their own and complementary products in order to provide higher value-added solutions for their customers or because citizen centred demands require much more focus on intelligent solutions where the complexity is hidden behind user-friendly interfaces to promote Inclusion. Given the enormous amount of heterogeneous devices, sensors and actuators with embedded systems already existing in the market, the diversity of the producers and manufactures, the different clock speed of the deployed technologies (from several decades to some months), there is a very large need for technologies and tools that easily can add, implement and exploit the intelligence embedded in the devices. The goal for the producers is to be able to build cost-efficient ambient intelligence systems with optimal performance, high confidence, reduced time to market and faster deployment and still build on the enormous assets of the installed base.
Project data
EU project (FP6)
IP
Technology
13 Partners
Start July 2006
Finish December 2010
Grant 034891
Budget: 12.5 m€
Funding: 7.7 m€
Architecture
The software architecture is an abstract representation of the software part of the Hydra middleware. The architecture is a partitioning scheme, describing components and their interaction with each other.
The middleware constitutes a software layer between the operating system of software enabled device and a user application that communicates with that device.
The middleware provides protocols that execute on top of the transport layer and provide services to the application layer.
Figure 1 gives a structural overview of the middleware and explains how the elements are logically grouped together. “Hydra Managers” constitute the major building blocks that make up the middleware.
A Hydra Manager encapsulates a set of operations and data that realise a specific functionality.
Figure 1 The Hydra architecture – allocation of Hydra Managers to Network Components
Technology
The main technical components in the Hydra architecture are:
- Service-Oriented Architecture
- Model-Driven Approach
- 3-layered Discovery Architecture
- P2P-based Network Architecture
- Dynamic Runtime Architecture
- Context Management
- Self-* Management
- Security and Trust enabled
- Storage Management
All devices and services comprising the middleware have been integrated in a Service Oriented Architecture (SoA), which effectively turns all devices into web services and thus provides extensive interoperability at the syntactic level, i.e. the capability of components to talk to each other regardless of the interface technology and their physical locations, is achieved by means of standard protocols from the world of web services, e.g. XML, XSL-t, SOAP, WSDL, XML Schema, WS-Security, WS-Addressing and several others.
A key feature of the Hydra middleware is to bring semantic web technologies down to the device level, i.e., each device can act as a semantic web service accessible by other devices, users and software applications. Ontologies are also used to create models of applications enabling context-related semantic support.
Due to the model-driven architecture, the middleware uses metadata on devices and lower-level protocols to semantically resolve new devices as they enter a Hydra Network during run-time and automatically generate the software drivers for the web services. The middleware provides a discovery architecture that builds on UPnP technology. The approach implements a three layered discovery architecture that includes physical device detection, UPnP network announcement and semantic resolution of devices against a device ontology.
The middleware distinguishes between powerful devices that are capable of running the Hydra middleware natively and smaller devices that are too constrained or closed to run the middleware. For the latter devices, proxies are used and once proxies are in place, all communication is based on the IP protocol. Ontologies are also used to create models of applications enabling context-related semantic support.
The Hydra Access Control Framework is policy-driven: access control policies are used to define and enforce resource access security. Hydra uses the declarative eXtensible Access Control Markup Language (XACML) format to define and evaluate access control policies.
Expected Project Outcomes
The tangible outcomes of the project are:
- The Software Development Kit (SDK)
- The Device Development Kit (DDK)
- The Integrated Development Environment (IDE)
- The LinkSmart Open Source Middleware
- The LinkSmart training package
The outcome of the Hydra project is an Integrated Development Environment (IDE) composed of two parts: (i) a set of tools and class libraries for application developers, called the Software Development Kit (SDK), and (ii) tools intended to facilitate for device developers to make their devices Hydra compliant, the Device Development Kit (DDK). The IDE integrates tools on two main platforms, Eclipse and .Net.
Whereas the SDK is focused on the development of applications of devices, the purpose of DDK is to adapt various physical devices for use by application developers. Many elements of the platform are of course common to both the SDK and the DDK.
As the Hydra name cannot be used for the middleware after the end of the project due to trademark rights, the registered commercial name for the Hydra middleware, LinkSmart™, has been registered. The project name of Hydra has also been replaced in all parts of the software’s source code with the name LinkSmart.
In-JeT’s role in the project
In-JeT was the chief vision-owner of the Hydra project. As manager of the workpackage on requirements engineering, we undertook scenario thinking workshops and developed future scenarios for usage of the Hydra middleware by developers. We further managed the iterative requirement process and developed procedures for capturing Lessons Learned and performed requirements re-engineering, constantly keeping the project aligned with its objectives and vision.
In-JeT was also in charge of the workpackage on business modelling, where we, together with partners, developed concepts and methods for value models and process models and created business cases in the domains of healthcare, energy control and agriculture.
On the dissemination and exploitation side, we developed the projects’ dissemination strategy and the Hydra website. Finally In-JeT also chaired the Technical Advisory Board.
Partners
- Fraunhofer Institute for Applied Information Technology, Germany (Coordinator)
- CNet Sweden AB, Sweden (Technical coordinator)
- Fraunhofer Institute for Secure Information Technology, Germany
- In-JeT ApS, Denmark
- Priway, Denmark
- T-Connect, Italy
- Telefónica I+D; Spain
- University of Aarhus, Dept. of Computer Science, Denmark
- Innova S.p.A., Italy
- University of Reading, Informatics Research Centre, UK
- Siemens Business Services, Germany
- Technical University of Kosice, Slovakia
- University of Paderborn, Germany (partly)
Funding
Co-funded by the European Commission 6th Framework Programme for Research.
