The Hydra project is co-funded by the 
Articles Hierarchy
Semantic Technologies and their application in Hydra project
The services offered by physical devices are generally designed independently of a particular application where the devices might be used. The semantic device on the other hand represents functionality of a device from the point of view of a particular application have. As an example , when we are designing the lighting system for a building, it would be appropriate to model the application as working with a virtual lighting system providing services like “switch on/off working light”, “switch on/off presentation light”, “switch on/off comfort light” etc., rather than working with a set of concrete lamps that can be turned on/off. These virtual (semantic) devices might in fact consist of aggregates of physical devices, and use different physical devices to provide the service depending on the situation. The service “switch on working light” might be achieved during day-time by pulling up the blind (if it is down) and in evening by turning on a lamp (the blind and lamp being HYDRA devices). We call these logical aggregates of devices and their services Semantic Devices. Semantic Devices should be seen as a programming concept. The application developer designs and programs his application using semantic devices. For example, semantic device “Heating System” can consist of three physical devices: a pump that circulates the water, a thermometer that delivers the temperature and a light that flashes when something goes wrong. Application developer will only have to use the services offered by the semantic device “Heating System”, for instances “Keep temperature at: 20 degrees of Celsius” and “Set warning level to: 17 degrees of Celsius”, and does not need to know the underlying implementation of this particular heating system. The Semantic Device concept is flexible and will support both static mappings as well as dynamic mappings to physical devices.
Semantic descriptions of the devices and their services are used at the design time to find suitable services for the application that the application developer is working on. The descriptions of these services will be used to generate code to call the service, query the device that implements the service, and manipulate the data that the service operates on. The application developer can specify a service to be used, and leave the device as generic as possible. The necessary code will be generated both for the service and the device. These device objects could be used when creating a semantic device or a HYDRA application from the selected devices and services.
Model driven code generation for physical devices - semantic description is used to determine the compilation target; depending on the available resources of a device, either embedded stubs or skeletons are created for a web service (to run on the target device) or proxy stubs and skeletons are created for the web service (to run on an OSGi gateway). Semantic description also provides support for reporting the device status. Based on a description of the device states at the run-time, support code is generated for reporting state changes.
At the design time, the HYDRA application developer selects HYDRA devices and services that will be used to implement the application. These devices may be defined at a fairly general level, e.g. the application may only be interested in a "HYDRA SMS Service" and any device entering the network (or application context) that fits into this generic definition will be presented to the application. The application will then work against the more general device descriptions. This means that an application should be only aware of (the types of) devices and services selected by the developer when it was defined. This also implies that the application could use a device that was designed and built after the application was deployed, as long as the device can be classified through the device ontology as being of a device type or using a service that is known to the application, i.e. for example a HYDRA application built in 2008 could specify the use of "HYDRA Generic Smart phone" and "HYDRA SMS Service" and thus use also a "Nokia N2010 Smartphone" released two years later in 2010. When a device is discovered, the device type is looked up in the device ontology and mapped to a specific device. A HYDRA application may present an external interface so that it can be integrated with other applications and devices. It will do this by introducing itself as a HYDRA device with a set of services. This is transparent to other devices, which means that some devices or services used in the application will be composite ones, based on other HYDRA applications that have exposed external interfaces. When such an application is discovered, the applications interested in that type of device and its services will be notified.
In the area of security, the ontology is used to describe the security capabilities of Hydra devices and different services they provide. Devices and services provide descriptions of their security properties, which refer to instances in the security ontology. Further information can then be derived from this ontology, such as the protection goals supported by a device’s security mechanisms. The basic device ontology describing device and service properties was extended by a model representing security concepts. The NRL ontology [8] was selected as a starting point for this model and has been modified and extended to match the Hydra’s requirements. The NRL ontology is a set of various security related models covering the representation of credentials, algorithms, assurances, but also the service security aspects directly supporting the SOA approach. Information contained in the ontology is designed with main focus to the functional aspects of capability, content and parameters. The main NRL ontology class covering the most basic security concepts, called SecurityConcept was linked with the main device ontology concept HydraDevice and the main service ontology concept Service. This simple interconnection of ontology concepts allows to add easily any security properties to both the devices and services separately. Describing security capabilities of the devices and services in a semantic way provides a number of benefits: By retrieving the security descriptions of the devices and services and by using the implicit knowledge inferred from the security ontology, it is possible to reason about the set of security mechanisms that is supported by all the involved parties and at the same time to match requirements stated by a given policy. This way the access control decisions could be based on this implicit knowledge gained from the security ontology. As an example, one could imagine a policy stating that only devices running an EAL4 certified operating system may be used. Thus, the semantic representation of security capabilities supports a high-level specification of security policies, which allows developers to specify their actual intention instead of concrete mechanisms to be used.
Semantic descriptions of the devices and their services are used at the design time to find suitable services for the application that the application developer is working on. The descriptions of these services will be used to generate code to call the service, query the device that implements the service, and manipulate the data that the service operates on. The application developer can specify a service to be used, and leave the device as generic as possible. The necessary code will be generated both for the service and the device. These device objects could be used when creating a semantic device or a HYDRA application from the selected devices and services.
Model driven code generation for physical devices - semantic description is used to determine the compilation target; depending on the available resources of a device, either embedded stubs or skeletons are created for a web service (to run on the target device) or proxy stubs and skeletons are created for the web service (to run on an OSGi gateway). Semantic description also provides support for reporting the device status. Based on a description of the device states at the run-time, support code is generated for reporting state changes.
At the design time, the HYDRA application developer selects HYDRA devices and services that will be used to implement the application. These devices may be defined at a fairly general level, e.g. the application may only be interested in a "HYDRA SMS Service" and any device entering the network (or application context) that fits into this generic definition will be presented to the application. The application will then work against the more general device descriptions. This means that an application should be only aware of (the types of) devices and services selected by the developer when it was defined. This also implies that the application could use a device that was designed and built after the application was deployed, as long as the device can be classified through the device ontology as being of a device type or using a service that is known to the application, i.e. for example a HYDRA application built in 2008 could specify the use of "HYDRA Generic Smart phone" and "HYDRA SMS Service" and thus use also a "Nokia N2010 Smartphone" released two years later in 2010. When a device is discovered, the device type is looked up in the device ontology and mapped to a specific device. A HYDRA application may present an external interface so that it can be integrated with other applications and devices. It will do this by introducing itself as a HYDRA device with a set of services. This is transparent to other devices, which means that some devices or services used in the application will be composite ones, based on other HYDRA applications that have exposed external interfaces. When such an application is discovered, the applications interested in that type of device and its services will be notified.
In the area of security, the ontology is used to describe the security capabilities of Hydra devices and different services they provide. Devices and services provide descriptions of their security properties, which refer to instances in the security ontology. Further information can then be derived from this ontology, such as the protection goals supported by a device’s security mechanisms. The basic device ontology describing device and service properties was extended by a model representing security concepts. The NRL ontology [8] was selected as a starting point for this model and has been modified and extended to match the Hydra’s requirements. The NRL ontology is a set of various security related models covering the representation of credentials, algorithms, assurances, but also the service security aspects directly supporting the SOA approach. Information contained in the ontology is designed with main focus to the functional aspects of capability, content and parameters. The main NRL ontology class covering the most basic security concepts, called SecurityConcept was linked with the main device ontology concept HydraDevice and the main service ontology concept Service. This simple interconnection of ontology concepts allows to add easily any security properties to both the devices and services separately. Describing security capabilities of the devices and services in a semantic way provides a number of benefits: By retrieving the security descriptions of the devices and services and by using the implicit knowledge inferred from the security ontology, it is possible to reason about the set of security mechanisms that is supported by all the involved parties and at the same time to match requirements stated by a given policy. This way the access control decisions could be based on this implicit knowledge gained from the security ontology. As an example, one could imagine a policy stating that only devices running an EAL4 certified operating system may be used. Thus, the semantic representation of security capabilities supports a high-level specification of security policies, which allows developers to specify their actual intention instead of concrete mechanisms to be used.