Vision and Challenges for Realising the Internet of Things

More documents

Recommendations

Info

3.2 Semantic Device Discovery and Ontologies Semantic Device Discovery: The basic idea behind the Hydra semantic model-driven architecture (MDA) is to differentiate between the physical devices and the application’s view of the device. A Hydra device is the software representation of a physical device. This representation is either implemented by a Hydra software proxy running on a gateway device or by embedded Hydra software on the actual device. A Hydra device is said to Hydra-enable a physical device. The concept of semantic devices, which is based on Hydra devices, supports static as well as dynamic mappings to physical devices. Mappings can be both 1-to-1 from a semantic device to a Hydra device or compositions of multiple devices into an aggregate. An example of a 1-to-1 mapping would be a “semantic pump” that is exposed with all its services to the programmer, whereas a “semantic heating system” is a composition of three different underlying Hydra devices – a pump, a thermometer and a digital lamp [1]. Hydra supports the semantic MDA approach from two perspectives: At design-time through the use of the Hydra Device Ontology, whereby it supports both device developers as well as application developers. When a new device type is needed, the adequate concept in the device classification ontology can be further sub-classed by more specialised concepts and the new properties can be added. Specific device models are created as instances of device ontology concepts and serve as templates for run-time instances of physical devices. At run-time, whereby Hydra applications can use knowledge provided by various device management services (e.g. discovery and updates). In the device discovery process, the discovery information is resolved using the ontology and the most suitable template is identified. The identified template is cloned and a new unique run-time instance representing the specific device is created. These device descriptions can 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 that fits this general category will be presented to the application. This means that an application need only know the types of devices and services. The application may use a device that may have been designed and built after the application was defined, as long as it can be classified through the device ontology as being of a device type or using a service that is requested by the application. The Hydra SDK is available in an object-oriented language environment providing class libraries developers can use to program with existing devices, and to generate new ones. Specific tools exist for accessing and maintaining the Device ontology. Device Discovery Architecture: The Hydra MDA includes a three-layer discovery architecture. The discovery process operates both locally and remotely so that devices that are discovered in a local Hydra network can also be discovered in a Hydra network over the P2P protocol implemented by the Hydra Network Manager. The lowest discovery layer implements the protocol-specific discovery of physical devices. This is performed by a set of specialized discovery managers listening for new devices at gateways in a Hydra network. The second layer uses UPnP/DLNA technology to announce discovered physical devices in the local network and to peer networks. At the top most layer the device type is resolved against the device ontology and is mapped to one or more Hydra device types. Hydra Device Ontology: The Hydra Device Ontology is expressed in OWL-DL [5,7] and is structured in several modules connected to the core ontology concepts, describing device capabilities like hardware and software properties, services, device malfunctions, QoSproperties, energy profiles, and device security properties [1]. The Hydra device ontology was. as illustrated in Figure 4.8-4, initially based on the FIPA Device Ontology, which specifies a frame-based structure to describe devices [3]. The initial device taxonomy has been extended based on the AMIGO project vocabularies for device descriptions [2] and has been further extended with additional subsets for specific device capabilities. CERP-IoT – Cluster of European Research Projects on the Internet of Things 160
Figure 4.8-4: Hydra Device Ontology. 3.3 Security There are many security challenges in a homogeneous environment, but are even larger when we move to enable interoperability across heterogeneous platforms and protocols, which otherwise are incompatible. It is expedient that users inside ambient environments should be able to simply specify their security, privacy and trust requirements as policies. The Hydra security framework deploys a policy enforcement framework comprising of a policy administration component, a policy decision component, a policy enforcement component, a policy conflict resolution component and the core Hydra policy language. The confluence of these components ensures that security decisions made by the individual user are enforced as and when necessary [11]. A further concern in ambient intelligence is that of context-awareness and securing context information. Context information can be shared in a “push” or “pull” approach. Context managers, the components within the Hydra middleware responsible for context acquisition and sharing, can assign security policies to context data, which in general identify Hydra principals who are authorised to access context data. For the “pull” approach, the enforcement is straightforward, as context consumers make themselves known and the distribution can be dealt with on a case-by-case basis. For the “push” approach to context sharing, a blackboard has been realised. Whenever data is published onto the blackboard, it is accompanied by a security policy, which will be used for the authorisation decision about who can subscribe to the published data. A third paradigm, originating from MobiPets, is virtualisation [10]. Hydra applies virtualisation mechanisms to different entities: virtual devices or proxies act as logical representations of devices to protect the actual device from possible attacks by adding another protection layer. By defining a proxy for a physical device, it is possible to integrate non-Hydra-enabled devices into a Hydra-enabled network and to enable further high-level concepts, such as semantic description of device capabilities or resolution of security. In addition, physical devices can be assigned to specific virtual device classes in a way that best serves their control within an application context – e.g. it is possible to define a “virtual” global light-switch that controls all lights within a building. 3.4 Service oriented Architectures and Hydra The term Service-Oriented Architecture, i.e., describes an architectural style in which units of functionality are exposed by ‘service providers’ in a network-accessible and loosely coupled way as ‘services’ used by ‘service consumers’, is used both inside the Hydra middleware and encouraged in applications built using the Hydra middleware on top of it. As an example in the agriculture scenario, the robotic radio transmitter and the irrigation system itself could be exposed and interact through services. Inside Hydra, the managers of the middleware expose their functionality as services and interact through services. Outside Hydra, applications may use Hydra managers through services and the Hydra SDK/DDK contains tools to serviceenable elements of applications. CERP-IoT – Cluster of European Research Projects on the Internet of Things 161
Page 1 and 2:
Vision and Challenges for Realising
Page 3 and 4:
Foreword Vision and Challenges for
Page 5 and 6:
Table of contents Foreword Vision a
Page 7 and 8:
1 Organization ....................
Page 9:
Chapter 1 The Internet of Things
Page 12 and 13:
1 Origin of the concept of "Interne
Page 14 and 15:
2.1 Research perspective Today the
Page 16 and 17:
(RFID), Near Field Communication (N
Page 18 and 19:
According to SRI Consulting Busines
Page 20 and 21:
Security and software Human interfa
Page 22 and 23:
According to ISTAG, technical resea
Page 24 and 25:
ties can be grouped around two axes
Page 26 and 27:
emerging uses and services, and lau
Page 29:
Chapter 2 The CERP-IoT Cluster
Page 32 and 33:
floor, and other things happening i
Page 34 and 35:
eral solutions have emerged, either
Page 36 and 37:
Acronym Project Title Coordinator H
Page 39:
Chapter 3 Strategic Research Agenda
Page 42 and 43:
Safety, Security and Privacy, Envi
Page 44 and 45:
dynamically extended and improved b
Page 46 and 47:
Domain 1 Fundamental characteristic
Page 49 and 50:
T he concept of Internet of Things
Page 51 and 52:
The vehicle itself is also consider
Page 53 and 54:
technology should foster a communit
Page 55 and 56:
Every day millions of people move u
Page 57 and 58:
3.3 Technologies supporting the Int
Page 59 and 60:
The traffic in the Internet of Thin
Page 61 and 62:
Coverage - sparse, dense or redunda
Page 63 and 64:
IoT will create new services and ne
Page 65 and 66:
including the virtual counterparts
Page 67:
Issues to be addressed: Event-driv
Page 70 and 71:
competitive marketplace that benefi
Page 72 and 73:
equired for IoT applications. Such
Page 74 and 75:
ility of things in their acting wil
Page 76 and 77:
Before 2010 2010-2015 2015-2020 Bey
Page 78 and 79:
Before 2010 2010-2015 2015-2020 Bey
Page 80 and 81:
Before 2010 2010-2015 2015-2020 Bey
Page 82 and 83:
Acknowledgements Many colleagues ha
Page 84 and 85:
T eams from research projects and i
Page 86 and 87:
should help brand owners to find th
Page 88 and 89:
3.1 Authentication Features For eac
Page 90 and 91:
4 Business Process Integration Seam
Page 93 and 94:
4.2 Challenges for Usage of Network
Page 95 and 96:
esent one step in the supply chain,
Page 97 and 98:
A reaction of things could be trigg
Page 99 and 100:
Table 4.2-1: Application Case Featu
Page 101 and 102:
NDEI- Service InformationBrokerage
Page 103:
7 References [Barry02] Barry, Dougl
Page 106 and 107:
data to a central server. When used
Page 108 and 109:
The smart retail concept holds simi
Page 110 and 111: 6 Acknowledgment The authors would
Page 112 and 113: Nevertheless, the majority of exist
Page 114 and 115: To implement this service, case and
Page 116 and 117: moving it from the reader’s anten
Page 118 and 119: The servers can process requests in
Page 120 and 121: web client. The solution largely re
Page 122 and 123: ently, establishing transparency ac
Page 124 and 125: Kourouthanassis, P., & Roussos, G.
Page 126 and 127: The importance of identity manageme
Page 128 and 129: Middleware and other software devel
Page 130 and 131: 1.2 Objectives The objective of the
Page 132 and 133: Air interfaces still do have differ
Page 134 and 135: 4.2.3 ITU-T ITU is the United Natio
Page 136 and 137: The report's conclusion highlights
Page 138 and 139: made significant progress on the de
Page 140 and 141: Finally, a more theoretical researc
Page 142 and 143: monitoring that manufactured goods
Page 144 and 145: worked RFID technology for various
Page 146 and 147: tually sold, at which moment in tim
Page 148 and 149: Business case analysis: Two busines
Page 150 and 151: of far field and near field UHF tag
Page 152 and 153: The manufacturing pilot provided sy
Page 154 and 155: also coming from distributed electr
Page 156 and 157: The ASPIRE architecture identifies
Page 158 and 159: ASPIRE Innovative filtering solutio
Page 162 and 163: Concretely, Hydra uses web services
Page 165 and 166: 4.9 Usage of RFID in the Forest & W
Page 167 and 168: sufficiently long and consistent re
Page 169 and 170: The purpose of Traceability Service
Page 171 and 172: An overview of the LCA procedure, c
Page 173: The environmental KPIs harmonize wi
Page 176 and 177: 5. Involving a large number of Memb
Page 178 and 179: Maintain a roadmap of the relevant
Page 180 and 181: 4 Members The RACE networkRFID comm
Page 182 and 183: EPoSS has close links with other ET
Page 184 and 185: Social context Surrounding people
Page 186 and 187: 2.5 Interoperability It is common k
Page 188 and 189: fraction of the time. RFID technolo
Page 190 and 191: The middleware solutions for these
Page 193 and 194: T he AmI-4-SME project is addressin
Page 195 and 196: BRIDGE (Building Radio frequency ID
Page 197 and 198: T oday’s Internet is rapidly evol
Page 199 and 200: T he CoBIs project developed a radi
Page 201 and 202: C uteLoop has the strategic objecti
Page 203 and 204: T he DiY Smart Experiences project
Page 205 and 206: T he project objectives of DYNA- MI
Page 207 and 208: epresentatives of the Member States
Page 209 and 210: Approach The EURIDICE platform will
Page 211 and 212:
T he first objective of the Hydra p
Page 213 and 214:
This will produce new inputs to set
Page 215 and 216:
IMS2020 strives for strengthening i
Page 217 and 218:
L eapfrog is a joint research and i
Page 219 and 220:
F easibility study for an improved
Page 221 and 222:
R FID will form the basis of better
Page 223 and 224:
T he SMART project employees RFID t
Page 225 and 226:
T he StoLPaN project aims to define
Page 227 and 228:
T he recently completed three-year
Page 229:
Expected Impact WALTER is aimed at
Page 235 and 236:
Free publications: HOW TO GET EU PU
show all

Vision and Challenges for Realising the Internet of Things

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?