FP7-ICT-2013-EU-Japan ClouT: Cloud of Things for empowering the citizen clout in smart cities FP7 contract number: 608641 NICT management number: 167ア Project deliverable
D2.1 – Reusable components, techniques and standards for the CIaaS
ABSTRACT
This document contains a collection of reusable objects (hardware and software components, techniques, protocols and standards) candidate to be part of the Infrastructure layer in the ClouT Reference Architecture. All these objects - described in detail within the document - derive from the experience of each project’s partner, from pilot cities existing assets and from the state of the art.
The final result will be the input – together with other deliverables, namely D1.1 (“Use Cases & User Requirements”) and D3.1 (“Reusable Components and techniques for CPaaS”) - for the definition of the ClouT Reference Architecture that will be described in the next deliverables, being D1.2 (“First version of Reference Architecture and Reusable Components”) and D1.3 (“Final Requirements and Reference Architecture”).
Only some of the illustrated objects in this document will be inserted in the ClouT Reference Architecture: the choice depends on the features and advantages related to each component, and especially from User and system requirements that will be extracted from the collection of the use cases.
D2.1 - Reusable components, techniques and standards for the CIaaS
Disclaimer
This document has been produced in the context of the ClouT Project which is jointly funded by the European Commission (grant agreement n° 608641) and NICT from Japan (management number 167ア). All information provided in this document is provided "as is" and no guarantee or warranty is given that the information is fit for any particular purpose. The User thereof uses the information at its sole risk and liability. This document contains material, which is the copyright of certain ClouT partners, and may not be reproduced or copied without permission. All ClouT consortium partners have agreed to the full publication of this document. The commercial use of any information contained in this document may require a license from the owner of that information. For the avoidance of all doubts, the European Commission and NICT have no liability in respect of this document, which is merely representing the view of the project consortium. This document is subject to change without notice.
The ClouT consortium is composed of the following institutions:
No. Participant organization name Short name Country
Commissariat à l’énergie atomique et aux énergies CEA 1 France alternatives (coordinator)
2 Engineering Ingegneria Informatica SpA ENG Italy
3 University of Cantabria UC Spain
4 STMicroelectronics S.r.l. ST Italy
5 Santander City Municipality SAN Spain
6 Genova Municipality GEN Italy
7 Nippon telegraph and telephone East Corporation NTTE Japan (NTT East) (coordinator)
8 Nippon Telegraph and telephone corporation (NTT NTTRD Japan R&D)
9 Keio University KEIO Japan
10 Panasonic System Solution PANA Japan
11 National Institute of Informatics NII Japan
ClouT – 31.07.2013 Page 2
D2.1 - Reusable components, techniques and standards for the CIaaS
EU Editor Bartolomeo Turco, ENG JP Editor Hiroyuki Maeomichi, NTTRD Authors [Bartolomeo Turco, ENG] , [Philip Wright, ENG], [Takuro Yonezawa, Keio], [Levent Gurgen, CEA], [Yazid Benazzouz, CEA] [Marco Grella, ST], [Jose Antonio Galache, UC], [Hiroyuki Maeomichi, NTTRD], [Stefania Manca, GEN], [Fernando Mons Nunez, SAN] Internal reviewer Jose Antonio Galache, UC Deliverable type R Dissemination level PU (Confidentiality) Contractual Delivery Date 31/07/2013 Actual Delivery Date 31/07/2013 Keywords ClouT, Cloud Computing, IoT, Smart Cities, CIaaS, Reusable Components
Revision history
Revision Date Description Author (Organization) v0.1 10.06.2013 Table of Contents created ENG
v0.2 08.07.2013 First draft with some contributions from some ENG partners v0.3 12.07.2013 Second draft with contributions from all partners ENG
v0.4 19.07.2013 First complete document to the internal ENG reviewer V0.5 29.07.2013 Reviewed version UC V1.0 31.07.2013 Final version ENG
ClouT – 31.07.2013 Page 3
TABLE OF CONTENTS
TABLE OF CONTENTS ...... 4 LIST OF FIGURES ...... 7 LIST OF TABLES ...... 9 LIST OF ABBREVIATIONS AND DEFINITIONS ...... 10 EXECUTIVE SUMMARY ...... 11 1. INTRODUCTION ...... 12
1.1. SCOPE OF THE DOCUMENT ...... 12 1.2. TARGET AUDIENCE ...... 13 1.3. STRUCTURE OF THE DOCUMENT ...... 13 2. IOT KERNEL ...... 15
2.1. INTRODUCTION ...... 15 2.2. STANDARD BASED CITY SENSING BACKBONE - REUSABLE COMPONENTS ...... 15 Digimesh/GPRS - based service architecture ...... 15 802.15.4-based Experimental architecture ...... 16 Hybrid 802.15.4/DIGIMESH/GPRS NETWORK ...... 17 IoT-A models ...... 18 CoAP ...... 21 MQTT ...... 23 FI-WARE IoT Protocol Adapter ...... 28 MBXXX boards ...... 30 STEVAL-IDZ401V1 ...... 31 STEVAL-IHP004V1 ...... 32 SPIRIT1/STM32L1 BASED platforms ...... 34 SPEAr320 ...... 37 Waspmote ...... 40 Meshlium ...... 42 Arduino ...... 42 Raspberry ...... 44 STLinux O.S...... 44 CONTIKI O.S...... 45 THINGSQUARE MIST ...... 47 2.3. ABSTRACTING IOT DEVICES - REUSABLE COMPONENTS...... 47 Commserver ...... 47 Microsoft .NET Gadgeteer ...... 48 3. VIRTUALIZATION AND HOSTING OF CITY RESOURCES ...... 50
3.1. INTRODUCTION ...... 50 3.2. VIRTUALIZATION AND HOSTING OF LEGACY AND IOT DEVICES - REUSABLE COMPONENTS ...... 50 Remote node flashing ...... 50 COSM/Xively ...... 51 Nimbits ...... 51 Ovirt ...... 51 CDMI ...... 52 D2.1 - Reusable components, techniques and standards for the CIaaS
3.3. SENSORIZATION AND ACTUATORIZATION OF LEGACY DEVICES AND SOCIAL NETWORKS - REUSABLE COMPONENTS 54 Detection and visualization of place-triggered geotagged tweets...... 54 Sensor Andrew ...... 55 4. INTEROPERABLE CITY DATA ...... 57
4.1. INTRODUCTION ...... 57 4.2. SYNTACTIC INTEROPERABILITY ACROSS CONTINENTS - REUSABLE COMPONENTS ...... 57 NGSI Context model ...... 57 FI-WARE publish/subscribe context broker ...... 60 JSON ...... 61 4.3. SEMANTIC SENSOR DATA INTEROPERABILITY - REUSABLE COMPONENTS ...... 63 Sensor ML ...... 63 Sesame ...... 65 NEO4J ...... 67 5. CITY RESOURCES MANAGEMENT ...... 68
5.1. INTRODUCTION ...... 68 5.2. SELF-IDENTIFICATION, SELF-DISCOVERY AND SELF-BINDING OF CITY SERVICES - REUSABLE COMPONENTS ...... 68 Service Provision Gateway...... 68 Resource manager ...... 69 Knopflerfish ...... 71 5.3. UNIVERSAL SERVICE DESCRIPTIONS - REUSABLE COMPONENTS ...... 74 Universal service description language ...... 74 6. REUSABLE CIAAS ASSETS FROM CITIES ...... 76
6.1. INTRODUCTION ...... 76 6.2. GENOVA REUSABLE CIAAS ASSETS ...... 76 Infopark ...... 76 Acitraff ...... 79 Traffic Camera System...... 79 Weather Sensors ...... 81 6.3. SANTANDER REUSABLE CIAAS ASSETS ...... 82 Fixed Environmental Nodes ...... 82 Mobile Environmental Nodes ...... 83 Outdoor Parking Nodes ...... 84 Traffic Intensity Nodes ...... 86 Parking Lots Panels ...... 87 Parks and gardens irrigation ...... 88 Augmented Reality ...... 89 Participatory Sensing ...... 90 Gateways Nodes ...... 91 Blade Virtualization Cluster ...... 91 Eva Storage System ...... 93 GIS System ...... 93 Database Cluster ...... 94 City Fiber Network ...... 95 6.4. FUJISAWA REUSABLE CIAAS ASSETS ...... 96 Information Sharing System ...... 96 legacy environmental sensors ...... 97 6.5. MITAKA REUSABLE CIAAS ASSETS ...... 98 Information Sharing Systems ...... 98 7. CONCLUSIONS...... 101
ClouT – 31.07.2013 Page 5
D2.1 - Reusable components, techniques and standards for the CIaaS
7.1. IOT KERNEL ...... 101 7.2. VIRTUALIZATION AND HOSTING ...... 102 7.3. INTEROPERABLE CITY DATA ...... 102 7.4. CITY RESOURCE MANAGEMENT ...... 103 7.5. REUSABLE CITIES ASSETS ...... 103 8. APPENDIX ...... 104
8.1. IOT KERNEL - REUSABLE COMPONENTS ...... 104 8.2. VIRTUALIZATION AND HOSTING OF CITY RESOURCES - REUSABLE COMPONENTS ...... 125 8.3. INTEROPERABLE CITY DATA - REUSABLE COMPONENTS ...... 132 8.4. CITY RESOURCES MANAGEMENT - REUSABLE COMPONENTS ...... 138 REFERENCES ...... 142
ClouT – 31.07.2013 Page 6
LIST OF FIGURES
Figure 1. ClouT City Architecture for Smart City Ecosystem ...... 12 Figure 2. Digimesh-based service architecture ...... 16 Figure 3. 802.15.4-based experimental architecture ...... 17 Figure 4. Hybrid Digimesh/GPRS/802.15.4 network ...... 18 Figure 5. IoT domain model ...... 19 Figure 6. Functional model ...... 20 Figure 7. Functional view ...... 21 Figure 8. CoAP Logical Layers ...... 22 Figure 9. CoAP Message Format ...... 23 Figure 10. Temperature request example ...... 23 Figure 11. MQTT Network ...... 25 Figure 12. XIVELY IoT solution ...... 26 Figure 13. MQTT - REST ...... 27 Figure 14. GenericDevice API and the ZigBee protocol adapter ...... 29 Figure 15. mb954 board on the left and mb851 on the right ...... 31 Figure 16. STEVAL-IDZ401v1 dongle ...... 32 Figure 17. Smartplug diagram and top view ...... 34 Figure 18. SmartPlug front panel ...... 34 Figure 19. STEVAL-ikr001v1 spirit1 based platform ...... 36 Figure 20. Generic GW interface ...... 37 Figure 21. Spear320 block diagram ...... 38 Figure 22. Spear320 daughter boards ...... 40 Figure 23. Detail of waspmote node ...... 41 Figure 24. Detail of meshlium node...... 42 Figure 25. Arduino simple schema ...... 43 Figure 26. Sensor-Arduino-Cosm ...... 43 Figure 27. STLinux logo ...... 45 Figure 28. Contiki based firmware on stm32w core ...... 46 Figure 29. CommServer Architecture ...... 48 Figure 30. Cosm - Visualization of sent data ...... 51 Figure 31. oVirt Engine ...... 52 Figure 32. SNIA Cloud Interactions ...... 53 Figure 33. System overview of sensorization of social network ...... 55 Figure 34. Interactive visualization tool ...... 55 Figure 35. Overview of Sensor Andrew ...... 56 Figure 36. Context information Model ...... 58 Figure 37. JSON request example ...... 59 Figure 38. XML request example ...... 59 Figure 39. ContextML/CQL request example ...... 59 Figure 40. Context Broker Functioning ...... 60 D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 41. Semantic Publish/Subscribe GE w NGSI ...... 61 Figure 42. Example description of SensorML...... 64 Figure 43. Pines SensorML Editor ...... 65 Figure 44. Sesame components ...... 66 Figure 45. Class diagram of Sesame RDF Model ...... 66 Figure 46. Neo4J example ...... 67 Figure 47. Service provision gateway architecture ...... 69 Figure 48. Resource manager architecture ...... 70 Figure 49. OSGi components ...... 71 Figure 50. OSGi service contract ...... 72 Figure 51. OSGi Life Cycle ...... 72 Figure 52. Generic gateway S/W architecture ...... 73 Figure 53. Types and Entities in USDL ...... 74 Figure 54. Genova Road Visor ...... 76 Figure 55. Infopark in Genova ...... 77 Figure 56. Infopark map ...... 78 Figure 57. Acitraff ...... 79 Figure 58. Traffic Camera System ...... 80 Figure 59. Examples of camera images ...... 81 Figure 60. Weather System ...... 81 Figure 61. Whole IoT nodes deployment in the city of Santander ...... 82 Figure 62. Detail of fixed environmental nodes ...... 83 Figure 63. Detail of Mobile environmental nodes installation ...... 84 Figure 64. Outdoor parking nodes ...... 85 Figure 65. Detail of parking sensors ...... 85 Figure 66. Detail of traffic intensity nodes ...... 87 Figure 67. Parking lots panels ...... 88 Figure 68. Detail of agriculture sensor ...... 89 Figure 69. SmartSantanderAR application screenshots ...... 89 Figure 70. QR code/NFC tag stickers ...... 90 Figure 71. Participatory sensing application screenshots ...... 91 Figure 72. Blade Virtualization Cluster ...... 92 Figure 73. Eva Storage System ...... 93 Figure 74. GIS System ...... 94 Figure 75. Database Cluster ...... 95 Figure 76. City Fiber Network ...... 96 Figure 77. Twitter Account for Fujisawa City Emergence Management...... 97 Figure 78. Live Camera for Enoshima-Island in Fujisawa ...... 97 Figure 79. Air pollution sensor map in Fujisawa ...... 98 Figure 80. Twitter account for Mitaka city ...... 98 Figure 81. Twitter account for Mitaka city tourist agency ...... 99 Figure 84. SNS page for Mitaka citizen ...... 99 Figure 85. Facebook page of Mitaka Tourist Information Center ...... 100 Figure 86. Pictures and movies of Mitaka ...... 100
ClouT – 31.07.2013 Page 8
LIST OF TABLES
Table 1. List of abbreviations ...... 10 Table 2. List of key terms ...... 10 Table 3. MQTT & HTTP differences ...... 24 Table 4. Digimesh/GPRS-based service architecture...... 104 Table 5. 802.15.4-based experimental architecture ...... 105 Table 6. Hybrid 802.15.4/DIGIMESH/GPRS NETWORK...... 106 Table 7. IoT-A model...... 107 Table 8. CoAP ...... 108 Table 9. MQTT ...... 109 Table 10. FI-WARE IoT Protocol Adapter ...... 110 Table 11. MBXXX ...... 111 Table 12. STEVAL-IDZ401V1 ...... 112 Table 13. STEVAL-IHP004V1 ...... 113 Table 14. SPIRIT1/STM32L1 ...... 114 Table 15. Spear320 ...... 115 Table 16. Waspmote ...... 116 Table 17. Meshlium ...... 117 Table 18. Arduino...... 118 Table 19. Raspberry ...... 119 Table 20. STlinux ...... 120 Table 21. Contiki ...... 121 Table 22. Thingsquare ...... 122 Table 23. Commserver ...... 123 Table 24. Microsoft .NET Gadgeteer ...... 124 Table 25. Remote node flashing ...... 125 Table 26. Cosm/Xively ...... 126 Table 27. Nimbits ...... 127 Table 28. oVirt ...... 128 Table 29. CDMI-Proxy ...... 129 Table 30. Sensorization of social networks ...... 130 Table 31. Sensor andrew...... 131 Table 32. NGSI ...... 132 Table 33. FI-WARE publish/subscribe context broker ...... 133 Table 34. JSON ...... 134 Table 35. Sensor ML ...... 135 Table 36. Sesame ...... 136 Table 37. Neo4J ...... 137 Table 38. Service Provision Gateway ...... 138 Table 39. Resource manager ...... 139 Table 40. Knopflerfish ...... 140 Table 41. Universal service description language ...... 141
LIST OF ABBREVIATIONS AND DEFINITIONS
TABLE 1. LIST OF ABBREVIATIONS
6LoWPAN IPv6 Low power Wireless Personal Area Networks API Application Programming Interface CIaaS City Infrastructure as a Service COAP Constraint Application Protocol CoRE Constrained RESTful Environments CPaaS City Platform as a Service CSaaS City Service as a Service CSMA/CA Carrier sense multiple access with collision avoidance EEPROM Electrically Erasable Programmable Read-Only Memory GPIO General Purpose Input / Output IETF Internet Engineering Task Force IoT Internet of Things IoT-A Internet of Things - Architecture IPSO Internet Protocol (IP) for Smart Object communications JSON JavaScript Object Notation [RFC 4627] JTAG Joint Test Action Group M2M Machine-to-Machine MEMS Micro Electro Mechanical Systems MMU Memory Management Unit MQTT Message Queue Telemetry Transport NFC Near Field Communication NGSI Next Generation Services Interface OSGi Open Services Gateway Initiative RDF Resource Description Framework REST REpresentational State Transfer RoHS Restriction of Hazardous Substances Directive URI Universal Resource Identifiers WSAN Wireless Sensor and Actuator Network WSN Wireless Sensor Network ZigBee Low-cost, low-power, wireless mesh network standard
TABLE 2. LIST OF KEY TERMS
Actuators Mechanical devices that perform action on command, but also social networks can be used as actuator. ISM band Industrial, Scientific and Medical radio bands. It is a radio bands reserved internationally for the use of radio frequency (RF) energy for industrial, scientific and medical purposes other than communications. Sensors Equipment used to measure and convert physical quantity (e.g. temperature) or human information (e.g. social data). D2.1 - Reusable components, techniques and standards for the CIaaS
EXECUTIVE SUMMARY
The document collects from all Project Partners existing and reusable objects (hardware and software components, techniques, protocols and standards), focusing on the City Infrastructure as a Service (CIaaS) layer. They belong to various categories and can be associated to different parts of the Infrastructure layer.
Following a recap of identified objects:
Almost twenty components (sensors and actuators, communication protocols and operating systems) belong to the IoT Kernel.
About ten objects (hardware and software components) useful to implement the virtualization piece.
Six reusable components (syntactic and semantic rules and standards) need to guarantee the data interoperability.
Four objects (standards and protocols) that can be used to implement service discovery, resource identification and representation.
A particular attention has been reserved to identify open source solutions, such as standards (i.e. IETF 6LoWPAN and CoRE CoAP), platforms (i.e. Arduino), software (i.e. Contiki Operating System) and protocols (i.e. MQTT).
Some components derived also from the involved cities: Santander and Genova in Europe, Mitaka and Fujisawa in Japan. Finally some conclusions, regarding to assets indicated, have been indicated according to each topic and their interaction and inclusion within the ClouT project.
Each partner’s specific past experiences have been represented, as their contribution in the extraction of all possible reusable objects. In deciding which component to represent, the potential of each component, technique or standard to be part of the ClouT Reference Architecture was considered.
Not all presented objects will be used in the final version of the architecture, but only those ones that better respond to requirements of a Smart City Ecosystem and offer more advantages in terms of efficiency, performance and costs.
ClouT – 31.07.2013 Page 11
D2.1 - Reusable components, techniques and standards for the CIaaS
1. Introduction
1.1. Scope of the Document
This document describes initiatives, tools, solutions and available assets from all partners and cities, thus leveraging on those to build the CIaaS layer of the ClouT Reference Architecture. The following figure is the starting point (representation) of the ClouT Architecture - based on the typical cloud stratification:
Figure 1. ClouT City Architecture for Smart City Ecosystem
As shown in the Figure 1, three layers can be identified:
CSaaS (City application Software as a Service): at this layer there are all services/applications developed using APIs exposed from underlying layers (CPaaS and CIaaS).
CPaaS (City Platform as a Service): it comprises a series of specialized middleware services that allows developing applications for the citizens (end Users) and the city Manager (administrators) for the CSaaS layer, exploiting resources taken from the CIaaS layer.
ClouT – 31.07.2013 Page 12
D2.1 - Reusable components, techniques and standards for the CIaaS
CIaaS (City Infrastructure as a Service): all physical resources (sensors and actuators networks, IoT and mobile devices) and virtualization technologies (that permit homogenous interface with the CPaaS), are included within this layer.
As this deliverable will serve as starting point for the initial definition of ClouT Reference Architecture (described in the next deliverables D1.2 and D1.3), for each reusable asset a description of its main features along with several useful details are provided. Furthermore a short assessment is given, in terms of opportunities, capabilities and known limits and threats adopting the reusable component as part of the ClouT Reference Architecture.
1.2. Target Audience
The document has the following targets:
ClouT project analysts: workgroup with objective to define ClouT Reference Architecture. Starting from this document they will choose all reusable components for the Reference Architecture Infrastructure layer.
ClouT infrastructure developers: all people that will work to develop each single component for the ClouT Infrastructure. This document will be a reference manual to recover functional and technical information.
Smart City Ecosystem integrators: each person wants to implement a Smart City Ecosystem based on ClouT Reference Architecture. The content of this document can help integrators to understand advantages and issues using each single component within their ClouT Infrastructure.
1.3. Structure of the Document
In the following Chapters 2 to 5 all reusable components will be introduced and described, highlighting mainly features and advantages for a possible use in the Reference Architecture (the work is a part of the Task Group 2.1, Task Group 2.2, Task Group 2.3 and Task Group 2.4, as described in the ClouT project Description of Work [DoW]). Each chapter is dedicated to a single topic, as shown in the following picture:
ClouT – 31.07.2013 Page 13
D2.1 - Reusable components, techniques and standards for the CIaaS
Chapter 2 is related to the IoT Kernel.
Chapter 3 concerns the virtualization and hosting of the city resources (legacy systems and IoT devices).
Chapter 4 is referred to the interoperability between city systems and data.
Chapter 5 is related to the city resources management.
In addition, Chapter 6 lists a set of existing assets, extracted from ClouT involved cities – Genova (Italy), Santander (Spain), Mitaka (Japan) and Fujisawa (Japan). Finally, all conclusions are exposed in the Chapter 7, while the Appendix reports a table for each reusable object, containing general and additional details about them.
ClouT – 31.07.2013 Page 14
D2.1 - Reusable components, techniques and standards for the CIaaS
2. IoT Kernel
2.1. Introduction
This chapter deals with the low level interaction of the devices among them, with the gateway and with the Cloud services. In this deliverable the available base technologies and, optionally, the already deployed city assets are listed and analyzed, to filter out which kind of building blocks best suit ClouT objectives, and how they can cooperate. Actually, one of the main objectives is the interoperability, by means of open standards or virtualization techniques. High emphasis, so, will be devoted to standard protocols like IEEE 802.15.4, IETF 6LoWPAN, CoRE CoAP and IPSO Application Framework. The Gateway will be programmed by means of OSGi (Open Services Gateway Initiative) bundles and the functionalities more related to the assigned task will be the specification of a uniform device access mechanism and raw data collecting and processing.
2.2. Standard based city sensing backbone - Reusable components
In this section, they are listed all reusable objects, that can potentially be included in the ClouT Reference Architecture in terms of standard based city sensing backbone.
DIGIMESH/GPRS - BASED SERVICE ARCHITECTURE
Digimesh [http://www.digi.com/technology/digimesh/] is a proprietary peer-to-peer networking protocol for use in wireless end-point connectivity solutions. The protocol can be implemented in 900 MHz and 2.4 GHz ISM frequency bands. This protocol presents a simplified mesh networking, without the necessity of defining and organizing coordinators, routers or end- nodes. Overhead associated with the protocol and data payload optimizes for network performance and addressing is made simple implying a short time for defining the network. This translates into an efficient network discovery and maintenance procedures, thus allowing to add new nodes to the existing network in a straightforward way, as well as to detect nodes failure and recovery recalculating new routes accordingly.
Santander deployment (detailed within Santander city assets section) uses this Digimesh protocol for allowing bidirectional trustworthy communication among IoT nodes and gateways nodes. That translates into, on the one hand, that IoT nodes can send information they have measured to the corresponding gateway which will gather, process and send it to the corresponding platform backend and whilst, on the other hand, gateways are able to send commands to the nodes and also to flash them remotely.
ClouT – 31.07.2013 Page 15
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 2. Digimesh-based service architecture
In Figure 2, it can be observed a three level architecture: end nodes, repeaters and gateways. End nodes (e.g. parking sensors buried under the asphalt) are in charge of sensing different parameters (i.e. free or occupied parking status), sending the information to the gateway. These nodes are not able to forward information, but only to generate or receive data. Same as end nodes, repeaters are also able to sense different parameters (e.g. environmental parameters such as light, temperature or noise), but different from end nodes, repeaters are able to forward packets towards the gateway. This way, as all nodes in the network, are provided with Digimesh routing protocol; information measured by both end nodes and repeaters can be gathered and processed by the gateway (also provided with a Digimesh interface). After this, the gateway node, through more robust interfaces, such as GPRS/UMTS, Ethernet, sends the gathered information to the central server.
With a similar objective than the Digimesh interface in fixed nodes, mobile nodes are provided with a GPRS interface, in order to assure the correct sending of information associated to the service (environmental and vehicle parameters) and to the management of the devices.
For further information please refer to the table in the appendix.
802.15.4-BASED EXPERIMENTAL ARCHITECTURE
The protocol 802.15.4 is the most widely used standard for Wireless Sensor Networks communications. In this sense, it provides low data rates (up to 250 Kbps), implementing power management mechanisms for decreasing battery consumption with the corresponding increase in battery lifetimes, applying it to low-complexity devices. The working frequencies frame within the ISM band (2.4 GHz, 915 MHz and 868 MHz).
ClouT – 31.07.2013 Page 16
D2.1 - Reusable components, techniques and standards for the CIaaS
Both mobile and fixed nodes - belonging to the SmartSantander deployment (detailed within Sanatnder city assets section) - will be provided with an 802.15.4 interface, thus assuring the communication with other devices provided with this standardized interface. This implies that new nodes can easily interact with all these devices, thus contributing to the scalability of the deployed network.
Figure 3. 802.15.4-based experimental architecture
In Figure 3, (same as that for Digimesh architecture), it can be observed the static 802.15.4 architecture, in which both repeaters and gateways are provided with an additional 802.15.4 interface, but end nodes (mainly due to battery constraints) are just provided with the Digimesh interface for sending service frames. In this case, as previously mentioned, as native 802.15.4 interface does not implement any routing protocol, nodes could only communicate with their neighbours (one-hop communication).
For further information please refer to the table in the appendix.
HYBRID 802.15.4/DIGIMESH/GPRS NETWORK
Considering the GPRS/Digimesh-based service architecture and 802.15.4-based experimentation architecture previously described and that, physically, fixed nodes are provided with Digimesh and 802.15.4 interfaces, whilst mobile nodes have GPRS and 802.15.4 interfaces, then fixed-fixed, mobile-mobile and fixed-mobile communications can be established through 802.15.4 interface, presenting a hybrid 802.15.4/Digimesh/GPRS network.
ClouT – 31.07.2013 Page 17
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 4. Hybrid Digimesh/GPRS/802.15.4 network
In Figure 4, it can be observed the communication between a bus and a fixed node located at a façade: using the 802.15.4 interface also referred as interface for experimentation as both mobile and fixed nodes. In order to send information gathered by the 802.15.4 interface to the corresponding central server (internet/intranet), Digimesh (implements a routing protocol) and GPRS (global coverage) interfaces are used by fixed and mobile devices, respectively. GPRS interface directly sends the information to the central server, whilst Digimesh interface sends the information to the gateway node that is provided with additional more powerful interfaces, such as GPRS/UMTS and Ethernet, in order to send information to the corresponding central server.
For further information please refer to the table in the appendix.
IOT-A MODELS
The IoT reference model provides the highest abstraction level for the definition of the IoT-A architectural reference model. It promotes a common understanding of the IoT domain. The description of the reference model includes a general discourse on the IoT domain, a domain model as a top-level description and, an information model explaining how IoT knowledge is going to be modelled.
IOT domain model
The IoT-A project defines a domain model as a description of objects belonging to a particular area of interest. The domain model also defines attributes of these objects, such as name and identifier. The domain model defines relationships between objects, for instance “instruments produce data sets”. The IOT domain model is shown in the following figure:
ClouT – 31.07.2013 Page 18
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 5. IoT domain model
The Domain Model aims to provide a way to conceptualize the target IoT scenarios and help linking the real-life entities with the information provided by sensors. Such real-life entities are physical entities, but the key point is not physical but virtual entities (since the applications do not interact with physical but with virtual entities). The model choices for physical entities are left to application designers that need resources in sensors. A virtual entity can be made up of as many virtual entities as needed.
Information model
The information model is used for demonstrating how to communicate (i.e., retrieve and store information) with a Virtual Entity (the observed entity). The Information model is also demonstrated how the pertinent data and metadata is saved. The information model is powerful enough to express device-level information and entity-level information, and to link this information together. For instance, several temperature sensors in a room can be modelled as entities with an attribute ‘hasTemperature’ measurement. The corresponding virtual entity “room” could then be modelled with an attribute ‘hasTemperature’ that contains the aggregate values of the temperature sensor entities. The (potentially dynamic) association between the
ClouT – 31.07.2013 Page 19
D2.1 - Reusable components, techniques and standards for the CIaaS
sensor devices and the entities is solved by the resolution infrastructure. The information model could support capturing these associations in two ways:
1. By keeping a history of the associations, e.g. by adding metadata to the ‘hasTemperature’ values that link to the device entity (data provenance).
2. By recording the current association, e.g. by introducing an attribute metadata object that links the entity to the resources that are currently able to contribute to the values of this attribute.
Figure 6. Functional model
Functional view
Functional view describes the grouping of IoT functions and their components. The Figure 7 below represents a diagram depicting the functional view of the IoT reference architecture. The IoT reference architecture identified the key functional groups to meet the requirements identified during their requirements-engineering process. The architecture illustrated below shows seven main blocks identified: device connectivity and communication layer that deals with heterogeneous communication protocols in the IoT domain; on top of that IoT resources and services layer that manages resources exposed by services in terms of services; Virtual entity level assigns the device resources as attributes to the physical entities which becomes at the end virtual entities; process execution and service orchestration level that integrates IoT services into the business process; and finally application layer that contains the business logic; besides 2 orthogonal layers, namely management and security, handles non-functional issues
ClouT – 31.07.2013 Page 20
D2.1 - Reusable components, techniques and standards for the CIaaS
related to device management, QoS management, authorization, authentication, trust, etc. Each block (i.e., functional groups) contains functional components represented as smaller boxes in the figure. The lines between functionality groups –terminating in ellipses- represent interfaces.
Figure 7. Functional view
For further information please refer to the table in the appendix.
COAP
The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for requirements of constrained environments, especially considering energy, building automation and other machine-to-machine (M2M) and Internet of Things (IoT) applications. It particularly targets resource-constrained, low power devices such as WSN nodes and physical networks such as 6LoWPAN. The standardization of the protocol is a work in progress and by the Internet Engineering Task Force (IETF). CoAP has several advantages in these environments over existing solutions:
UDP binding with optional reliable unicast and multicast messages.
Asynchronous message exchanges.
ClouT – 31.07.2013 Page 21
D2.1 - Reusable components, techniques and standards for the CIaaS
Low message header overhead, which is important in a constrained network such as 6LoWPAN, where IPv6 packets are fragmented into small frames, reducing the payload.
Universal Resource Identifiers (URIs) and content types, which are necessary for web interactions.
Built-in discovery mechanism and easy HTTP integration.
CoAP interaction model relay to client/server model of HTTP, with requests and responses. Unlike HTTP, CoAP interchanges asynchronous messages over UDP or UDP-like datagram- oriented transport protocols. This is done by a logical layer of messaging that deals with UDP and asynchronous message interchange, as shown in the following figure:
Figure 8. CoAP Logical Layers
Messaging Model and Format
The CoAP messaging model is based on the exchange of messages over UDP between endpoints. A CoAP message does not necessarily require reliable transmission (NON, Non-confirmable message type), but CoAP messaging model enables sending messages with an acknowledgement requirement (CON, Confirmable message type) and in that case recipient sends an acknowledgement message (ACK). Each message contains a message id for detecting duplicate messages and confirmable messages are retransmitted with a default timeout. If recipient is not able to process the message, it sends a reset message (RST). The following figure contains the format of a CoAP message containing various information such as the version, type (confirmable or not), token length, message code (request or response), message ID (e.g., for duplication detection), options and payload.
ClouT – 31.07.2013 Page 22
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 9. CoAP Message Format
CoAP makes use of standard HTTP methods; GET, POST, PUT, DELETE in a similar way to HTTP. Regarding to response codes, these correspond to a small subset of HTTP response codes with a few CoAP specific codes added. Below you can find an example for requesting temperature resource value from a device with a GET method, with a confirmable request. With a resource based approach the temperature information is expressed in terms of a resource identified with a URI:
Figure 10. Temperature request example
For further information please refer to the table in the appendix.
MQTT
Message Queue Telemetry Transport (MQTT) is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code
ClouT – 31.07.2013 Page 23
D2.1 - Reusable components, techniques and standards for the CIaaS
footprint is required and/or network bandwidth is at a premium. The word Telemetry referred to Telemetry technology which allows things to be measured or monitored from a distance (IBM 2012). For a better understanding, the following table resumes the difference between MQTT and HTTP:
TABLE 3. MQTT & HTTP DIFFERENCES
The most important difference in the table is that MQTT uses Publish/Subscribe mechanism. However, it is possible to use point-to-point messaging for individual clients, such as actuators, that typically only receive information pertaining to them specifically. As an alternative to the publish/subscribe approach, a WebSphere MQ application has the capability to send an unsolicited message to an MQTT V3 client directly. This method can be accomplished by putting the message onto the SYSTEM.MQTT.TRANSMIT.QUEUE, specifying the ClientID (Client Identifier) as the queue manager and designating the topic as a queue. The message goes directly to the client because the ClientID is specified in the code through the creation of an object descriptor, with the client as the ObjectQmgrName in the WebSphere MQ application.
However, in wireless sensors network (Andy Stanford-Clark 2007), a large number of battery- operated sensors and actuators (SAs) are usually equipped with a limited amount of storage and processing capabilities. Such a network is by nature very dynamic: the wireless links may temporally break at any time and nodes may fail and be replaced very often. MQTT requires TCP/IP as underlying transport and network services, being still too complex its implementation in very simple, small footprint, and low-cost devices such as wireless SAs.
MQTTs (Andy Stanford-Clark 2007) can be considered as a version of MQTT which is adapted to the peculiarities of a wireless communication environment. MQTTs are also optimized for the implementation on low-cost, battery-operated devices with limited processing and storage resources. MQTT was originally developed for running on top of the ZigBee APS layer.
ClouT – 31.07.2013 Page 24
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 11. MQTT Network
The application support sub-layer (APS) is a main standard component of the ZigBee application layer, and as such it offers a well-defined interface and control services. It works as a bridge between the network layer and the other components of the application layer.
Figure 11 shows an example of MQTTs – MQTT network design for IoT. In a ZigBee network, a gateway needs not to be hosted by a coordinator node, but on an always-on router node to be able to receive client messages at any time. Due to short payload length of the ZigBee network/APS layer, the maximum length of a MQTTs message gets restricted to 60 octets.
As shown in Figure 11, a communication architecture using MQTT technology implements MQTT clients and brokers. An MQTT client (also called a client application) collects information from a telemetry device, connects to a messaging server and uses a topic string to publish the information in a way that allows other clients or applications to retrieve it. An MQTT client also can subscribe to topics, receive publications associated with those topics and issue commands to control the telemetry device. An MQTT broker is a server that implements the MQTT protocol, which mediates communication between MQTT client applications, such as those running in remote sensors and other devices, with the enterprise integration layer.
In the next section, we selected the most important MQTT server/broker references which are related to ClouT project:
Xively is the Public Cloud specifically built for the Internet of Things: The Xively service provides a data cloud for the Internet of Things, with MQTT support. This is not a generic MQTT broker implementation; but it uses MQTT as a transport for publishing and subscribing to your already existing data feeds (Xively component will be described in detail in the paragraph 3.2).
ClouT – 31.07.2013 Page 25
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 12. XIVELY IoT solution
M2M.IO: It is a cloud messaging service. The broker allows the ability to connect your device and application clients using MQTT; a simple publish/subscribe protocol. The m2m.io broker allows incoming connections to q.m2m.io on port 1883 (if you're licensed for SSL, use port 8883). Any client connected is sandboxed within their "domain" level topic. Only clients with authorization are allowed to connect to the broker. This is an example of a valid payload that would be stored in the m2m.io data-store:
{ "report": { "gps": { "latitude": "39.702610038220882", "longitude": "-104.97231300920248" }, "temp": { "celsius": "252", "fahrenheit": "76" } } }
Really Small Message Broker (RSMB): It is a 75KB MQTT broker runtime free download as binaries from IBM alphaWorks, presenting a C implementation of a tiny MQTT server suitable for development, embedded systems, concentrators or small to medium sized deployments. It provides complete MQTT v3.1 support, bridging and a C client API.
Mosquitto: it is an open source (BSD licensed) message broker that implements the MQ Telemetry Transport protocol version 3.1. MQTT provides a lightweight method of carrying out messaging using a publish/subscribe model. This makes it suitable for
ClouT – 31.07.2013 Page 26
D2.1 - Reusable components, techniques and standards for the CIaaS
"machine to machine" messaging such as with low power sensors or mobile devices such as phones, embedded computers or microcontrollers like the Arduino. Among different existing OS, Mosquitto is available for Windows and Linux, Mac and iPhone.
MQTT Client and Broker technology support
As an open source protocol, MQTT is an important component in numerous connectivity solutions. The following table gives an idea about some existing solutions.
Client MQTT Java, JavaScript, C, Python, specific device (Arduino client), eclipse paho
Server/ Windows, Linux, Mac Broker
Compatibility of MQTT with REST (QEST)
QEST is a star-gate between the universe of devices which speak MQTT and the universe of apps which speak HTTP and REST like it is shown in the following figure:
Figure 13. MQTT - REST
MQTT to REST is done by:
Retains every message received: client.publish(“temp”, “30”).
Every topic has its own URI /topics/
REST to MQTT:
ClouT – 31.07.2013 Page 27
D2.1 - Reusable components, techniques and standards for the CIaaS
Transform every HTTP PUT received to a MQTT message: curl –X PUT –d ‘{“payload”:42}’ \ -H “Content-Type: application/json”\ http://qest.me/topics/temp.
Devices can listen directly to MQTT topics: void callback(char* topic, byte* payload, int length){…}; PubSubClient(server, 1883, callback); Client.subscribe(“temp”).
For further information please refer to the table in the appendix.
FI-WARE IOT PROTOCOL ADAPTER
The Protocol Adapter GE is a generic enabler which aims at handling heterogeneous devices in a common format, as designed in the GenericDevice API1 (developed by Ericsson).It is part of the “Internet of Things Service Enablement” chapter in the Fi-Ware architecture. Telecom Italia presented during a webinar session the ZigBee implementation of the Protocol Adapter (ZPA). During the webinar, the global Fi-Ware architecture was presented, and this generic enabler was placed in this context. A presentation of the ZigBee alliance was made in order to specify the applications domains, which covers smart homes, building management, smart retail, smart transports and smart health.
This GE is described as follows in the Fi-Ware catalogue: “The goal of a Gateway Protocol Adapter GE is to translate a specific protocol (in the case of ZPA is ZigBee) into a unique internal language which normalizes the different communication protocols (in the case of ZPA is the Generic Device API) “.
This generic enabler specific architecture is detailed in the Figure 14. Physical devices using ZigBee are exposed at the gateway level as a proxy device. This proxy device interface is specified by the GenericDevice API, which claims to be generic. The overall architecture uses the OSGi service execution framework. At a User level, only the proxy device is exposed, without any clue about its communication layer. Telecom Italia presented the mapping between Zigbee concepts (clusters, parameters) and the GenericDevice API concept (service, argument).
The generic proxy has the same architecture than UPnP: a device contains services, which contains methods with specified arguments. It uses the very descriptive XML format to describe devices, services and arguments.
1https://labs.ericsson.com/blog/having-a-headache-using-legacy-iot-devices.
ClouT – 31.07.2013 Page 28
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 14. GenericDevice API and the ZigBee protocol adapter
The GenericDevice API seems to be the most important part of this GE, as it specifies:
The interface and data for all IoT device, without any regards of their native protocol, for service developers, and the overall FiWare platform.
The interface to be implemented for unsupported protocols, as a Specific Enabler.
This GenericDevice API seems very inspired from UPnP, especially for the product / service / arguments structure, the semantics used and the XML schema. This solution is easy to use and close to computer science paradigms. However, it has drawbacks in its design: no state-diagrams describing functionalities and behaviour of the device are specified, and we can assume that it relies on the underlying protocol. Thus, many protocols propose different application profiles that are incompatible. The description of these application profiles may be similar, but with an incompatible implementation, or manufacturer dependent behaviour of the devices.
Taking into consideration that many proprietary protocols have to be handled, the use of such a GE becomes unavoidable. These protocols, such as SCADA, have different constraints, and different paradigms than the ones used by the Protocol Adapter GE: sensors networks may have event-driven communication layers, opposite to the on-demand design induced by the GenericDevice API. A proper adaptation would require in this case important work to have an operable Specific Enabler.
With only the ZigBee implementation available, it is hard to evaluate the effectiveness of the Protocol Adapter GE, and the associated GenericDevice API, in the ambition to provide an abstraction layer for all IoT devices. However, this GE is the main entry point for sensor data within the Fi-Ware architecture. Important work has to be planned in order to handle a larger
ClouT – 31.07.2013 Page 29
D2.1 - Reusable components, techniques and standards for the CIaaS
number of protocol. It includes feedback to Fi-Ware and development of specific enablers in order to take advantage of the Fi-Ware platform with so called “legacy devices”.
For further information please refer to the table in the appendix.
MBXXX BOARDS
The board’s mb851 and mb954 (generally referred as “MBXXX”) are development platforms based on STM32W108xx core. This development kits can be used with provided (dedicated) libraries (ZigBee RF4CE and Simplified MAC), but can be programmed with third parties tools and firmware.
These boards have a digital MEMS three axis accelerometer (LIS302DL), a precision analogue temperature sensor (STLM20W87F), two programmable LEDs and one programmable button. Additional functionalities may be added using the GPIO pins. The mb954 has a power amplifier that enables longer ranges of communication. They can be battery (two AA) or USB powered.
The STM32W-SK and STM32W-EXT starter and extension kits are easy to use tools for the STM32W108xx microcontrollers. This family of microcontrollers integrates a 32-bit ARM® Cortex™-M3 microprocessor and a 2.4 GHz, IEEE 802.15.4-compliant transceiver. The kits demonstrate how effectively the STM32W108xx can be used in real IEEE 802.15.4 applications.
The STM32W108xx kits provide demonstration applications and documentation which serve as a reference for creating your own applications and re-programming the STM32W108xx microcontroller.
You can run the STM32W108xx kits in several ways (remote control/target, HID devices such as a mouse or keyboard and point-to-point applications), using the dedicated software libraries (ZigBee RF4CE, and Simplified MAC), as well as a third-party IDE and C compiler (IAR). Moreover, the STM32W108xx kits provide a set of APIs which allow you to use the kit platform capabilities such as LEDs and serial communication channels (virtual COM through USB).
Main features:
32-bit ARM® Cortex™-M3 microprocessor.
2.4 GHz, IEEE 802.15.4-compliant transceiver.
Suitable for different types of wireless network scenarios such as:
o Remote control and target networks (based on the ZigBee RF4CE protocol stack) used for driving consumer devices such as TVs and set-top boxes, and HID devices such as a mouse or keyboard.
o Point to point networks (based on a Simplified MAC library) used to address a basic IEEE 802.15.4 communication. This configuration enables customers to develop any protocol stack of their choice.
ClouT – 31.07.2013 Page 30
D2.1 - Reusable components, techniques and standards for the CIaaS
We plan to use them to implement the sensor nodes of the 802.15.4 WSAN (Wireless Sensor and Actuator Network). A part form the integrated temperature sensor, the acceleration sensor can be used as motion, fall or intrusion detections, just to make some example. The programmable LEDs can give a useful feedback to the User, or can be used to easily simulate/debug some (missing) actuators.
In Figure 15 the pictures of the two kinds of MBxxx boards are reported. The system on chip (stm32w) and antenna are confined in the central/top part of each board, the rest contains sensors and i/o lines.
Figure 15. mb954 board on the left and mb851 on the right
For further information please refer to the table in the appendix.
STEVAL-IDZ401V1
The STEVAL-IDZ401V1 is an IEEE 802.15.4/ZigBee RF module with a USB interface and with a “dongle” style optimized form factor (as illustrated in Figure 16). The board includes an STM32F103 chipset with USB bridge functional capabilities and an STM32W chipset. Configurable LEDs and a pushbutton are also available onboard.
Different ways of programming partitioning between the STM32W and the STM32F are available. Its form factor makes it ideal to be used as border router of a 6LoWPAN network, if the gateway does not have a native 802.15.4 radio interface.
The board allows the configuration of the connection of the JTAG with the STM32W (default) or with the STM32F, or with both the processors in scan chain mode.
Main features:
Based on a 2.4 GHz IEEE 802.15.4/ZigBee® SPZB32W1A2 RF module.
Integrated STM32F103TBU6 with USB bridge capabilities.
ClouT – 31.07.2013 Page 31
D2.1 - Reusable components, techniques and standards for the CIaaS
USB interface and power supply.
Supported re-programmability via the USB interface.
JTAG connector.
Configurable pushbutton.
Configurable LEDs.
Power indicator LED.
Small dimensions 5.75 cm x 2.15 cm.
STM32W protocol stack libraries supported.
Supported application partitioning between STM32F and STM32W.
Figure 16. STEVAL-IDZ401v1 dongle
More than one dongle can be used in case multi channel networks have to be simultaneously supported; it can also be used as a ZigBee network device.
For further information please refer to the table in the appendix.
STEVAL-IHP004V1
The STEVAL-IHP004V1 demonstration board is a “SmartPlug” based on the SPZB32W1A2.1 module which integrates the STM32W108 microcontroller with IEEE-802.15.4 integrated radio
ClouT – 31.07.2013 Page 32
D2.1 - Reusable components, techniques and standards for the CIaaS
and 32-bit ARM Cortex-M3 core. It is ideal to implement both a sensor and actuator node of a WSAN.
Energy metering is provided by the STPM10 and the AC load can be controlled by a 16 A relay supporting soft-switch by the T2035H TRIAC.
The STEVAL-IHP004V1 demonstration board is a node of an RF network which allows the final User to monitor and manage the plugged load energy consumption. The node personalization is supported by the M24LR64 dual interface EEPROM. The introduction of the dual interface EEPROM enables RF communication with RFID readers or ISO15693-capable NFC phones, allowing offline programming of the smart plug’s parameters/profile, as well as download of events/logs. The STEVAL-IHP004V1 demonstration board has been developed in order to provide a guideline to build a home/building automation subsystem for energy management and sub-metering. It is designed to fit the dimensions of a standard box for wall installation and easy integration into home/building electrical plants. The current, power, energy and other info related to the electrical load connected to the SmartPlug board are sent to an IEEE-802.15.4 data concentrator through the home/building RF network.
Main features:
RF network to monitor and manage the plugged load.
Energy consumption monitoring.
IEEE-802.15.4 communication.
ON/OFF and dimming.
RoHS compliant.
The board allows digital data communication through the embedded IEEE802.15.4 2.4 GHz radio of the STM32W108CB microcontroller supporting encryption communication using the AES-128 algorithm. The module is designed to have 3 dBm output power (8 dBm in boost mode) and -99 dBm receiver sensitivity. Moreover, it has a robust coexistence with Bluetooth and WiFi.
Figure 17 illustrates a block diagram of the STEVAL-IHP004V1with the main functional blocks (Relay/Triac/Power and Energy Management, EEPROM, STM32W core) and a top view of the internal of the plug (once removed the whole front panel).
Figure 18 illustrates the part of the font panel containing LEDs (three programmable and one linked to power) and buttons (two programmable and one reset). The complete front view is completed by the standard plug.
ClouT – 31.07.2013 Page 33
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 17. Smartplug diagram and top view
Figure 18. SmartPlug front panel
This reference board is a very flexible item that allows different loads in a Smart Building scenario to be remotely driven without the need of additional wiring. It fits Smart Energy like scenarios too, thanks to the power and energy consumption reporting. Buttons and LEDs can be programmed in static (firmware) or dynamic (through gateway actions and network commands) way.
For further information please refer to the table in the appendix.
SPIRIT1/STM32L1 BASED PLATFORMS
SPIRIT1 transceiver
The SPIRIT1 is a very low-power RF transceiver, intended for RF wireless applications in the sub-1 GHz band. It is designed to operate both in the license-free ISM and SRD frequency bands
ClouT – 31.07.2013 Page 34
D2.1 - Reusable components, techniques and standards for the CIaaS
at 169, 315, 433, 868, and 915 MHz, but can also be programmed to operate at other additional frequencies in the 300-348 MHz, 387-470 MHz, and 779-956 MHz bands. The air data rate is programmable from 1 to 500 kbps, and the SPIRIT1 can be used in systems with channel spacing of 12.5/25 kHz, complying with the EN 300 220 standard. It uses a very small number of discrete external components and integrates a configurable baseband modem, which supports data management, modulation, and demodulation. The data management handles the data in the proprietary fully programmable packet format also allows the M-Bus standard compliance format (all performance classes). However, the SPIRIT1 can perform cyclic redundancy checks on the data as well as FEC encoding/decoding on the packets. The SPIRIT1 provides an optional automatic acknowledgement, retransmission, and timeout protocol engine in order to reduce overall system costs by handling all the high-speed link layer operations. Moreover, the SPIRIT1 supports an embedded CSMA/CA engine. An AES 128-bit encryption co- processor is available for secure data transfer. The SPIRIT1 fully supports antenna diversity with an integrated antenna switching control algorithm, as well as, different modulation schemes: 2- FSK, GFSK, OOK, ASK, and MSK. Transmitted/received data bytes are buffered in two different three-level FIFOs (TX FIFO and RX FIFO), accessible via the SPI interface for host processing.
Main features:
Air data rate from 1 to 500 kbps.
Very low power consumption (9 mA RX and 21 mA TX at +11 dBm).
Programmable RX digital filter from 1 kHz to 800 kHz.
Programmable channel spacing (12.5 kHz min.).
Excellent performance of receiver sensitivity (-118 dBm), selectivity and blocking.
Programmable output power up to +16 dBm.
Battery indicator and low battery detector.
AES 128-bit encryption co-processor.
STM32 L1 series of ultra-low-power MCUs
ST’s ARM® Cortex™-M3-based STM32 L1 series uses ST’s proprietary ultra-low-leakage process technology with an innovative autonomous dynamic voltage scaling and 5 low-power modes offering unprecedented platform flexibility to fit any application. The STM32 L1 series extends the ultra-low power concept with no compromise on performance.
The well-know STM8L is also a member of the ultra-low-power family sharing the same ultra- low-leakage process technology.
More than just ultra-low-power MCUs, the STM32 L1 series offers a wide portfolio of features, memory sizes and package pin counts. Combining ultra-low power and performance, the
ClouT – 31.07.2013 Page 35
D2.1 - Reusable components, techniques and standards for the CIaaS
portfolio covers from 32 to 384 Kbytes of Flash memory (with up to 48 Kbytes of RAM and 12 Kbytes of true embedded EEPROM) and from 48 to 144 pins.
This innovative architecture (voltage scaling, ultra-low-power MSI oscillator) gives your design more performance for a very low power budget. The large number of embedded peripherals, such as USB, LCD interface, op amp, comparator, ADC with fast on/off mode, DAC, capacitive touch and AES, gives the STM32 L1 series an expandable platform to fit all your requirements.
The series is available in 4 different lines: STM32L100 Value line, STM32L151, STM32L152 (LCD), STM32L162 (LCD and AES-128).
To simplify migration and give you all the flexibility you need, the STM32 L1 is pin-to-pin compatible with the different STM32 F series and opens the door to the full STM32 ecosystem.
Ultra-low-power mode: 300 nA with backup registers (3 wakeup pins).
Ultra-low-power mode + RTC: 900 nA with backup registers (3 wakeup pins).
Low-power run mode: down to 9 μA.
Dynamic run mode: down to 230 μA/MHz.
Figure 19. STEVAL-ikr001v1 spirit1 based platform
Figure 19 shows an example of a SPIRT1 based system is the STEVAL-IKR001V4 demonstration board. The demonstration board is equipped with an STM32L low power microcontroller which controls the SPIRIT1. The board also features a USB connector for PC GUI interaction and firmware updates; a JTAG connector for the microcontroller allows the development of specific firmware on the microcontroller.
Main features:
ClouT – 31.07.2013 Page 36
D2.1 - Reusable components, techniques and standards for the CIaaS
2 SPIRIT1 low power, sub-GHz RF transceiver daughter boards tuned for the 868 MHz band.
2 STM32L microcontroller-based motherboards.
Suitable for wireless M-BUS systems.
Associated SPIRIT1 software development kit with documentation, STM32L firmware and GUI.
Debug connector.
USB interface.
For further information please refer to the table in the appendix.
SPEAR320
Various ARM based platforms suitable to implement a gateway to interface the WSAN with the non constrained network are available. The SPEAr320 (see Figure 20) is one of these platforms, sitting on the low end (cheap) side of the bunch.
Figure 20. Generic GW interface
The SPEAr320 is a member of the SPEAr family of embedded MPUs, optimized for industrial automation and consumer applications. It is based on the powerful ARM926EJ-S processor (up to 333 MHz), widely used in applications where high computation performance is required. In addition, SPEAr320 has an MMU that allows virtual memory management - making the system compliant with Linux operating system. It also offers 16 KB of data cache, 16 KB of instruction cache, JTAG and ETM (Embedded Trace Macrocell™) for debug operations. A full set of peripherals allows the system to be used in many applications, some typical applications being factory automation, printer and consumer applications.
ClouT – 31.07.2013 Page 37
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 21. Spear320 block diagram
Main features:
ARM926EJ-S 333 MHz core.
High-performance 8-channel DMA.
Dynamic power-saving features.
Configurable peripheral functions on 102 shared I/Os.
Memory:
o 32 KB ROM and 8 KB internal SRAM.
o LPDDR-333/DDR2-666 external memory interface.
o SDIO/MMC card interface.
o Serial Flash memory interface (SMI).
o Flexible static memory controller (FSMC) up to 16-bit data bus width, supporting NAND Flash.
o External memory interface (EMI) up to 16-bit data bus width, supporting NOR Flash and FPGAs.
Security: Cryptographic accelerator.
ClouT – 31.07.2013 Page 38
D2.1 - Reusable components, techniques and standards for the CIaaS
Connectivity:
o 2 x USB 2.0 Host.
o 1 x USB 2.0 Device.
o 2 x Fast Ethernet ports (for external MII/SMII PHY).
o 2 x CAN interface.
o 3 x SSP Synchronous serial port (SPI, Microwire or TI protocol).
o 2 x I2C.
o 1 x fast IrDA interface.
o 3 x UART interface.
o 1 x standard parallel device port.
Peripherals supported:
o TFT/STN LCD controller (resolution up to 1024 x 768 and up to 24 bpp).
o Touch screen support.
Miscellaneous functions:
o Integrated real time clock, watchdog, and system controller.
o 8-channel 10-bit ADC, 1 Mbps.
o 4 x PWM timers.
o JPEG CODEC accelerator.
o 6 x 16-bit general purpose timers with programmable prescaler, 4 capture inputs.
o Up to 102 GPIOs with interrupt capability.
A wide set of peripherals and network interfaces (integrated or provided by means of USB dongles) make this platform ideal to implement a gateway for Home Automation, Smart Energy, Surveillance/Security, and E-Health and assisted living like applications. SPEAr320 comes as a CPU board that may be plugged on top of different daughter boards to gain more connectivity or UI capability.
Figure 22 illustrates the CPU board (EVALSPEAr320SCPU, con the right) and two possible daughter boards (that will host the CPU board on the red rectangle position):
EVALSPE320SHMI on top left (in this picture, the CPU board is plugged). This board is designed to evaluate the SPEAr320S mainly in HMI automation mode.
ClouT – 31.07.2013 Page 39
D2.1 - Reusable components, techniques and standards for the CIaaS
EVALSP320SPLC on bottom left (in this picture, the CPU board is missing). This board is designed to evaluate the SPEAr320S with a variety of devices and especially in its Media Independent Interface (MII) Automation mode.
Figure 22. Spear320 daughter boards
For further information please refer to the table in the appendix.
WASPMOTE
Waspmote module (shown in Figure 23) is a hardware platform developed by Spanish company Libelium (http://www.libelium.com/), presenting the particularity of supporting two radio interfaces.
ClouT – 31.07.2013 Page 40
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 23. Detail of waspmote node
As it can be derived from Figure 23, waspmote module is composed of two parts:
Main board: This board (called Waspmote) is in charge of processing and memory issues, providing a set of interfaces for attaching different types of sensors (both analogue and digital), as well as to plug several radio modules to communicate with other nodes. The Waspmote comes with with a ATmega1281 microcontroller, and several types of memory, 8KB SRAM, 4KB EEPROM, 128KB FLASH and an extra storing SD memory with 2GB capacity. On the other hand, 7 analogue and 8 digital interfaces are available for external sensor connection, as well as 1 PWM, 2UART, 1 I2C and 1 USB interfaces for attaching different communication modules. All the development tools (libraries, API’s, etc.) provided by Libelium are based on a pseudo-wiring solution which aims to promote the simplicity of the functioning of the micro-processor based on events and loops. Attached to the main board, they can be placed the sensor boards with the corresponding sensing capabilities, such as temperature, luminosity, noise, parking, CO, soil temperature.
Two XBee-PRO radio modules: Both modules manufactured by Digi (http://www.digi.com/) company, and can run over 868 Mhz, 915 MHz and 2.4 GHz frequency bands. On top of these 802.15.4-based radio modules, they can be installed Digimesh and Zigbee protocols, being able also to execute native 802.15.4 protocol. This flexibility opens the possibility of combining different radio interfaces on top of the same board, for instance (as explained in Section 2.2.) within the SmartSantander project, Digimesh and native 802.15.4 radio modules coexist over the same board.
In terms of both hardware and software, waspmote nodes are based on Arduino. This allows us to program them directly through an API offered by Libelium company or using the functions provided by Arduino. This means that programming will be based on C and C++.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 41
D2.1 - Reusable components, techniques and standards for the CIaaS
MESHLIUM
Meshlium node is already manufactured by Libelium company and is intended to receive, gather and process the information sent by a WSN, forwarding it to a backbone network through the internet or making it available at a web site.
Figure 24. Detail of meshlium node
As it can be derived from Figure 24, meshlium is composed of 4 antennas, 2 of them are used for communication with waspmote nodes and their corresponding two radio interfaces, whilst the other 2 ones are intended for WiFi (local management of the gateway) and UMTS (remote access to the gateway) communications. Finally, an Ethernet interface is also provided in order to connect node to connect node through the wired network, as well as to power it using Power over Ethernet (PoE).
In terms of software, meshlium nodes are provided with an embedded Linux operating system, offering higher capacity in terms of processor (500MHz) and memory (256MB RAM and up to 32GB hard disk). In this sense, meshlium node can be programmed in different languages, such as Java, C, Python.
Regarding to installation, for massive deployments, topology based on different clusters is intended, where gateway behaves as cluster head controlling several nodes, placed one or several hops away from the gateway.
For further information please refer to the table in the appendix.
ARDUINO
Arduino is an open-source electronics prototyping platform easy to use (hardware and software), dedicated to anyone interested in creating interactive objects or environments. The microcontroller on the board must be programmed using his own language that allows the developer, for example, to read a value coming from a sensor in a specific time interval.
ClouT – 31.07.2013 Page 42
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 25. Arduino simple schema
Arduino projects can be stand-alone or can communicate with a software on a computer; in our tests we opted for a stand-alone project with a dedicated Arduino's Ethernet Shield that allows to connect to the internet, making outgoing connections to a dedicated storage for the data coming from the sensor, as shown in the following figure:
Figure 26. Sensor-Arduino-Cosm
In this way, we just needed to connect an Ethernet Shield and a sensor (but they can be more than one) direct to the Arduino.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 43
D2.1 - Reusable components, techniques and standards for the CIaaS
RASPBERRY
Similar to Arduino, it is also available an open-source device named Raspberry: is a credit-card sized computer that plugs into your TV and a keyboard. It is a capable little PC which can be used for many of the things that your desktop PC does, like spreadsheets, word-processing and games; it also plays high-definition video.
In order to use it, you will need to install an Operating System (OS)2 onto an SD card: in that sense Raspberry represent a real microcomputer while Arduino is a microcontroller.
The Arduino and the Raspberry devices can easily communicate each other, with different ways: they can communicate through internet, Ethernet or Wireless communication, Bluetooth, but it is also possible to the Raspberry to use an Arduino Shield, or just convert the I/O pin tension3. With this kind of configuration it is also possible to install the Arduino's software inside the Raspberry, in this way, for instance, it will be allowed to change the code online; in fact, it must be considered that, in order to update a configuration for all the Arduino device, a sensor cable is needed: without being on the place and physically update it with a cable connection, it is not possible modify its configuration.
N.B. A nice thing that it is possible to carry out it is to make the Raspberry device behave like a server and storage, installing on it a NoSQL db, like CouchDB, and connect it to the Arduino on internet; in this way, obtaining a real internet of things communication, even if only between two devices. But we have to consider that such configuration doesn't provide a real Infrastructure for the Cloud, like a Virtual Machine can do.
For further information please refer to the table in the appendix.
STLINUX O.S.
The STLinux distribution and development environment provides everything required to build Linux based systems for STMicroelectronics products which are based around the ARMv5/7, ST40 or ST200 CPUs:
Arm tool chain to cross compiles OS and programs.
Kernel sources.
Target File system.
2 An Operating System is the set of basic programs and utilities that allow your computer to run; examples include Windows on a PC or OSX on a Mac computer. Rasperry uses a Linux OS. 3 Arduino needs 5V instead of Raspberry: Pi 3.3V, the respective Pins must be connected
ClouT – 31.07.2013 Page 44
D2.1 - Reusable components, techniques and standards for the CIaaS
The STLinux distribution and development tools are distributed as RPM files and must be installed on a host PC running a Linux distribution. Although the STLinux RPM packages can be installed on any Linux distribution, only the following 32-bit Linux Distributions are supported:
RedHat Enterprise version 4 and above.
Fedora 6 and above.
The latest kernel version available is currently 3.5 and Users can keep up to date by means of a git repository. A complete and detailed set of “how-to” and instructions is available online: it explains all the steps to use a STLinux image and file system with the different ST boards, taking into account the various possibilities, i.e. how to boot from flash or network, how to boot with a ramdisk root file system, etc.
The User can keep up to date with the provided packages updates by means of the “stmyum” utility. Kernel image and file system can be transferred on the target board using tftp protocol, and stored in the flash memory by means of Uboot commands. After this, the system acts like a normal Linux box and can be controlled via serial terminal or telnet/ssh shells.
Figure 27. STLinux logo
For further information please refer to the table in the appendix.
CONTIKI O.S.
Contiki is an open source operating system for the Internet of Things. It is written in C language and it is designed for tiny, low-cost, battery-operated and low-power systems and to connect them to the Internet. It supports by default several platforms/cpus and many porting are available in the open source community. Among these cores, it obviously supports the stm32w based platforms we plan to use in the context of the project.
Contiki integrates fully standard IPv6 and IPv4, along with low-power wireless standards like 6lowpan, RPL, CoAP. Upper layer protocols (such as UDP, TCP, and http) are of course
ClouT – 31.07.2013 Page 45
D2.1 - Reusable components, techniques and standards for the CIaaS
supported. The Contiki IPv6 stack, developed by and contributed to Contiki by Cisco, is fully certified under the IPv6 Ready Logo program. An alternative stack (Rime) is available for even more constrained scenarios.
A powerful network simulator, called Cooja, is provided to ease the development and test of large systems. Contiki is designed as a system that has only a few kilobytes of memory available, so it is highly memory efficient and provides a set of mechanisms for memory allocation, in particular a managed memory allocator ‘mmem’, as well as the standard C memory allocator ‘malloc’.
Contiki supports dynamic loading and linking of modules at run-time making it easy to change firmware after deployment. Other key features of Contiki are the event-driven and multi tasking programming provided by the protothreads mechanism and the file system support (Coffee) for permanent storage on flash memory.
Standard application like http based web servers as well as M2M specific profiles like IPSO Application Framework can be built using Contiki. A system with full IPv6 networking and RPL routing can be deployed using less than 10 kB RAM and 30 kB Flash.
Figure 28 illustrates a high level block diagram of the firmware that can be developed for STM32W based systems using Contiki: the different colours highlight the various domains, the blue being the standard communication libraries (STM32W specific), the orange the Contiki- provided core (6LoWPAN and O.S.) and the green the application code, that depends on the use case and the purpose of the project.
Figure 28. Contiki based firmware on stm32w core
We plan to program the ST nodes of the WSAN by means of Contiki that has proven to be easy to use, very short rump up phase, and very robust. Being written in C it make easy to integrate existing previously developed code and the solid support of open networking standards makes easier the debugging phase too (nodes can be accessed by means of a regular browser, traffic can be sniffed by means of a dedicated node and a standard WireShark installation).
ClouT – 31.07.2013 Page 46
D2.1 - Reusable components, techniques and standards for the CIaaS
For further information please refer to the table in the appendix.
THINGSQUARE MIST
Thingsquare Mist is a new operative system based on Contiki (it actually includes a modified version) but with a more Cloud oriented approach. Major differences with regards to Contiki are the concept of sleepy wireless mesh network, to provide longer life to battery powered devices, the use of encrypted web sockets to “directly” (Thingsquare Mist supports a tiny edge router that can be deployed on a constrained node as well, providing Ethernet or Wi-Fi connectivity) interface the nodes with cloud services. It supports 2.4 GHz as well as sub-GHz band devices, like the SPIRIT1.
An online development environment, running in the cloud, is available as well: devices can be registered in and programmed from the cloud just using a regular web browser.
For further information please refer to the table in the appendix.
2.3. Abstracting IoT devices - Reusable components
In this section are listed all reusable objects, that can potentially be included in the ClouT Reference Architecture in terms of abstracting IoT devices.
COMMSERVER
The CommServer consists of a port multiplexer/demutiplexer, offering several virtual communication ports towards a one physical serial port. This translates into the fact that different applications can simultaneously transmit/receive data through a same physical port using different virtual ports associated to each of these applications. Next figure shows the functionality previously described:
ClouT – 31.07.2013 Page 47
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 29. CommServer Architecture
As it can be shown in the Figure 29, CommServer module is used for managing the Digimesh/802.15.4 communication interfaces (described in section 2.2) at a gateway level. In this sense, gateway nodes are in charge of gathering information associated to service, management and experimentation results (sent through Digimesh interface) and of behaving as an additional node (with high processing and memory skills), at native 802.15.4 level. Taking into consideration that different applications could be demanding data received by the same interface, CommServer is in charge of defining different virtual ports associated to each of the aforementioned applications, where data from corresponding physical interface is sent. As it can be observed in the figure, several EXP virtual ports are taking and injecting data from/in 802.15.4 interface, whilst several SER virtual ports and one for management called OTAP (use for managing data associated to remote flashing procedure), are taking and injecting data from/in Digimesh interface. This way, it can be easily managed an hybrid Digimesh/802.15.4 network, easily adding new platforms (i.e. Zigbee), as well as including new applications/services on top, through the creation of additional virtual ports.
For further information please refer to the table in the appendix.
MICROSOFT .NET GADGETEER
Microsoft .NET Gadgeteer is an open source rapid prototyping platform for small electronic gadgets and embedded hardware devices. The platform is built on the .NET Micro Framework, which allows small devices to be programmed in the C# language and make use of Visual Studio’s programming and debugging tools. The .NET Gadgeteer system is composed of a mainboard containing an embedded processor and a variety of modules which connect to the mainboard through a simple plug-and-play interface. The mainboard sockets can support one or more different types of modules. Multiple hardware makers have developed .NET Gadgeteer
ClouT – 31.07.2013 Page 48
D2.1 - Reusable components, techniques and standards for the CIaaS
compatible hardware. For example, GHI electronics is the first vender to offer a .NET Gadgeteer board, FEZ Spider.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 49
D2.1 - Reusable components, techniques and standards for the CIaaS
3. Virtualization and Hosting of City Resources
3.1. Introduction
In this chapter the focus is on defining and developing virtualization solutions that allow all kind of possible IoT devices to be accessed from cloud services, in the same way of any other data. Regarding to the virtualization aspects an open-source virtualization management application (oVirt) is presented. In addition, two examples of database (Xively and Nimbits) – that connect directly with sensors devices – are described. Finally, an international standard about the interface to access cloud storage and to manage the data stored within it, is reported.
3.2. Virtualization and hosting of legacy and IoT devices - Reusable components
In this section are listed all reusable objects, that can potentially be included in the ClouT Reference Architecture in terms of virtualization and hosting of legacy and IoT devices.
REMOTE NODE FLASHING
In order to remotely modify the behaviour of the nodes installed in the network, a mechanism for remotely flashing nodes over the air called MOTAP (Multihop Over The Air Programming) is implemented over Digimesh protocol layer. Associated to the flashing procedure, some additional functionality is also implemented:
Flash: As many codes as needed can be sent in unicast, multicast and broadcast way to nodes one or several hops away. All these codes will be stored in an external SD card.
Start: A specific code stored in the SD card can be loaded in a corresponding node, so the node starts to operate according to this code.
Reset: All nodes have stored in the SD card, a specific code called as Golden Image, which when executed, puts node at an accessible and reliable state. Reset command allows putting node in this default state.
List programs: This command allows knowing which programs are loaded within a certain node SD card.
Remove: In order to avoid having lots of programs (for instance older versions of certain code), a determined program can be easily removed using this command.
The aforementioned functionalities allow changing the nodes behaviour in an easy and remote way, thus providing network with a high flexibility, for adapting to the requirements associated to a determined service/application, such as sending parameters measurements with different format, changing transmission interval or pre-processing somehow information in the node before sending it. Apart from this, different experiments can be also loaded in the nodes, thus for
ClouT – 31.07.2013 Page 50
D2.1 - Reusable components, techniques and standards for the CIaaS
testing different routing protocols, data mining schemes, network coding algorithms or V2I (Vehicle to Infrastructure) communications, using 802.15.4 interface for this type of communications.
This protocol is implemented in Java on the server side and in C/C++ on the node side. The nodes on which the protocol has been implemented are waspmote nodes.
COSM/XIVELY
Cosm, now changed in Xively, is a Public Cloud for the Internet of Things. It allows connecting different private or public devices - like Arduino - with dedicated API keys and so to allow the User to put and get the data coming from a device: in addition it is possible to have simple access to them from the website with a smart phone, a tablet or a computer.
Figure 30. Cosm - Visualization of sent data
For further information please refer to the table in the appendix.
NIMBITS
Like Xively there is also Nimbits by Google: both can be used with the two devices to collect data, because they are all based on the same structure and logic. The data coming from the sensor are all processed and then sent to the Cloud's services through the SQL language. The data are all collected into storage, through a web page and afterwards they can be visualized on a personal device like a computer or a smart device (tablet or smart phone).
For further information please refer to the table in the appendix.
OVIRT
ClouT – 31.07.2013 Page 51
D2.1 - Reusable components, techniques and standards for the CIaaS
oVirt is an open-source virtualization management application, that allows the client, using an interface (named oVirt engine and shown in Figure 31), to manage hardware nodes, storage and network resources and to deploy and monitor virtual machines running on the data center4.
It is also better to choose a VM, instead of a simple dedicated machine as a server, because it is possible to use just a dedicated space of memory and optimize it to have the best performance of the VM. It is possible to make your own project using oVirt and simply access to the portal and it is possible to manage your virtual machine like it is shown on the following figure.
With this simple configuration, it is possible to implement a real IaaS, because oVirt permits an automatic migration to a node, if the connection of a VM goes down, without losing any data or information (no manual configuration is needed).
Figure 31. oVirt Engine
An example of VM can be with Centos and CouchDB installed; in this way it is possible to send a string through TCP/IP and store data on the NoSQL DB. It is really suggested to send data on this way and not to simply access a mySql DB, especially in case of many data (like in our project where we have about a ”terabyte torrent” coming from trillions of devices).
For further information please refer to the table in the appendix.
CDMI
4 Like oVirt there is also RHEV; the main difference is that it is needed a license to have the Red Hat support.
ClouT – 31.07.2013 Page 52
D2.1 - Reusable components, techniques and standards for the CIaaS
CDMI is an international standard about the interface to access cloud storage and to manage the data stored within it: it is important because provides a secure access, in fact allows the access only using a special command with a secure credential.
Figure 32. SNIA Cloud Interactions
Figure 32 has been extracted from the SNIA site (http://www.snia.org/cloud) and shows how the CDMI standard can be integrated into emerging cloud ecosystems. The CDMI standard does not replace existing cloud data access standards: this is an important aspect because permits to use CDMI both with existing and new clouds that store data via non-CDMI protocol.
In our case CDMI-proxy (a CDMI-complaint proxy server to public Cloud) can be taken in consideration. By default CDMI-Proxy opens two connections:
TLS on port 8080.
HTTP on port 2365.
Both of them require authentication, which can be modified in the configuration files. Moreover out of the box “user:cdmipass” (for HTTP-Digest) and “aaa:aaa” (for HTTP-Basic) are available.
It is possible to use your every day browser to read the contents of the CDMI-Storage (simply open http://URI_OF_CDMI_SERVER:port) or use “curl” line command for constructing a valid CDMI request. For example, to create a new container, the following commands can be run:
$ curl -v -u username:pass --digest \
-H 'x-cdmi-specification-version: 1.0.1' \
-H 'content-type: application/cdmi-container' \
-H 'accept:application/cdmi-container' \
ClouT – 31.07.2013 Page 53
D2.1 - Reusable components, techniques and standards for the CIaaS
-X PUT http://cdmiserver:2365/newcontainer
For further information please refer to the table in the appendix.
3.3. Sensorization and actuatorization of legacy devices and social networks - Reusable components
In this section are listed all reusable objects, that can potentially be included in the ClouT Reference Architecture in terms of sensorization and actuatorization of legacy devices and social networks.
DETECTION AND VISUALIZATION OF PLACE-TRIGGERED GEOTAGGED TWEETS
Recently, many related works address to detect real world events from social media such as Twitter. By leveraging social networks as sensor, we can detect various social events in the cities. However, geotagged tweets often contain noise, which means tweets which are not content-wise related to Users’ location. This noise is problem for detecting real world events. To address and solve the problem, we have been developed the Place-Triggered Geo- tagged Tweet, meaning tweets which have both geotag and content-based relation to Users’ location. Researchers at Keio University have designed and implemented a keyword-based matching technique to detect and classify place-triggered geotagged tweets. They have evaluated the performance of our method against a ground truth provided by 18 human classifiers, and achieved 82% accuracy.
The researchers designed filter modules that detect each selected type of place-triggered geotagged tweets. Each filter uses naive key- word matching method to detect the type of tweets, because they assume that people tend to classify tweets mainly by distinctive keywords. Approaches of each filter module are described below. First, they considered that the tweets from check-in services are the re- port of whereabouts. From the result of preliminary survey, most of the tweets which classified as the report of whereabouts were made using the check-in services. Many Users link their check-in service account to Twitter’s, so that they can acquire check-in activity from crawling Twitter. The filter estimates tweets to be a report of whereabouts, if the source information of tweets contains Foursquare, Loctouch, or Imakoko- now site URL.
The other filters: food, weather, back at home and earth- quake use a keyword matching method. As an example of keyword matching, we describe the food filter. First, the researchers created a list of synonyms of the keyword “food” using Weblio English thesaurus. If text of a tweet contains words in the synonyms list of food, the tweet is considered to be food type. In the same way, they make lists of synonyms of the other keywords. For the first step, they prepare synonyms of verb, noun and adjective for each filter. As a method of keyword matching, filters use regular expressions. The researchers also examined the possibility of morphological analysis, but decided to apply simple keyword matching method to avoid performance degradation due to object analysis. By increasing the pattern of keywords in the list of synonyms, they have confirmed the accuracy of determination equal to or better than if the
ClouT – 31.07.2013 Page 54
D2.1 - Reusable components, techniques and standards for the CIaaS
morphological analysis is used. Visualization applications are intended to assist in the detection of real world events with place-triggered geotagged tweets. Figure 33 shows system architecture for sensorization of social networks: so far, the researchers implemented prototype system and interactive interface for Users to visualize and find social event based on sensorized social network (see Figure 34).
Figure 33. System overview of sensorization of social network
Figure 34. Interactive visualization tool
For further information please refer to the table in the appendix.
SENSOR ANDREW
Sensor Andrew is a large-scale sensor and actuator platform which has been developed in Carnegie Mellon University. It uses XMPP server for publishing and subscribing sensor data. In XMPP server, there are two kinds of event nodes, meta event node and data event node. Meta event node takes responsibility to present meta information about sensor node, and data event node sends actual sensor data to subscribers. It also has actuation mechanism to various actuators such as light, sound and so on. Current Sensor Andrew was implemented by open source software called “ejabber”, so it is possible to extend Sensor Andrew features for this task.
ClouT – 31.07.2013 Page 55
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 35 shows overview of Sensor Andrew. It has two main actor, sensor node deployer and users who get the sensor data from Sensor Andrew. Deployer created two types of event nodes, data node and meta node. Once the deployer deploys these nodes, corresponded sensor node publish sensor information to the data node. Users who subscribe the event node can get sensor data through the corresponded data node by referring meta node to understand the types of sensors which are mounted on sensor nodes.
Figure 35. Overview of Sensor Andrew
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 56
D2.1 - Reusable components, techniques and standards for the CIaaS
4. Interoperable City Data
4.1. Introduction
Data interoperability is a common issue in all domains of computer science and has mainly two possible solutions:
Adopting a standard data model to ensure that all exchanged data fit into a common format and semantic.
Providing data adapters (or wrappers) to adapt/translate one data model to another. In the field of the “Internet of Things” (IoT) there are already many data standards proposed to deal with the interoperability problem. However, the solutions are in general domain specific (Home, Building, Transportation, Health, Energy, etc.), thus do not interoperate. More generic models have also been proposed such as SensorML, USDL, NGSI context model, Neo4j, etc., from many collaborative projects as well as standardization groups to achieve the interoperability goal.
This section lists the relevant existing technologies that can potentially be reused by the ClouT project in order to provide cross-application domain interoperability that will be make the ClouT system capable of cooperating with the solutions of different device vendors, service providers or application integrators. Besides providing a syntactic interoperability (which is the capacity of the system to communicate and exchange data), ClouT project aims also dealing with the semantic interoperability (the ability to interpret the exchanged information).
4.2. Syntactic interoperability across continents - Reusable components
In this section are listed all reusable objects, that can potentially be included in the ClouT Reference Architecture in terms of syntactic interoperability across continents.
NGSI CONTEXT MODEL
Context Information in OMA NGSI is represented through data structures called context elements which have associated: an Entity Id and an Entity Type, uniquely identifying the entity to which context data refers (see Figure 36). A sequence of one or more data element attributes (
As an example, we may consider the context element reporting info on: attributes “speed”, “geo- location”, “current established route” of a “car”, or attributes “last message geo-location”, “last message contents” of an “User”.
The Entity Id is a string, and can be used to designate “anything”, not necessarily “things” in the “real world” but also application entities.
ClouT – 31.07.2013 Page 57
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 36. Context information Model
The advantages of this conceptual model are:
Not linked to particular data/context representation formalism: Neither for transferring and nor storing.
Can work with a standard IoT formats (SensorML) but at the same time allows to overcome the limitations derived from the adoption of a single standard format.
The flexible nature of data structures linked to context elements enables an optimized communication (only information about queried or updated attributes is transferred).
A partial implementation of NGSI-10 interface, described in [NGSI10] and [NGSI API], has been realized by means of a wrapper on top of ContextML/CQL Context Broker. NGSI data structure has been modeled in JSON language, compliant to supplied xsd schema and NGSI specification. It should be noted that since NGSI and ContextML/CQL interfaces have a slightly different approach to context management, this implementation of NGSI functions undergoes some simplifications; here is a list of the ones related to context model, which applies to every method:
Attribute Domain and related metadata are not supported.
In Entity Id data structure the Pattern parameter is not supported.
In Context Attribute data structure the metadata Timestamp, Expires and Source are optional in input as required by specifications, but default values are introduced when context is retrieved.
The following figures represent examples of a request message in JSON/XML and ContextML (Please refer also to the figure “. Context Broker Functioning”):
a. Pub/Sub GE NGSI with JSON
ClouT – 31.07.2013 Page 58
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 37. JSON request example
b. Pub/Sub GE NGSI with XML
Figure 38. XML request example
c. Pub/Sub GE with ContextML/CQL
Figure 39. ContextML/CQL request example
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 59
D2.1 - Reusable components, techniques and standards for the CIaaS
FI-WARE PUBLISH/SUBSCRIBE CONTEXT BROKER
The Context Broker GE (FI-WARE PUB/SUB s.d.) enables publication of context information by entities, referred as Context Producers, so that published context information becomes available to other entities, referred as Context Consumers, which are interested in processing the published context information. The Context Broker GE supports two ways of communications: push and pull towards both the Context Producer and the Context Consumer. Push services follows publish/subscribe messaging.
Context Broker GE is an excellent bridge enabling external applications to manage events related to the Internet of the Things (IoT) in a simpler way hiding the complexity of gathering measurements from IoT resources (sensors) that might be distributed or involving access through multiple low-level communication protocols.
There are two similar context broker developed in FI-WARE: Publish/Subscribe Broker Called Orion Context Broker of Telefonica (TID) and Publish/Subscribe Broker - Context Awareness Platform of Telecom Italia called SAMSON. Figure 40 represents Context Broker functioning:
Figure 40. Context Broker Functioning
Orion provides the NGSI9 and NGSI10 interfaces. OMA NGSI-9 interface is a RESTful API via HTTP. Its purpose is to exchange information about the availability of context information while OMA NGSI 10 interface is a RESTful API via HTTP for exchanging context information. Using these interfaces, clients can do several operations:
Register context producer applications, e.g. a temperature sensor within a room.
Update context information, e.g. send updates of temperature.
Being notified when changes on context information take place (e.g. the temperature has changed) or with a given frequency (e.g. gets the temperature each minute).
Query context information. The Orion Context Broker stores context information updated from applications, so queries are resolved based on that information.
In SAMSON Broker, context information may be requested via two distinct APIs: REST like ContextML/CQL supporting very rich set or the requests and subscriptions and by RESTful FI-
ClouT – 31.07.2013 Page 60
D2.1 - Reusable components, techniques and standards for the CIaaS
WARE NGSI based on OMA standard. ContextML is used for the representation of the context information. In addition, CQL (context Query Language) is aligned with the concepts defined in ContextML and allows the execution of queries on the context model. In fact, one problem when dealing with context information is the semantic of used data. Some information is usually expressed differently by different Users as for example, position and location. Telecom Italia proposes a tool to integrate a semantic engine to the context broker. As the Figure 41 shows besides NGSO queries, semantic queries are supported. The context information is synchronized between the context broker and the semantic engine continuously.
Figure 41. Semantic Publish/Subscribe GE w NGSI
For further information please refer to the table in the appendix.
JSON
JSON (JavaScript Object Notation) is described in [JSON] and [RFC 4627]. It is a lightweight data- interchange format. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers. These properties make JSON an ideal data-interchange language. A format example is presented in the figure “. JSON request example”.
Because most JSON-formatted text is also syntactically legal JavaScript code, an easy way is to produce native objects rather than using a JSON-specific parser. For example, web browsers now either have or are working on native JSON encoding/decoding to increase security and performance. For example, Mozilla 4 (Native JSON s.d.) has full ECMAScript 5 support which allows a native JSON use. ECMAScript 5.1 is the latest edition of the standard upon which JavaScript is based, and was approved in June 2011. Thus, to convert a JSON string into a JavaScript object, you simply pass the JSON string into the JSON.parse() method, like this:varjsObject = JSON.parse(jsonString).
Unfortunately UBJSON [UBJSON], marshaling native programming language in and out of a text- based representation does have a measurable processing cost associated with it. In high- performance applications, avoiding the text-processing step of JSON can net big wins in both
ClouT – 31.07.2013 Page 61
D2.1 - Reusable components, techniques and standards for the CIaaS
processing time and size reduction of stored information, which is where a binary JSON format becomes helpful.
But, attempts to make using JSON faster through binary specifications like BSON, BJSON or Smile exist, but have been rejected from mass-adoption for two reasons:
1. Custom (Binary-Only) Data Types: Inclusion of custom data types that have no ancillary in the original JSON specification, leaving room for incompatibilities to exist as different implementations of the specification handle the binary-only data types differently. 2. Complexity: Some specifications provide higher performance or smaller representations at the cost of a much more complex specification, making implementations more difficult which can slow or block adoption. One of the key reasons JSON became as popular as it did was because of its ease of use.
Fortunately, while the Universal Binary JSON specification carriers these tenants of simplicity forward, it is also able to take advantage of optimized binary data structures that are (on average) 30% smaller than compacted JSON and specified for ultimate read performance; bringing simplicity, size and performance all together into a single specification that is 100% compatible with JSON. Also, UBJSON provides implementation libraries in Java, .NET, JavaScript, Python.
The Universal Binary JSON specification defines a total of 13 discrete value types all delimited in the binary file by a specific, 1-byte ASCII character (optionally) followed by a length and (optionally) a data payload containing the value data itself. For example:
{
"id":1234567890,
"name":"bob"
}
Storing that object in the Universal Binary JSON format would look like this (whitespace added for readability):
[o][2] 2 bytes
[s][2][id][I][1234567890] 4 + 5 = 9 bytes
[s][4][name][s][3][bob] 6 + 5 = 11 bytes
This Universal Binary JSON format is 22 bytes, 27% smaller than the compacted JSON.
JSON Storage
Json engine (JSON ENGINE s.d.) is a simple and ultra-scalable JSON storage that works on Google App Engine. You do not need any server-side Java/Python coding. Just deploy a Json engine to App Engine cloud as your application, and you can call the REST API from any HTTP client
ClouT – 31.07.2013 Page 62
D2.1 - Reusable components, techniques and standards for the CIaaS
(JavaScript, Flash, iPhone/iPad/Android or etc) to get/put/search any kind of JSON documents. For example:
POST /_je/myDoc?_doc={"name":"Foo","age":20} will save a doc on the data-store. It is also possible to use:
POST /_je/myDoc?name=Foo&age=20.
Json engine provides update conflict detection, as an optional feature. A client may set "_checkUpdatesAfter" parameter to the “_updatedAt” value of the client-side copy of the doc on POST/PUT/DELETE methods.
Then json engine will compare it with the _updatedAt property value of the doc stored in Json engine. If the latter is newer, it means some other client has updated the doc already and the client's doc is not the latest anymore.
Json engine will return “Status code 409 (Conflict)” without updating it so that client may get the latest doc again and let User retry the update.
In addition, the following properties are generated by Json engine automatically and client must not modify those values. You can use generated properties as a filtering or sorting condition on query.
_docId: unique ID of each doc.
_createdAt: long value of timestamp when the doc has been created.
_createdBy: User ID of the person created the doc.
_updatedAt: long value of timestamp when the doc has been updated.
_updatedBy: User ID of the person updated the doc.
For further information please refer to the table in the appendix.
4.3. Semantic Sensor Data Interoperability - Reusable components
In this section are listed all reusable objects, that can potentially be included in the ClouT Reference Architecture in terms of semantic sensor data interoperability.
SENSOR ML
Sensor Model Language (SensorML) is a forum standard specified in Open GeoSpatial Consortium (OGC). It provides a XML (eXtensible Markup Language) based format for descriptions of sensors and sensor systems, including data-types. The model and schema in SensorML provides a “skeletal” framework, so that it requires the definition of community-
ClouT – 31.07.2013 Page 63
D2.1 - Reusable components, techniques and standards for the CIaaS
specific semantics (within online dictionaries or ontologies) for realizing interoperability between various sensor communities. Currently SensorML 1.0.0 standardized in 2007 is the latest version; SensorML 2.0 is currently being standardized. According to the specification of SensorML, scope of the language is as follows:
Provide descriptions of sensors and sensor systems for inventory management.
Provide sensor and process information in support of resource and observation discovery.
Support the processing and analysis of the sensor observations.
Support the geo-location of observed values (measured data).
Provide performance characteristics (e.g., accuracy, threshold, etc.).
Provide an explicit description of the process by which an observation was obtained (i.e. lineage).
Provide an executable process chain for deriving new data products on demand (i.e. derivable observation).
Archive fundamental properties and assumptions regarding sensor systems.
From a viewpoint of data interoperability, this language is not designed for describing hardware design of sensors but for describing functional model of sensors. Especially, geo-location of sensors can be expressed flexibly. In addition, SensorML provides a rich collection of metadata such as identifiers, classifiers, constrains (time, legal, and security), capabilities, characteristics, contacts, and references, inputs and outputs parameters and location etc. These capabilities will be helpful to extracting ‘Semantics (=metadata)’ of sensor data from various sensors remotely located in the City. Figure 42 shows an example:
Figure 42. Example description of SensorML
ClouT – 31.07.2013 Page 64
D2.1 - Reusable components, techniques and standards for the CIaaS
Some useful tools are available associated with SensorML. SensorML data processing library and SensorML profile library are open source Java software libraries for processing SensorML which includes parser code ( https://code.google.com/p/sensorml-data-processing/). Pines SensorML Editor is open source editing tool for viewing, creating and modifying SensorML using tree- based view. (https://sites.google.com/site/lxspine/pine'ssensormleditor) Figure 43 shows a screen shot of the editor:
Figure 43. Pines SensorML Editor
For further information please refer to the table in the appendix.
SESAME
Sesame is a de-facto standard framework for processing Resource Description Framework (RDF) data. This includes parsing, storing, inferencing and querying of/over such data. It offers an easy-to-use API that can be connected to all leading RDF storage solutions. Sesame fully supports the SPARQL query language for expressive querying and offers transparent access to remote RDF repositories using the exact same API as for local access. Finally, Sesame supports all main stream RDF file formats, including RDF/XML, Turtle, N-Triples, TriG and TriX. It is implemented in Java and distributed under BSD type license.
Originally, Sesame was developed by Aduna (then known as Administrator) as a research prototype for the EU research project On-To-Knowledge. When this work ended in 2001, Aduna continued the development in cooperation with NLnet Foundation and a number of volunteer developers.
Figure 44 shows the major components and APIs of Sesame. At the bottom of the diagram are RDF Model and the foundation of the Sesame framework. It provides interfaces and implementation for all basic RDF entities, such as URI, blank node, literal and statements. The
ClouT – 31.07.2013 Page 65
D2.1 - Reusable components, techniques and standards for the CIaaS
Storage and Inference Layer (SAIL) API is a low level System API (SPI) for RDF stores and inferences. It abstracts storage details to allow using various type of storage.
The Repository API is a higher level API that offers a large number of methods for handling RDF data, such as uploading data files, querying, and extracting and manipulating data. There are several implementations of this API, the ones shown in this figure are the SailRepository and the HTTPRepository. The former translates calls to a SAIL implementation of choice, the latter offers transparent client-server communication with a Sesame server over HTTP.
At the top, there is the HTTP Server. It accommodates Java Servlets that implement a protocol for accessing Sesame repositories.
Figure 44. Sesame components
Figure 45 shows the class diagram of Sesame RDF Model. The RDF entities, which are Value, Literal, Resource, URI and BNode, are organized in inheritance relationship. Note that these are defined as ‘interface’, which allows multiple options for underlying implementation.
Figure 45. Class diagram of Sesame RDF Model
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 66
D2.1 - Reusable components, techniques and standards for the CIaaS
NEO4J
Neo4J is an open source graph database implemented in Java. Graphs are represented by nodes and their relationships. Graphs are useful for representing a wide diversity of datasets. Main features of Neo4J are:
Intuitive, using a graph model for data representation.
Reliable, with full ACID transactions.
Durable and fast, using a custom disk-based, native storage engine.
Massively scalable, up to several billion nodes/relationships/properties.
Highly-available, when distributed across multiple machines.
Expressive, with a powerful, human readable graph query language.
Fast, with a powerful traversal framework for high-speed graph queries.
Embeddable, with a few small jars.
Simple, accessible by a convenient REST interface or an object-oriented Java API.
Though Neo4J handles graphs with the proprietary data model, it is also possible to handle graphs in standardized way RDF with SPARQL by using a plug-in. Neo4J can be used in 2 ways; as an embedded library and as a server. In the server mode, client can access to the server through REST API. By federating multiple servers, it is possible to improve availability and scalability.
Figure 46. Neo4J example
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 67
D2.1 - Reusable components, techniques and standards for the CIaaS
5. City Resources Management
5.1. Introduction
This chapter deals with the higher level specifications of the IoT city backbone. It will be focused on services more than on raw sensor data provisioning. Standard based, large scale mechanisms to implement service discovery on the (possibly multi hop) wireless sensors network will be investigated and specified. The software running on the gateway will have to represent and manage the discovered services, and it will have to allow semantic search and (self-) management of the provided services.
5.2. Self-identification, self-discovery and self-binding of city services - Reusable components
In this section are listed all reusable objects, that can potentially be included in the ClouT Reference Architecture in terms of Self-identification, self-discovery and self-binding of city services.
SERVICE PROVISION GATEWAY
Taking into consideration the heterogeneity of the deployed network in terms of sensing capabilities associated to each device, as well as the different set of services offered by the platform, it is needed to automatically process the received information, gathering it in the corresponding database or forwarding it to the suitable entity. In this sense, this module is in charge of receiving the raw data sent by the different devices deployed in the network and forward it to a determined service.
This module is mainly composed of two entities: service proxy and service manager. Service proxy is in charge of taking the raw information associated to the different services, process them and sending it accordingly to the service manager. This module is composed of several instances (one for each service), such that raw information received from the service proxy is sent to the corresponding service instance. This way of functionality translates into an easy and straightforward inclusion of new applications/services in the platform.
ClouT – 31.07.2013 Page 68
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 47. Service provision gateway architecture
As it can be observed in Figure 47, information sent by the different IoT devices deployed is received by the service proxy. This raw information will be sent to the service manager, which will distribute it to its corresponding service entity, which will process the received information accordingly.
Service proxy and service manger have been programmed in Java, C and C++ language.
For further information please refer to the table in the appendix.
RESOURCE MANAGER
Taking into consideration the great amount of resources associated to the current massive IoT deployments, this entity is in charge to arbitrate different mechanisms in order to carry out the registration of new devices and to manage them accordingly (failure detection, attributes update). For this purpose, several blocks/modules can be identified:
Node Manager: This module is in charge of overhearing transmissions from IoT devices and gateways, thus allowing the discovery of new devices, as well as their corresponding management according to the messages sent and the interval among these transmissions. This information will feed the Event broker and the rest of entities within the resource management module.
Resource directory: It stands as a directory including the attributes (available sensing capabilities, location, type) associated to the resources offered by the deployed platform.
ClouT – 31.07.2013 Page 69
D2.1 - Reusable components, techniques and standards for the CIaaS
IoT Manager: This module is in charge of managing registration of new nodes to the network, as well as the maintenance of the corresponding timers and events for calculating the validity time of a node in the network through notification messages sent by nodes. Once determined the node status, the IoT Manager updates the Resource Directory accordingly, with the corresponding registration, deregistration or change of attributes of a determined node or set of nodes within the network.
Testbed manager configurator: This entity carries out the update of the testbed runtime module with the information retrieved by the IoT Manager, thus keeping corresponding testbed manager (one example of this component explained in the Deliverable 3.1 “Reusable Components and techniques for CPaaS”) updated with the available nodes to be managed (send commands, remotely flash).
IDAS configurator: Component in charge of updating IDAS platform, indicating new nodes as well as removed ones, in order to keep updated the set of nodes that are sending and storing measurements within IDAS platform.
Event broker: Component that manages all the events that take place related to the resource management within the network, mainly those implying registration/deregistration of nodes to/from the platform. This module interacts with IoT Manager, TR Configurator and IDAS Configurator.
Figure 48 shows the interaction among all modules composing the resource management module:
Figure 48. Resource manager architecture
As it can be derived from Figure 48, information provided by the node manager feeds the event broker, which interacts with IoT manager in order to access to the Resource Directory and update it accordingly. Apart from updating resource directory, event broker is also in charge of updating IDAS platform and testbed manager, through IDAS and TM configurator, respectively.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 70
D2.1 - Reusable components, techniques and standards for the CIaaS
KNOPFLERFISH
Knopflerfish is an open source implementation of OSGi (Open Services Gateway Initiative) framework that is a specification for a module system and service platform for the Java programming language.
Figure 49. OSGi components
The OSGi execution environment is the standard de facto for the software to be deployed for gateways. It implements a complete and dynamic component model: applications or components (bundles) can be remotely updated and uninstalled without requiring a reboot. Different applications share the same JVM. Its service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly.
The OSGi key benefits are:
Reliability
Large scale distribution
Wide range of devices
Collaborative environment.
The OSGi implements a service and component oriented system (see Figure 50):
Contract is separated from implementation.
Different implementations by different operators are possible (but sharing the same interfaces or contract).
They are dynamically discovered and bind.
So components are reusable and not coupled to implementation details.
ClouT – 31.07.2013 Page 71
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 50. OSGi service contract
The OSGi “applications” so called bundles, are basically JAVA jar archives equipped with a specific manifest. OSGi takes care, among other things, of the services dependencies resolution among the various bundles, and of the bundles life cycle.
The Life cycle (see Figure 51) layer adds bundles that can be remotely and dynamically installed, started, stopped, updated and uninstalled, this being fully protected by the security architecture.
Figure 51. OSGi Life Cycle
ClouT – 31.07.2013 Page 72
D2.1 - Reusable components, techniques and standards for the CIaaS
Use of Java language ensures ease of development and portability among different platform. The OSGi environment has proved to be very efficient and flexible to develop gateway software from the low level bundles, to interact with different type of networks, to the higher level ones, in charge of web services/RESTful API implementation. Knopflerfish is a simple yet powerful and easy to use OSGi implementation.
Typical s/w architecture for the Gateway to be implemented in the ClouT project can be as reported in Figure 52:
Figure 52. Generic gateway S/W architecture
The main purpose of this figure is to highlight the modular and layered design of the gateway firmware implemented in OSGi.
The JVM ensures the upper layers’ portability across different O.S.; on top of this, we run the OSGi container and the various bundles that implement the gateway firmware itself.
A lower layer is dedicated to networks access: we plan to have one bundle per each device technology (i.e. 6LoWPAN, Bluetooth, other legacy devices, …). These bundles will implement the different protocols/profiles/APIs. An “abstraction” layer will be in charge of hiding the lower layer details, allowing the upper layers to access the devices in a uniform and simple (as much as possible) way.
The yellow box is more speculative, as it will be part of the specification and development of the project, but we may foresee that we’ll need some bundles to implement a Resource Directory module (to expose the sensors/devices/services discovered in the network), a HTTP/CoAP proxy to access the devices for the WSAN from the Cloud and the external world. Some other bundles can be needed for instance to implement the data cache typical of a constrained resource network, in which the reliability and low delay are not generally granted.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 73
D2.1 - Reusable components, techniques and standards for the CIaaS
5.3. Universal service descriptions - Reusable components
In this section are listed all reusable objects, that can potentially be included in the ClouT Reference Architecture in terms of universal service descriptions.
UNIVERSAL SERVICE DESCRIPTION LANGUAGE
The aim of Universal Service Description Language (USDL) is to describe entities related to pervasive computing, including objects that provide digital services, spaces that contain the objects and humans who manage and/or use them. The major ideas to achieve that are:
Dividing the description into two parts (types and entities).
Enabling the description in XML-based human/machine readable documents.
Describing both type-specific and entity-specific information.
The separate description of types and entities is similar to the ideas of classes and instances in object-oriented programming. Type documents describe abstract functions of corresponding entities and do not contain any platform-specific information. Entity documents, on the other hand, describe the way the functions defined in a type are provided by a specific device. USDL allows types to inherit other types. Types are similar to Java interface definition in that they do not describe any implementation-specific issues, such as communication protocols and device identifiers used in services.
Figure 53. Types and Entities in USDL
The separate description of types and entities is similar to the ideas of classes and instances in object-oriented programming (see Figure 53). Type documents describe abstract functions of
ClouT – 31.07.2013 Page 74
D2.1 - Reusable components, techniques and standards for the CIaaS
corresponding entities, and do not contain any platform-specific information. For example, a television type could contain functions such as turn on, next channel, and get current channel. These operations would be common in most televisions, thus defined in this generic television type. Entity documents, on the other hand, describe how the functions defined in a type are provided by a specific device. Following enclosed document with an example from an UPnP television entity document that inherits the television type. Three of the seven operations in television are implemented in this entity:
Sample USDL Entity Document.docx
The major advantage of dividing the description into types and entities is that it enables two levels of service composition. First, users and applications can compose service entities, which enables users to consider entity-specific constraints (access controls, physical locations, etc) on service composition. This, however, is dependent on the place where the entities reside, as it is not portable among different places. Second, users and applications can compose service types, which enables users to postpone the decision of which entities to compose until they actually use the composition. This composition is then portable among places, while is not able to contain entity-specific constraints.
USDL allows types to inherit other types. For example, the networked television type would be a sub-type of a television type, which in turn is a sub-type of a generic device type. These types are similar to Java interface definition in that they do not describe any implementation-specific issues, such as communication protocols and device identifiers used in services. On the other hand, entity definitions describe such issues, as well as they inherit types. My television example shown above implements the networked television type, and describes implementation-specific issues using map tags.
For further information please refer to the table in the appendix.
ClouT – 31.07.2013 Page 75
D2.1 - Reusable components, techniques and standards for the CIaaS
6. Reusable CIaaS Assets from Cities
6.1. Introduction
In the previous chapters each partner, starting from his specific experience, described all possible reusable components (related to the different topic), candidate to be part of the ClouT Reference Architecture.
On the other hand, in this chapter cities assets are briefly described, taking a careful look to the infrastructure’s features (sensors and actuators networks, IoT devices, social data systems). The final objective is to understand the state of the infrastructure within the project’s pilot cities (Genova, Santander, Mitaka and Fujisawa), highlighting needs and possible improvements for the future.
6.2. Genova Reusable CIaaS Assets
The municipality of Genova uses an infrastructure called “RoadVisor” in order to manage mobility services. This infrastructure is composed by a console management system that collects data from several sensors, located on the municipality area. The platform is divided into different modules, as described in the follow.
Figure 54. Genova Road Visor
INFOPARK
ClouT – 31.07.2013 Page 76
D2.1 - Reusable components, techniques and standards for the CIaaS
Infopark is dedicated software to the supervision of occupancy of parking lots. The system manages 16 parking spaces and 16 poles indicator of the state where parking on each pole shows the status of one or more parking spaces, with special panels dedicated information.
The architecture of INFOPARK is composed by two distinct layers which are interconnected via a communication network:
The peripheral level, consisting of poles and panels (video message systems) for the reporting of available parking spaces and sensors to acquire data.
The central level, where a server system acquires data from the parking areas and processes them for later viewing of poles and panels.
A dedicated network allows the connection between central and peripheral level.
Figure 55. Infopark in Genova
ClouT – 31.07.2013 Page 77
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 56. Infopark map
Figure 56 shows the information returned from the server for each Parking Area. The information are:
Latitude of the Parking Area
Longitude of the Parking Area
The name of the Parking Area
The unique identifier of the Parking Area
The total space capacity of the Parking Area
The total space capacity for mobility impaired
A flag indicating if the Parking Area has toilets for mobility impaired people
The distance from the Parking Area to the User
The real time capacity of the Parking Area
The tariff of the Parking Area
A flag indicating if the Parking Area has toilets
A code indicating the kind of Parking Area (openspace, roadside, covered, etc.).
ClouT – 31.07.2013 Page 78
D2.1 - Reusable components, techniques and standards for the CIaaS
ACITRAFF
The architecture provides a central system and a peripheral sensor-based infrastructure:
The peripheral level includes all of the equipment and sensors dedicated to the recognition of traffic data (18 data concentrators and 54 Sensors). The stations also ensure communication with the central monitoring station, mainly for setting mode of operation and execution of the measurement campaigns and the transmission of traffic data and diagnostics, also relating to the field sensors.
The central system is the level of access, where are located all the functionality of storing data acquired by the peripheral devices, the configuration functions of the peripheral stations and sensors connected to this, the definition of procedures for storage and archiving data, as well as management and maintenance of the system, including all further processing allowed by BI modules of the RoadVisor.
Figure 57. Acitraff
The Figure 57 shows the results obtained from the Acitraff module that can be used to create Infomobility services:
The name of the Traffic Segment
The level of congestion of the Traffic Segment according to four levels Red, Orange, Yellow, Green
The unique identifier of the Traffic Segment.
TRAFFIC CAMERA SYSTEM
The Traffic Webcam System is composed by about 25 webcams, located on the municipality territory. This infrastructure will be integrated with new webcams during the next years.
ClouT – 31.07.2013 Page 79
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 58. Traffic Camera System
Figure 58 shows the response from the RoadVisor Server:
The response is composed by an array of WebCam objects.
The Webcam are updated every five seconds.
ClouT – 31.07.2013 Page 80
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 59. Examples of camera images
WEATHER SENSORS
The Weather Sensors installed in collaboration with civil protection can export a series of detailed information about the temperature, the humidity level, and weather in general, for more than twenty areas of the Municipality.
The output will be HTML or WAP. The data are updated every five minutes.
Figure 60. Weather System
ClouT – 31.07.2013 Page 81
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 60 shows the possibility of using data acquired from the Wheater Station in order to create thematic maps.
6.3. Santander Reusable CIaaS Assets
The Santander testbed is currently composed of around 3000 IEEE 802.15.4 devices, 200 devices including GPS/GPRS capabilities and 2000 joint RFID tag/QR code labels deployed both at static locations (streetlamps, facades, bus stops) as well as on-board of public vehicles (buses, taxis).
Figure 61. Whole IoT nodes deployment in the city of Santander
Figure 61 shows the whole deployment in the city of Santander, including different static nodes, such as environmental sensors (temperature, noise, luminosity), parking sensor nodes, parks and gardens irrigation sensors (air temperature and humidity, soil moisture and temperature), traffic sensors (road occupancy, number of vehicles, speed); and mobile nodes measuring specific environmental parameters (CO, NO2, Ozone, Microscope particles). In the next sections, specific deployments are described in detail.
FIXED ENVIRONMENTAL NODES
Around 2000 IoT devices (mainly waspmote nodes) installed (mainly at the city center), at streetlights, facades provide measurements on different environmental parameters, such as temperature, CO, noise, and light). Environmental sensor nodes are deployed into repeaters nodes that server not only as measuring ones but also as communication component to carry the data until the nearest Gateway. The received information is stored and processed in the gateway,
ClouT – 31.07.2013 Page 82
D2.1 - Reusable components, techniques and standards for the CIaaS
in order to be used by different applications running over it, both in a local way or accessing from Internet through the SmartSantander backbone. Nodes are also classified in clusters, being a cluster the set of IoT nodes and repeaters that are associated to a determined gateway.
Figure 62. Detail of fixed environmental nodes
Figure 62 shows the repeaters installed in lamp posts (top part) and facades (bottom part) of the city, being equipped with two antennas associated to two independent 802.15.4 radio interfaces, one running Digimesh and other one native 802.15.4.
MOBILE ENVIRONMENTAL NODES
As previously indicated, more than 2,000 environmental monitoring sensors are deployed on Santander city, as a static deployment for monitoring environmental information. Although this deployment is very representative as it is located at the Santander city centre, it was considered necessary to extend the Environmental Monitoring service to other areas of the city. Hence, instead of continuing with fixed deployments all over the city, the additional hardware was deployed on municipal public buses, taxis and parks and gardens management vehicles, reaching the amount of 150 equipped vehicles. In This way, it is easier from the municipality to cover a much wider area on a much more efficient way.
ClouT – 31.07.2013 Page 83
D2.1 - Reusable components, techniques and standards for the CIaaS
The architecture deployed on vehicles divides in several parts:
1. Sensors Board: Responsible for sensing the corresponding environmental parameters (temperature, humidity, CO, PM10, O3, NO2), sending these values through a serial port to a local processing unit.
2. CANBUS module: This module is in charge of measuring main parameters associated to the vehicle (GPS position, altitude, speed, course and odometer), sending them to the local processing unit.
3. Waspmote board: For this use case, nodes similar to those already deployed in fixed deployment (waspmote nodes) have been installed. For this case, waspmotes are only provided with the 802.15.4 interface for experimentation issues, as service-related information and network management data is transmitted by the local processing unit.
4. Local processing unit (LPU): This unit, called CLV, is in charge of managing the service provision (data retrieved from sensor board and CANBUS module), experimentation (sending the log messages generated by 802.15.4 interface) and network management (OTAP procedures, transmission/reception of commands).
5. Gateway for mobile nodes (GWM): Equipment with high capacity in terms of computational power and memory which is in charge of gathering and processing all the information sent from the LPUs, just storing the information in the central server.
All the buses are provided with a sensor board, a CANBUS module, an IoT device and an LPU, whilst in each taxi and parks and gardens management vehicle only a sensor board and an LPU will be installed (no native experimentation allowed at taxis and police cars).
Figure 63. Detail of Mobile environmental nodes installation
Figure 63 shows a detail of the nodes installed in the public buses, on the left hand, they can be observed on the top of the roof all parts regarding to the sensing capabilities and the waspmote 802.15.4 board, whilst in the right hand, installation of LPU and CAN-Bus module under the roof of the bus, can be observed.
OUTDOOR PARKING NODES
ClouT – 31.07.2013 Page 84
D2.1 - Reusable components, techniques and standards for the CIaaS
Almost 400 parking sensors (based on ferromagnetic technology), buried under the asphalt have been installed at the main parking areas of the city center, in order to detect parking sites availability in these zones.
Figure 64. Outdoor parking nodes
As shown in Figure 64, Outdoor parking management uses pretty the same infrastructure described in Fixed Environmental Nodes, where several parking sensors (IoT nodes) provided with one transceiver (running the Digimesh protocol) send their parking state (free or occupied), to the corresponding gateway through the repeaters placed at the streetlights. The received information is stored and processed in the gateway, in order to be used by different applications running over it, both in a local way or accessing from Internet through the SmartSantander backbone.
Figure 65. Detail of parking sensors
ClouT – 31.07.2013 Page 85
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 65 shows a detail of the parking sensors installed at several zones of the city. As it can be observe, nodes are buried into the asphalt, using the corresponding IP67 capsule to protect them mainly from water, putting over them an asphalt thin layer.
TRAFFIC INTENSITY NODES
Around 60 devices located at the main entrances of the city of Santander are deployed to measure main traffic parameters, such as traffic volumes, road occupancy, vehicle speed or queue length.
Nowadays, the measure and classification of vehicles in road traffic is accomplished by inductive loops placed under the pavement. These inductive loops allow monitoring vehicle passing by means of different configurations which provide us a number of data in order to control several parameters of the traffic (vehicle speed, traffic congestion, traffic accidents).
However, these systems have several problems and disadvantages like their deployment, maintenance, high cost, and put into gear, among others. In this sense, within the SmartSantander project a solution based on sensors buried under the asphalt has been deployed to control traffic parameters at main entrances of the city of Santander.
The architecture deployed divides in three parts:
Traffic Sensor: Buried under the asphalt, they are accountable for sensing the corresponding traffic parameters (traffic volumes, road occupancy, vehicle speed, queue length), sending these values through an 802.15.4 interface to the indicated repeaters, using the ISM frequency band of 8686 MHz and through a proprietary routing protocol.
Repeater: This module is in charge of forwarding the measurements retrieved from the traffic nodes, making it available to the corresponding Gateway.
Gateway: Both traffic sensors and repeaters, are configured to send all the information to the access point. Once information is received by this node, it can either store it in a database which can be placed in a web server to be directly accessed from internet, or send it to another machine (central server), through the different interfaces provided by it (GPRS/UMTS or Ethernet).
ClouT – 31.07.2013 Page 86
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 66. Detail of traffic intensity nodes
As shown in Figure 66, traffic nodes are installed in a similar way to parking nodes, thus burying them in the asphalt and covering them with a specific epoxy. It is important to highlight, that for measuring values such as road occupancy one sensor per lane is enough, whilst for vehicle speed measurements two sensors per lane are needed.
PARKING LOTS PANELS
Taking information retrieved by the deployed parking sensors, 10 panels located at the main streets intersections have been installed in order to guide drivers towards the available free parking lots.
The architecture deployed divides in two parts:
1. Panel: According to the information received from the Central Station, the panel will show two displays. One with the number of places available in a determined parking zone and the other one with the sites availability in the whole area to be covered (see Figure 67).
2. Central Station: It receives, from the Portal Server, all data retrieved by the sensors already deployed to detect parking lots availability, thus processing it accordingly and transmitting the suitable information to the corresponding panel. In addition to the reception of information about parking sites occupancy, Central Station also sends incidences and other data related to the gathered information.
ClouT – 31.07.2013 Page 87
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 67. Parking lots panels
Figure 67 illustrates an installed panel. These panels are provided with a multicolor LED display (green/red/amber) and a 120 mm digit height alphanumeric, assuring a reading distance up to 50 meters. Panels must have uninterruptible power supply (220 V), although they are also equipped with a UPS (Uninterruptible Power Supply) to protect against small outages (30 minutes). Furthermore, panels are provided with an IP67 protection and a GPRS connection for transmitting/receiving information.
PARKS AND GARDENS IRRIGATION
Around 50 devices have been deployed in two green zones of the city, to monitor irrigation- related parameters, such as moisture temperature and humidity, pluviometer, anemometer, in order to make irrigation as efficient as possible.
In order to control and make it more efficient the irrigation in certain parks and gardens within the city of Santander, several type of sensors are installed in order to firstly monitor then evaluate the current situation and finally act over the irrigation systems making it more efficient the use of water. For this purpose, the following types of sensors are deployed:
Environmental sensors: Anemometer, pluviometer, atmospheric pressure, solar radiation, air humidity and temperature sensors.
Agriculture sensors: Soil temperature and humidity sensors.
Water sensors: Evaluation of water consumption sensor.
ClouT – 31.07.2013 Page 88
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 68. Detail of agriculture sensor
Figure 68 shows the detail of an agriculture node, where soil moisture and temperature sensors are covered with a specific housing to protect them and they are connected to the communication module through a wire.
AUGMENTED REALITY
In the majority of cities there is a huge amount of information that may be of interest for tourists and citizens but which is not readily accessible because it is so disperse. To avoid that, this service/application unifies the way to access all data sources and presenting them in a context- sensitive, location-aware manner to the end users using AR technology.
Figure 69. SmartSantanderAR application screenshots
The AR service (developed within the SmartSantander project) includes information about more than 2700 places in the city of Santander, classified in different categories: beaches, parks and gardens, monuments, buildings, tourist information offices, shops, art galleries, libraries, bus stops, taxi ranks, bicycle hire points, parking lots and sports centres, as shown in Figure 69. Furthermore, it allows real-time access to traffic and beach cameras, weather reports and forecasts, public bus information and bike hire service, generating a unique ecosystem for end users when moving around the city.
ClouT – 31.07.2013 Page 89
D2.1 - Reusable components, techniques and standards for the CIaaS
As an illustration of the type of service supported by the SmartSantanderRA application, it offers an interactive experience through its “stroll in the city” mode. With the application in this mode, visitors will receive information about specific Points Of Interest (POIs) taking into account their preferences as they stroll around the city. This, in general, enhances the serendipity effect for the application end user. In this sense, they can define their own preferences (language, places to visit, etc.) and have an interactive context-sensitive experience visiting the city, rather than using traditional standalone applications.
Figure 70. QR code/NFC tag stickers
The deployment of stickers (around 2000) including QR codes and NFC tags in strategic places in the urban landscape, see Figure 70, will provide location-sensitive information (transport service, the cultural agenda, shops, monuments, buildings). These stickers link visitors and citizens to the same information included in the AR Service. Additionally, it complements the SmartSantanderAR app, providing precise information about specific POIs, and according to the number of readings of these codes they can be inferred anonymous tendency and movement patterns of the users.
SmartSantanderAR application has been developed for Android and IoS platforms having been downloaded for around 14,000 users.
PARTICIPATORY SENSING
Participatory Sensing service, see application appearance in aims at exploiting the use of citizens’ smartphones to make people become active in observations and data contribution. In this scenario citizens, Santander City Council and the local newspaper “El Diario Montañés” are connected into a common platform where they can report, share and be notified of events happening in the city. As an example, a user walking in the city centre who finds a hole in the pavement can take a picture, write a text and finally share this incidence with other users of the application. The Santander City Council will therefore be notified of the occurrence of the event and proceed accordingly by sending an employee to the location in order to fix this problem.
ClouT – 31.07.2013 Page 90
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 71. Participatory sensing application screenshots
As well as sharing these social-related events, this application periodically samples the values sensed by the smartphones, such as GPS location, acceleration, temperature, humidity, etc. This information is fed into our platform periodically and can be very valuable in the development of new and innovative services.
Participatory Sensing application has been developed for Android and IoS platforms having been downloaded for around 5,000 users.
GATEWAYS NODES
Around 20 Meshlium devices are deployed in the City and are in charge of gathering information of IoT nodes and sending it to the Smart City Platform and to the Portal Server. These devices have several ways of transmission, including WiFi, GPRS, Ethernet. For assuring the transmission of data in a reliable and transparent way, the aforementioned Digimesh-enabled network is used.
To give support to the experimentation purposes this nodes have also the capability to create two parallel communication networks, one through a Digimesh interface for real data and one through native 802.15.4 interface for experimentation data. This node uses also the CommServer module already defined in previous chapter.
BLADE VIRTUALIZATION CLUSTER
Data process Center of Santander City Council is provided with a Virtualization Cluster running on HP Proliant Hardware. This cluster is composed by three nodes, each one provided with 98 GB of RAM, 2 Processor with 6 cores per processor and auxiliary virtualization storage system of 10 TB running on HP Lefthand Hardware.
For virtualization Purposes we are running a VMWare technology on top of this cluster, currently supporting 74 virtual servers and covering 65% of actual Santander City Council computational requirements. Figure 72 shows an informed a simplified diagram of this Cluster from an IT staff point of view:
ClouT – 31.07.2013 Page 91
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 72. Blade Virtualization Cluster
This platform allows Santander City Council to achieve some important benefits:
Decrease up to 50 % power consumption.
Decrease drastically server’s maintenance.
Improve service time for Users and applications, through technologies like vMotion, that allow server shutdown, without interrupt this kind of services.
Improve dynamic distribution of resources through technologies like DRS.
Scale Infrastructure from a dynamic and agile manner, accordingly to each moment needs.
Speed up the deployment and management of both physical and virtual servers, with auto-deployment features.
Ease backup of servers, concretely his management and automation.
Improve knowledge and management of server infrastructure, his inventory and performance of every component, everything from a single management tool.
This is a core asset for Santander, because most of platforms reused in this project will be running on top of this Cluster.
ClouT – 31.07.2013 Page 92
D2.1 - Reusable components, techniques and standards for the CIaaS
EVA STORAGE SYSTEM
Santander City Council Data process center is also provided with an array Storage System deployed on HP EVA Hardware. This storage system offers high performance, high availability, and robust data protection, thus a 25 TB of gross Capacity, and actually a net capacity of 10 GB.
EVA is composed of 104 5-inch disk drives, mainly on Ultra Wide SCSI specification, but also with SATA and FATA specifications, so this variety allows us to assign specific resources according to the each Service requirements. The EVA is connected with the Switches through a 2 GB/s Fiberdata bus.
With this system our Data Process Center is free of stranded capacity issues. EVA uses all the disks to send and retrieve data and can dynamically expand virtual disks as data grows.
EVA is equipped with replication features that improve data availability and reliability. This system brings the capacity to make hot swaps when a disk fails.
EVA is a core asset in Santander Data Process Center so any system that needs to persist any data must be supported by this component. Most important supported services are File Servers, Database Servers, Multimedia Servers and Application Servers.
Figure 73. Eva Storage System
GIS SYSTEM
Another useful asset for this project could be the Santander City Council GIS System. Actually this System is used to store and process all Geo-referenced data managed by Municipality
ClouT – 31.07.2013 Page 93
D2.1 - Reusable components, techniques and standards for the CIaaS
services. Some of this data is valuable for this project as, for example, Bus Stops, Police Incidences.
The system is deployed on a Physical Server due to manufacturer specifications. The Server is equipped with 2 Processors with 2 cores each one, 8GB of RAM and runs Windows Server operating system. Also this server is supported by the EVA storage System and Database Cluster. Figure 74 illustrates an overview of the complete Gis Platform:
Figure 74. GIS System
DATABASE CLUSTER
A Cluster of Servers is deployed on Santander Council Data process Center and is used to support several RDBMS Platforms required by Municipality Data processing. This cluster is formed by Oracle Database, Microsoft Sql Server and MySql platforms.
Most of these platforms are running on the Blade Virtualization Cluster, but concretely the Oracle Platform is running on his own hardware made by 2 Proliant nodes, with 2 processor and 2 cores per processor and is equipped with 4GB of RAM. The Oracle one is the main RDBMS Municipality system and manages actually near 1,5TB of data. This system runs on Red Hat Linux operative system and uses Oracle RAC to provide clustering and high availability environment.
ClouT – 31.07.2013 Page 94
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 75. Database Cluster
Database Cluster (shown in Figure 75) is actually supporting some components that will be reused in this project.
CITY FIBER NETWORK
Santander City Council has been, in the last years, investing in the deployment of optic fiber network across the City. This action has enabled the City to connect his entire municipality Offices, through his own 1 GB high speed network, and ease a technological progress of all City Facilities and Services.
Actually Santander Network is deployed on a Star Topology (as shown in Figure 76), although Municipality continues making investments and efforts to reach in sort-term, a ring topology, with redundant paths between Municipality Offices.
In Edge offices are placed access Switch, and in the Star center Office in concentrated core and distribution functions, managed by two nodes.
ClouT – 31.07.2013 Page 95
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 76. City Fiber Network
SmartSantander project and derivate, are actually using this infrastructure, giving hundreds of sensors and associated gateways nodes, a way to route data to SmartSantander City Platform. In this way, we have to remark that, despite of sharing infrastructure, this node uses an isolated communication channel, for security and reliability purposes.
Also, those offices that cannot be reached with own Santander optic fiber network, there are hired connection points that allow extending the network to reach a full City coverage.
Santander City Network allows furthermore establishing access controls, and authentication policies to the network, discovering, inventory and locking mechanisms to connected devices, enabling a secured and controlled environment from connection points.
6.4. Fujisawa Reusable CIaaS Assets
INFORMATION SHARING SYSTEM
Fujisawa has several information resources such as Twitter (see Figure 77), Facebook or e-mail magazines. The information systems are already leveraged for announcing public information to the citizens. Though network capability is not available, Fujisawa has several sensors in the city such as temperature, air pollution, or vibration sensor; and some of the cameras (see Figure 78) in Fujisawa publish video data in the Internet through web page. Fujisawa also has been deployed digital signage system in cooperation with Keio University for research purpose.
ClouT – 31.07.2013 Page 96
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 77. Twitter Account for Fujisawa City Emergence Management
Figure 78. Live Camera for Enoshima-Island in Fujisawa
LEGACY ENVIRONMENTAL SENSORS
Fujisawa city has several environmental sensors in several places. In addition to popular sensor such as temperature and humidity, Fujisawa has other kinds of sensors such as air and water pollution sensors, or noisy sound sensor (see Figure 79). Sensor data from popular sensors (e.g., temperature) is provided to several weather service organizations; although it is still not easily accessed directly for everybody. In addition, other kinds of sensors are not connected to network, so connecting and sharing them among many people/services would be one of challenges in ClouT Project.
ClouT – 31.07.2013 Page 97
D2.1 - Reusable components, techniques and standards for the CIaaS
Figure 79. Air pollution sensor map in Fujisawa
6.5. Mitaka Reusable CIaaS Assets
INFORMATION SHARING SYSTEMS
Mitaka city provides various kind of information using cloud service and on-promise system. It includes twitter, Facebook, mailing list, SNS. Next figure shows official twitter page of Mitaka city (@mitaka_tokyo, see Figure 80). It has established 11th March 2011, at the day of “The 2011 off the Pacific coast of Tohoku Earthquake” for providing information in chaotic condition. Since then it reports mainly the Tohoku Earthquake related information and radioactive measurement in the city periodically.
Figure 80. Twitter account for Mitaka city
ClouT – 31.07.2013 Page 98
D2.1 - Reusable components, techniques and standards for the CIaaS
Following figures show the twitter page for ‘Mitaka city tourist agency’ (@mitakann, see Figure 81). It provides information for mainly tourist, for example, the famous ‘GHIBLI museum’ and popular public bath:
Figure 81. Twitter account for Mitaka city tourist agency
The SNS site (shown in Figure 84) is dedicated for Mitaka citizen, for promoting information exchange among citizens. It accommodates various groups with same interest, called ‘Circles’, e.g. child-raising, movies, music, agriculture and so on. Major circle has more than 2000 members.
Figure 82. SNS page for Mitaka citizen
ClouT – 31.07.2013 Page 99
D2.1 - Reusable components, techniques and standards for the CIaaS
The mayor of Mitaka city issues mailing list combines the Mayor’s message and column with other city information. Mitaka city has also another mailing list for providing security information including criminal related children, emergent information, fire incidents and solved incidents.
Mitaka Tourist Information center has a Facebook account for providing information about city events. Album page provides a lot of pictures and movies taken in Mitaka city. They are linked with map, so that the information is helpful for sight-seeing.
Figure 83. Facebook page of Mitaka Tourist Information Center
Figure 84. Pictures and movies of Mitaka
ClouT – 31.07.2013 Page 100
D2.1 - Reusable components, techniques and standards for the CIaaS
7. Conclusions
In the previous chapters some components (hardware and software), tools, standards and available assets from cities were described, in order to have a list of objects to reuse into building the CIaaS layer for the ClouT Reference Architecture.
As mentioned in the introduction of this document, each chapter has been dedicated to a specific topic (regarding to the Infrastructure layer); for each topic one or more reusable objects have been identified, as shown in the following schema:
This deliverable will serve as starting point for the definition of ClouT Reference Architecture, in particular for the Infrastructure level: from this document will be choose all components to reuse, taking care to all advantages and costs for each single object.
In the next sections conclusions about each chapter are presented.
7.1. IoT Kernel
In the Chapter 2 five classes of reusable components come up:
ClouT – 31.07.2013 Page 101
D2.1 - Reusable components, techniques and standards for the CIaaS
Hardware platforms to be used as sensor/actuators or gateway systems (MBXXX boards, STEVAL-IDZ401V1, STEVAL-IHP004V1, SPIRIT1/STM32L1 BASED platforms, SPEAr320, Microsoft .NET Gadgeteer, Arduino, Raspberry, Waspmote and Meshlium).
Operative systems/firmware (STLinux O.S., CONTIKI O.S., THINGSQUARE MIST).
Communication standards and protocols (802.15.4, DIGIMESH, GPRS, CoAP, MQTT).
Models and enablers from other projects (IoT-A models, FI-WARE IoT Protocol Adapter).
Reusable utility software and libraries (Commserver).
As expected, this section identifies the lower level components on top of which the higher levels of the ClouT solution will be built: different hardware platforms, running different operative system or programmed with firmware written in different languages will cooperate using common communication protocols or proper abstraction layers developed at gateway level.
7.2. Virtualization and Hosting
In the Chapter 3, three classes of reusable components were illustrated:
Xively and Nimbits, as an example of existing Cloud storage for the Internet of Things.
oVirt, as a system for the Virtual Machine management.
CDMI, as a standard for a secure access to the data storage.
The most of presented components have the advantage to be Open Source. Xively and Nimbits are Public Clouds for the Internet of Things that allow connecting different private or public devices with dedicated API keys, so to allow the User to put and get the data coming from a device, and having simple access to them from the website with a Smartphone, a tablet or a computer. oVirt can provide a real IaaS building different Virtual Machine as a Server.
7.3. Interoperable City Data
In the Chapter 4 - Interoperable City Data – three classes of components have been identified:
Description of device data (JSON, NGSI Context model, SensorML).
Storing device data (Sesame, Neo4J).
Processing device data (Sesame, FI-WARE pub/sub).
Each class can again be classified according to the management of semantic issues. For instance, while JSON provides a format to describe the devices data in a semi-structured way (without semantics), SensorML provides ways of including semantic information by following the semantic web concepts. Similarly FI-WARE pub/sub enabler does not deal with the data semantics while Sesame and Neo4j can take into account the semantic relationships between described datasets. As a consequence, the interoperable data management components that will be reused in the ClouT system will depend on the application requirements on managing semantic issues. While opting for simplicity, the chosen components should be sufficiently extensible and expressive in order to include semantic management of information when
ClouT – 31.07.2013 Page 102
D2.1 - Reusable components, techniques and standards for the CIaaS
necessary. For instance JSON can be extended to include semantic information as described in JSON-LD (http://json-ld.org/). Neo4j seems also a good choice for managing large number of linked data, which will be the case in city environments that we are targeting.
Another criterion for choosing the components is the availability of stable versions and developer support that we can have during the lifetime of the project. In this sense, the FI-WARE enablers should be revised with the latest version information at the moment of the decisions. We will in addition be based as much as possible on open source solutions in order to avoid any license and PIR related problems.
7.4. City Resource Management
Chapter 5 - City Resource Management - identifies higher level blocks compared to the IoT Kernel one:
Generic Gateway Application framework like Knopflerfish (OSGi container).
Service data management framework (Service Provision Gateway).
Infrastructure management module (Resource manager) for high scale deployments
High level, object oriented language (Universal service description language) to describe the services offered by the underlying devices.
The next steps of this task will be to determine how to harmonize these modules and how to make the best use of their potentiality, for instance which parts of the system can be developed in OSGi and for which devices we may reuse the proposed modules.
7.5. Reusable Cities Assets
Finally, in the last Chapter 6 a set of further existing assets were described. They have been extracted from ClouT pilot cities: Genova (Italy), Santander (Spain), Mitaka (Japan) and Fujisawa (Japan).
This cities’ assets overview is useful to understand current situation in existing infrastructures, exploiting and improving them. Inspiring to these assets we are starting to implement a prototype that will evolve in the future during the project lifetime: it will be useful to test one or more of presented objects, in order to decide the better component to use in the ClouT Reference Architecture.
ClouT – 31.07.2013 Page 103
D2.1 - Reusable components, techniques and standards for the CIaaS
8. Appendix
8.1. IoT Kernel - Reusable Components
Following all tables with details for reusable components introduced in Chapter 2:
TABLE 4. DIGIMESH/GPRS-BASED SERVICE ARCHITECTURE
Proposing Partner UC
Info Name Digimesh/GPRS-based service architecture Owner(s) SmartSantander Consortium http://www.smartsantander.eu/downloads/2ndOpenCall/Full_Call_Text_Sm Link to code artSantander_Open_Call_2_def.pdf Project, plus link http://www.smartsantander.eu ID Card ID Patents or other IPR exploitation (licenses) To be determined. Digimesh is a proprietary peer-to-peer networking protocol for use in Description wireless end-point connectivity solutions. Type Communication protocol Programming
language/based technologies Routing protocol built on 802.15.4 protocol.
Exposed APIs Anatomy Target User(s) Network manager References http://www.digi.com/technology/digimesh/
Adopted Standard(s) IEEE 802.15.4 Capabilities /Opportunities Bidirectional trustworthy communication Easy addition of additional nodes to the network. Known Limitations/Threats Limited number of hops between gateway and IoT node. Assessment Limited transmission power and coverage area.
ClouT – 31.07.2013 Page 104
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 5. 802.15.4-BASED EXPERIMENTAL ARCHITECTURE
Proposing Partner UC
Info Name 802.15.4-based experimental architecture Owner(s) SmartSantander Consortium http:w//www.smartsantander.eu/downloads/2ndOpenCall/Full_Call_Text_S Link to code martSantander_Open_Call_2_def.pdf Project, plus link http://www.smartsantander.eu ID Card ID Patents or other IPR exploitation (licenses) To be determined. 802.15.4 is the most widely used standard for Wireless Sensor Networks Description communications. Type Communication protocol Programming language/based
technologies
Exposed APIs Anatomy Target User(s) Network manager/Researcher References
Adopted Standard(s) IEEE 802.15.4 Capabilities /Opportunities Easy inclusion of additional nodes (providing a native 802.15.4 interface) to the network.
Assessment Known Limitations/Threats No routing protocol implemented. Limited transmission power and coverage area.
ClouT – 31.07.2013 Page 105
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 6. HYBRID 802.15.4/DIGIMESH/GPRS NETWORK
Proposing Partner UC
Info Name Hybrid 802.15.4/Digimesh/GPRS-network Owner(s) SmartSantander Consortium
http://www.smartsantander.eu/downloads/2ndOpenCall/Full_Call_Text_Sm Link to code artSantander_Open_Call_2_def.pdf http://www.smartsantander.eu
ID Card ID Project, plus link Patents or other IPR exploitation (licenses) To be determined. As fixed nodes are provided with Digimesh and 802.15.4 interfaces and mobile nodes have GPRS and 802.15.4 interfaces; then fixed-fixed, mobile- mobile and fixed-mobile communications can be established through Description 802.15.4 interface, presenting an hybrid 802.15.4/Digimesh/GPRS network. Type Network Programming language/based technologies 802.15.4, GPRS Exposed APIs
Anatomy Target User(s) Network manager, Researcher, Service Provider
References
Adopted Standard(s) IEEE 802.15.4 Capabilities
/Opportunities Communication skills over a hybrid/heterogeneous network
Known Vehicle to infrastructure and vehicle to vehicle communications implies a Assessment Limitations/Threats very changing environment, difficult to handle and characterize.
ClouT – 31.07.2013 Page 106
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 7. IOT-A MODEL
Proposing Partner CEA
Info Name IoT-A model IoT-A Consortium
Owner(s) Link to code http://www.iot-a.eu/public/public-documents/d1.2/view Project, plus link http://www.iot-a.eu/public
ID Card ID Patents or other IPR License free specifications exploitation (licenses) Description The IoT reference model provides the highest abstraction level for the definition of the IoT-A architectural reference model. Type Software engineering models Programming IoT-A proposes conceptual models that can be implemented by any language/based programming language. technologies Exposed APIs
Anatomy Software architects/ Developers Target User(s) References http://www.iot-a.eu/public/public-documents IoT-A propose a “standard IoT model” to be adopted by other IoT related software projects. Adopted Standard(s) These models provide a way to conceptualize the target IoT scenarios and Capabilities help linking the real-life entities with the information provided by sensors. /Opportunities The lack of concrete examples makes the model difficult to understand by common Users. The project will end in autumn 2013. Getting technical support beyond that date can be difficult. Assessment Known Limitations/Threats
ClouT – 31.07.2013 Page 107
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 8. COAP
Proposing Partner CEA
Info Name CoAP Owner(s) IETF Link to client side implementations:
http://people.inf.ethz.ch/mkovatsc/californium.php (Java) http://coapy.sourceforge.net/ (Python) https://addons.mozilla.org/de/firefox/addon/copper-270430/ (Browser)
ID Card ID Link to code Project, plus link http://tools.ietf.org/html/draft-ietf-core-coap-18 Patents or other IPR Free specifications. Code Components extracted from the draft-ietf-core-coap- exploitation 18 document must include simplified BSD License text. (licenses) Description The Constraint Application Protocol (CoAP) is a specialized web transfer protocol for requirements of constrained environments, especially considering energy, building automation and other machine-to-machine (M2M) and Internet of Things (IoT) applications. Type Application Layer Communication Protocol Programming Language independent. Existing implementations based on C, Java, Python, language/based Javascript technologies Exposed APIs RESTful APIs based on 4 generic methods (GET, PUT, POST, DELETE)
Anatomy Developers of applications for resource constraint devices using 6LoWPAN and Target User(s) IEEE 802.15.4 protocol http://tools.ietf.org/html/draft-ietf-core-coap-18 References CoAP is based on UDP/RPL/6LoWPAN/IEEE 802.15.4. The standardization of Adopted the protocol is a work in progress and by the Internet Engineering Task Force Standard(s) (IETF) Request/response mechanism for resource constrained devices
Rest compatible, easy HTTP mapping. Already existing open source Capabilities implementations (e.g, by Contiki OS) /Opportunities Client-server model, difficult to adapt to event-based applications. Made to work with 6LoWPAN networks. Not suitable (adaptation needed) for
Assessment Known other type of devices. Still IETF draft. Limitations/Threats
ClouT – 31.07.2013 Page 108
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 9. MQTT
Proposing Partner CEA
Info Name MQTT
Owner(s) IBM Link to code http://mqtt.org/wiki/software Project, plus link http://mqtt.org ID Card ID Patents or other IPR exploitation Open source: OASIS standardization process started in March 2013 (licenses) Commercial solutions exist Description MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium. Type Communication Protocol Programming Various open source and commercial implementations exist :
language/based Client : Java, JavaScript, C, Python, device specific (Arduino client), eclipse paho technologies Broker : Windows, Linux, Mac CONNECT, CONNACK, PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBACK, PINGREQ, PINGRESP,
Anatomy DISCONNECT Exposed APIs Target User(s) IoT Application developers See http://en.wikipedia.org/wiki/MQ_Telemetry_Transport for a list of References available implementations Adopted MQTT has been proposed as an OASIS standard Standard(s) Publish/Subscribe mechanism
MQTT is that it was designed to be very lightweight Some cloud messaging service exist M2M.IO Some open source solutions exist e.g., broker Mosquitto) Capabilities small footprint (75KB MQTT broker) /Opportunities Assessment Known Adapted to event oriented applications, less adapted for client/server Limitations/Threats applications.
ClouT – 31.07.2013 Page 109
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 10. FI-WARE IOT PROTOCOL ADAPTER
Proposing Partner CEA
Info Name FI-WARE IoT Protocol Adapter Owner(s) FI-WARE Project
Link to code http://catalogue.fi-ware.eu/enablers/downloads-0 Project, plus link http://catalogue.fi-ware.eu/enablers/protocol-adapter-zpa Belongs to Telecom Italia. Instances for experimental use can be obtained in ID Card ID the context of Open Innovation Lab. Patents or other IPR Conditions described at http://catalogue.fi-ware.eu/enablers/terms-and- exploitation conditions-19 (licenses) Description The Protocol Adapter GE is a generic enabler which aims at handling heterogeneous devices in a common format, as designed in the Generic Device API (developed by Ericsson).It is part of the “Internet of Things Service Enablement” chapter in the Fi-WARE architecture. Type Software component Programming language/based technologies OSGi gateway, implements Zigbee driver Exposed APIs Generic Device Access API, NGSI Anatomy
Target User(s) Gateway developers
References http://catalogue.fi-ware.eu/enablers/protocol-adapter-zpa Adopted Standard(s) OMA NGSI
Capabilities Easy integration of Zigbee devices into OSGi gateways. The gateway can be /Opportunities extended to integrate other protocols.
Restricted access to the FI-WARE enablers. Difficulties to test and evaluate. IPR issues can arise.
Assessment With only the ZigBee implementation available, it is hard to evaluate the Known effectiveness of the Protocol Adapter GE, and the associated Generic Device Limitations/Threats API, for the goal of providing an abstraction layer for all IoT devices.
ClouT – 31.07.2013 Page 110
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 11. MBXXX
Proposing
Partner ST
Info Name MBXXX Owner(s) STMicroelectronics
Link to code http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF247094# Project, plus link ID Card ID Patents or other IPR exploitation (licenses)
IEEE 802.15.4 development boards, equipped with 3-axis acceleration and temperature sensors. Description Type Hardware Programming
language/based technologies Any 802.15.4 based protocol. We use these boards with open standards like
Anatomy IETF 6LoWPAN and CoRE CoAP protocol suite. Exposed APIs They can talk with a PC via serial line and SLIP6 protocol.
Target User(s) Gateway/Human References
Adopted Standard(s) IEEE 802.15.4
Capabilities Flexible and extendible platform, some sensors are provided on board, other /Opportunities can be added via GPIO.
Assessment Known More a development platform than a final product. Battery life has to be Limitations/Threats assessed with regards to the final application.
ClouT – 31.07.2013 Page 111
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 12. STEVAL-IDZ401V1
Proposing Partner ST
Info Name STEVAL-IDZ401V1
Owner(s) STMicroelectronics Link to code
Project, plus link http://www.st.com/web/en/catalog/tools/PF252616 ID Card ID Patents or other IPR exploitation (licenses) The STEVAL-IDZ401V1 is an IEEE 802.15.4/ZigBee RF module with a USB Description interface and with a “dongle” style optimized form factor. Type Hardware Programming language/based technologies Any 802.15.4 based protocol. We use this dongle with open standards like IETF 6LoWPAN and CoRE CoAP protocol suite. Exposed APIs It can talk with a PC via serial line and SLIP6 protocol. Anatomy Target User(s) Gateway References
Adopted Standard(s) IEEE 802.15.4 Capabilities
/Opportunities ent
Known
Assessm Limitations/Threats
ClouT – 31.07.2013 Page 112
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 13. STEVAL-IHP004V1
Proposing Partner ST
Info Name STEVAL-IHP004V1 Owner(s) STMicroelectronics
Link to code
Project, plus link http://www.st.com/web/catalog/tools/FM116/SC1078/PF253892
ID Card ID Patents or other IPR exploitation (licenses) SmartPlug board with IEEE 802.15.4 radio interface, to be used as actuator of a WSAN. It can report energy and power consumption for SmartEnergy like Description applications. Type Hardware Programming language/based technologies Any 802.15.4 based protocol. We use this dongle with open standards like IETF 6LoWPAN and CoRE CoAP protocol suite. Exposed APIs Anatomy
Target User(s) Gateway/Human References
Adopted Standard(s) IEEE 802.15.4 Capabilities
/Opportunities Finished design to be used in Home Automation scenarios.
Known
Assessment Limitations/Threats Current version is discontinued; we are waiting for next release.
ClouT – 31.07.2013 Page 113
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 14. SPIRIT1/STM32L1
Proposing Partner ST
Info Name SPIRIT1/STM32L1 Owner(s) STMicroelectronics Link to code http://www.st.com/web/en/catalog/sense_power/FM1968/CL1976/SC1845 /PF253167
ID Card ID Project, plus link http://www.st.com/web/en/catalog/mmc/FM141/SC1169/SS1295
Patents or other IPR exploitation (licenses) SPIRIT1 is a very low-power RF transceiver intended for RF wireless applications in the sub-1GHz band: 169, 315, 433, 868, and 915MHz. It can be programmed to operate at other additional frequencies in the 300-348MHz, 387-470MHz, and 779-956MHz bands. It works in tandem with STM32L1 that is an ARM Cortex™-M3-based MCU, to provide ultra low power capabilities to the development platforms equipped with these modules. Description Type Hardware Programming language/based technologies natomy
A Any 802.15.4 based protocol. We use these boards with open standards like IETF 6LoWPAN and CoRE CoAP protocol suite. Exposed APIs
Target User(s) Gateway References
Adopted Standard(s) IEEE 802.15.4
Capabilities /Opportunities Last generation technology suitable for very low power kind of operations.
We never developed with these boards, but we plan to implement (part of) Known ClouT specification using Thingsquare Mist firmware and SPIRIT1 based Limitations/Threats hardware. Assessment
ClouT – 31.07.2013 Page 114
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 15. SPEAR320
Proposing Partner ST
Info Name SPEAR320 Owner(s) STMicroelectronics
rd Link to code http://www.st.com/web/catalog/mmc/FM169/SC1156/SS1601/PF247244 Project, plus link ID Ca ID Patents or other IPR exploitation (licenses) ARM (333MHz ARM026EJ-S) based platform with network connectivity and Description MMU capable of virtual memory management that allows running Linux O.S. Type Hardware Programming language/based technologies Exposed APIs Any network based API running on top of the Linux O.S.
Anatomy Target User(s) Sensors/Humans
References
Adopted Standard(s) Capabilities During the life time of the project some new reference board with enhanced /Opportunities capabilities/more embedded communication interfaces may be available.
Known Assessment Limitations/Threats
ClouT – 31.07.2013 Page 115
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 16. WASPMOTE
Proposing Partner UC
Info Name Waspmote Owner(s) Libelium
Link to code http://www.libelium.com/development/waspmote/sdk_applications http://www.libelium.com Project, plus link ID Card ID Patents or other IPR exploitation (licenses) Waspmote board provides a set of interfaces for attaching different types of sensors (both analogue and digital), as well as to plug several radio modules to communicate with other nodes. The Waspmote comes with with a ATmega1281 microcontroller, and several types of memory, 8KB SRAM, 4KB EEPROM, 128KB FLASH and an extra storing SD memory with 2GB capacity. On the other hand, 7 analogue and 8 digital interfaces are available for external sensor connection, as well as 1 PWM, 2UART, 1 I2C and 1 USB interfaces for attaching different communication modules. It has also the capacity to manage Description two independent 802.15.4 radio interfaces.
Type Hardware Programming
Anatomy language/based technologies C, C++ Exposed APIs Waspmote API, Arduino libraries
Target User(s) Humans
References
Adopted Standard(s) Capabilities
/Opportunities
Known
Assessment Limitations/Threats Low processing and memory skills, Battery constraints.
ClouT – 31.07.2013 Page 116
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 17. MESHLIUM
Proposing Partner UC
Info Name Meshlium Owner(s) Libelium
Link to code http://www.libelium.com/development/waspmote/sdk_applications http://www.libelium.com Project, plus link ID Card ID Patents or other IPR exploitation (licenses) Meshlium node behaves as a gateway between a WSN and a backbone network. For this purpose it is provided with 2 802.15.4 interfaces for interacting with WSN and offers WiFi, UMTS and Ethernet interfaces for Description accessing to the stored information through the internet.
Type Hardware Programming language/based Embedded linux so it can be programmed with different programming technologies languages such as C, C++, Java, Python Exposed APIs Web interface for configuration Anatomy
Target User(s) Humans
References
Adopted Standard(s) It is not bounded to connection to waspmote nodes, but radio modules
Capabilities working on 802.15.4, both native and with Digimesh or Zigbee protocols on /Opportunities top.
Known Assessment Limitations/Threats Not so powerful as a PC with an standard Linux.
ClouT – 31.07.2013 Page 117
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 18. ARDUINO
Proposing Partner ENG
Info Name Arduino Owner(s) Arduino Community
Link to code Arduino: http://www.arduino.cc Project, plus link ID Card ID Patents or other IPR exploitation (licenses) Arduino Uno (model of Arduino used): Microcontroller Atmega328, Operating Voltage 5V, Input Voltage (recommended) 7-12V, Input Voltage (limits) 6-20V, Digital I/O Pins 14 (of which 6 provide PWM output), Analogue Input Pins 6, DC Current per I/O Pin 40 mA, DC Current for 3.3V, Pin 50 mA, Flash Memory 32 KB (ATmega328) of which 0.5 KB used by bootloader SRAM2 KB (Atmega328), EEPROM1 KB
Description (Atmega328), Clock Speed 16 MHz , Size 68.6 x 58.3 mm. Type Hardware / software Programming language/based Anatomy technologies Wiring Exposed APIs Target User(s)
References Arduino official website http://www.arduino.cc
Adopted Standard(s)
Capabilities Open-source device often use for different kind of application, easy to use and /Opportunities very cheap.
Assessment Known Limitations/Threats
ClouT – 31.07.2013 Page 118
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 19. RASPBERRY
Proposing Partner ENG
Info Name Raspberry Pi Owner(s) Raspberry Pi Community
Link to code
Card Raspberry: http://www.raspberry.org Project, plus link ID Patents or other IPR exploitation (licenses) Raspberry Pi (model B):
System-on-a-chip (SoC) Broadcom BCM2835 (CPU + GPU. SDRAM is a separate chip stacked on top), CPU 700 MHz ARM11 ARM1176JZF-S core, GPU Broadcom VideoCore IV, OpenGL ES 2.0,OpenVG 1080p30 H.264 high-profile encode/decode, Memory (SDRAM) 512 MB, Video outputs Composite RCA, HDMI (not at the same time), Audio outputs 3.5 mm jack, HDMI, Audio inputs none, but a USB mic or sound-card could be added, Onboard Storage Secure Digital|SD / MMC / SDIO card slot, Onboard Network 10/100 wired Ethernet
RJ45 or WiFi on USB connection, Power ratings (provisional, from alpha board) 700 mA, (3.5 W) , Power source 5 V (DC) via Micro USB type B or GPIO header, Size 85.0 x 56.0 mm. Description
Anatomy Type Hardware Programming language/based technologies Based on Linux; programming language: Python, Java, and C/C++. Exposed APIs Target User(s) References Raspberry official website http://www.raspberrypi.org
Adopted Standard(s) Capabilities Open-source device often use for different kind of application, easy to use and
/Opportunities very cheap.
Known Assessment Limitations/Threats
ClouT – 31.07.2013 Page 119
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 20. STLINUX
Proposing Partner ST
Info Name STLinux Owner(s) STMicroelectronics
Link to code http://www.stlinux.com Project, plus link ID Card ID Patents or other IPR exploitation (licenses) GPL/LGPL
Description Standard Linux OS tailored for ST ARM based boards.
Type Software (Operative system) Programming
language/based technologies C Exposed APIs
Anatomy Target User(s) Gateway/Humans
References
Adopted Standard(s) Capabilities
/Opportunities
Known
Assessment Limitations/Threats
ClouT – 31.07.2013 Page 120
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 21. CONTIKI
Proposing Partner ST
Info Name Contiki O.S. Owner(s) Thingsquare Link to code http://www.contiki -os.org Project, plus link
ID Card ID Patents or other IPR exploitation (licenses) Open source, 3-clause BSD-style license.
Contiki is an open source operative system for Internet of Things, written in C Description and implementing a full standard IPv6 (with 6LoWPAN) stack. Type Software (Operative system/Firmware) Programming language/based technologies C Exposed APIs Network based communication/specific board API (i.e.. getTemperature())
Target User(s) Gateway The Oxford badger tracking system – also used to track swans, hares, and Anatomy eagles The tado° smart thermostat The Rad-DX radioactive radiation monitor References The Zolertia city street noise monitoring system.
Adopted Standard(s) 802.15.4, 6LoWPAN, CoRE CoAP, IPv4, IPv6, TCP, UDP, HTTP, SLIP6
With an open source O.S. that uses open standards, there are no technological Capabilities bottlenecks to really make Things interact with Internet and Cloud based /Opportunities services.
Known Limitations/Threats Assessment
ClouT – 31.07.2013 Page 121
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 22. THINGSQUARE
Proposing Partner ST
Info Name Thingsquare Mist Owner(s) Thingsquare
Link to code http://thingsquare.com/ Project, plus link ID Card ID Patents or other IPR exploitation Open source, 3-clause BSD-style license. (licenses) Evolution of Contiki (on which it is based) with enhanced support for Cloud Description services. Software (Operative system/Firmware) Type Programming language/based
technologies C Exposed APIs Network based communication/specific board API (i.e.. getTemperature())
Anatomy Target User(s) Gateway The tado° smart thermostat (http://www.tado.com) The LIFX WiFi LED bulb (http://www.lifx.co) References
Adopted Standard(s) 802.15.4, 6LoWPAN, CoRE CoAP, IPv4, IPv6, TCP, UDP, HTTP, SLIP6 With an open source O.S. that uses open standards, there are no technological Capabilities bottlenecks to really make Things interact with Internet and Cloud based /Opportunities services.
Known Assessment Limitations/Threats We never tested this new O.S.
ClouT – 31.07.2013 Page 122
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 23. COMMSERVER
Proposing Partner UC
Info Name CommServer Owner(s) SmartSantander Consortium
http://www.smartsantander.eu/downloads/2ndOpenCall/Full_Call_Text_Sma Link to code rtSantander_Open_Call_2_def.pdf http://www.smartsantander.eu
ID Card ID Project, plus link Patents or other IPR exploitation (licenses) To be determined. The CommServer consists of a port multiplexer/demutiplexer, offering several virtual communication ports towards a one physical serial port. This translates into the fact that different applications can simultaneously transmit/receive data through a same physical port using different virtual ports associated to Description each of these applications. Type Network management Programming language/based technologies Module developed in C++. It exposes virtual serial ports for the application to transmit/receive data Anatomy Exposed APIs to/from a physical serial port
Target User(s) Network manager, Researcher, Service Provider References
Adopted Standard(s)
Capabilities /Opportunities Several applications/services concurrently executing over a single serial port.
Known Assessment Limitations/Threats
ClouT – 31.07.2013 Page 123
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 24. MICROSOFT .NET GADGETEER
Proposing Partner NTTRD
Info Name Microsoft .NET Gadgeteer Owner(s) Microsoft
Link to code http://research.microsoft.com/en -us/projects/gadgeteer/ Project, plus link ID Card ID Patents or other IPR exploitation (licenses) Open source Microsoft .NET Gadgeteer is an open source rapid prototyping platform for Description small electronic gadgets and embedded hardware devices. Type Platform Programming
language/based technologies C#, .NET Micro Framework Exposed APIs
Anatomy Target User(s) References http://research.microsoft.com/en-us/projects/gadgeteer/
Adopted Standard(s)
Capabilities It is a platform for creating User’s own electronic devices using a variety of
t /Opportunities hardware modules and a programming environment.
Assessmen Known Limitations/Threats
ClouT – 31.07.2013 Page 124
D2.1 - Reusable components, techniques and standards for the CIaaS
8.2. Virtualization and Hosting of City Resources - Reusable Components
Following all tables with details for reusable components introduced in Chapter 3:
TABLE 25. REMOTE NODE FLASHING
Proposing Partner UC
Info Name Remote node flashing Owner(s) SmartSantander Consortium
http://www.smartsantander.eu/downloads/2ndOpenCall/Full_Call_Text_Sma Link to code rtSantander_Open_Call_2_def.pdf http://www.smartsantander.eu
ID Card ID Project, plus link Patents or other IPR exploitation (licenses) To be determined. In order to remotely modify the behaviour of the nodes installed in the network, a mechanism for remotely flashing nodes over the air called MOTAP (Multihop Over The Air Programming) is implemented over Digimesh protocol Description layer.
Type Network management Programming language/based technologies Protocol developed in Java. Anatomy Exposed APIs Target User(s) Network manager, Researcher, Service Provider References
Adopted Standard(s)
Capabilities Additional managing functionalities to the flashing: scan, start, reset, list and /Opportunities remove.
Known Assessment Limitations/Threats Limited by the wireless channel rate and the packet size.
ClouT – 31.07.2013 Page 125
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 26. COSM/XIVELY
Proposing Partner ENG
Info Name Xively Owner(s) Xively Community
Link to code Xively: http://www.cosm.com Project, plus link ID Card ID Patents or other IPR exploitation (licenses) Xively (xively.com), previously known as Cosm and before than as Pachube, is Description an on-line database service Type Software Programming language/based technologies Web service plus Cloud storage Exposed APIs
Anatomy Target User(s) References Xively official website http://www.cosm.com
Adopted Standard(s)
Xively is a Public Cloud for the Internet of Things that allows connecting different private or public devices like Arduino with dedicated API keys, so to Capabilities allow the User to put and get the data coming from a device, and having simple /Opportunities access to them from the website with a Smartphone, a tablet or a computer.
Assessment Known Limitations/Threats
ClouT – 31.07.2013 Page 126
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 27. NIMBITS
Proposing Partner ENG
Info Name Nimbits Owner(s) Google
Link to code Nimbits: http://www.nimbits.com/ Project, plus link ID Card ID Patents or other IPR exploitation (licenses) Description Nimbits similar to xively is an on-line database service Type Software Programming
language/based technologies Web service plus Cloud storage Exposed APIs Target User(s) Anatomy References Nimbits: http://www.nimbits.com/
Adopted Standard(s) Nimbits is a Public Cloud for the Internet of Things that allows connecting different private or public devices like Arduino with dedicated API keys, so to Capabilities allow the User to put and get the data coming from a device, and have simple /Opportunities access to them from the website with a Smartphone, a tablet or a computer.
Known
Assessment Limitations/Threats
ClouT – 31.07.2013 Page 127
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 28. OVIRT
Proposing Partner ENG
Info Name oVirt Owner(s) oVirt Community
Link to code
Card oVirt: http://www.ovirt.org Project, plus link ID Patents or other IPR exploitation (licenses)
Description oVirt is a virtualizations platform with an easy-to-use web interface.
Type Software Programming language/based technologies Based on Linux, KVM. Anatomy Exposed APIs Target User(s) References oVirt official website http://www.ovirt.org
Adopted Standard(s)
Capabilities Open-source can provide a real IaaS building different Virtual Machine as a /Opportunities Server.
Known Limitations/Threats Assessment
ClouT – 31.07.2013 Page 128
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 29. CDMI-PROXY
Proposing Partner ENG
Info Name CDMI-PROXY Owner(s) Community
Link to code CDMI-Proxy: https://github.com/livenson/vcdm Project, plus link ID Card ID Patents or other IPR exploitation (licenses) The terms of use of the software are governed by the Apache 2 license. CDMI-Proxy is an implementation of a CDMI-compatible (http://cdmi.sniacloud.com/) server that can be used to store data both using Description local infrastructure and public cloud services. Multiplatform. Type Software Programming language/based CDMI-Proxy is written using Twisted network engine in Python (v2.6+) and
technologies was seen working on a number of platforms: Linux, Windows and MacOS X. Exposed APIs Target User(s) Venus C project: Anatomy References http://resources.venus-c.eu/cdmiproxy/docs/index.html
Adopted Standard(s)
Capabilities /Opportunities Metadata of the stored elements is kept in a CouchDB server.
Known Assessment Limitations/Threats
ClouT – 31.07.2013 Page 129
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 30. SENSORIZATION OF SOCIAL NETWORKS
Proposing Partner KEIO
Info Name Detection and visualization of place-triggered geo-tagged tweets
Owner(s) Keio University, Japan Link to code Project, plus link
ID Card ID Patents or other IPR exploitation (licenses) Place-triggered geotagged tweets means that geotagged SNS data which is related to the location. This component has method to detect and visualize of Description place-triggered geotagged tweets. Type Language specification
Programming language/based technologies SQL
Anatomy Exposed APIs Target User(s) End -User / Developer References
Adopted Standard(s)
Capabilities It is still under research phase technology. But it is useful for detecting social /Opportunities events in city area.
Known Limitations/Threats Assessment
ClouT – 31.07.2013 Page 130
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 31. SENSOR ANDREW
Proposing Partner KEIO
Info Name Sensor Andrew Owner(s) Carnegie Mellon University
Link to code http://sensor.andrew.cmu.edu/ Project, plus link ID Card ID Patents or other IPR exploitation (licenses) Sensor Andrew is a large-scale effort to widely deploy sensing and actuating Description devices across Carnegie Mellon University.
Type software Programming
language/based technologies Any language Exposed APIs
Anatomy Target User(s) End-User / Developer
References
Adopted Standard(s) Capabilities It is still under research phase technology. But it is useful for sensorization and
/Opportunities actualization.
Known Assessment Limitations/Threats
ClouT – 31.07.2013 Page 131
D2.1 - Reusable components, techniques and standards for the CIaaS
8.3. Interoperable City Data - Reusable Components
Following all tables with details for reusable components introduced in Chapter 4:
TABLE 32. NGSI
Proposing Partner CEA
Info Name NGSI Context model Owner(s) OMA
Link to code http://technical.openmobilealliance.org/Technical/release_program/ngsi_v1_
D Card Project, plus link 0.aspx I Patents or other IPR exploitation (licenses) Open Specification Description Context Information in OMA NGSI is represented through data structures called context elements which have associated: An EntityId and EntityType, uniquely identifying the entity to which context data refers (see the following figure). A sequence of one or more data element attributes (
language/based technologies Implementations exist using C, Java, JSON, XML, ContextML/CQL NGSI-9 interface: registerContext, discoverContextAvailability, subscribeContextAvailability, Anatomy updateContextAvailabilitySubscription, UnsubscribeContextAvailability, notfiyContextAvailability, NGSI-10 interface: Querycontext, subscribeContext, updateContextSubscription, Exposed APIs unsubscribeContext, notifyContext, updateContext Target User(s) Application developers http://technical.openmobilealliance.org/Technical/release_program/ngsi_v1_ References 0.aspx Adopted Standard(s) Protocol agnostic Capabilities Very generic model that can be adapted to many event based applications. /Opportunities Standard from Open Mobile Alliance
Initially developed for mobile phone applications. Known Very generic and thus multiple representations are possible for the same
Assessment Limitations/Threats context data.
ClouT – 31.07.2013 Page 132
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 33. FI-WARE PUBLISH/SUBSCRIBE CONTEXT BROKER
Proposing Partner CEA
Info Name FI-WARE publish/subscribe context broker Owner(s) FI-WARE project http://catalogue.fi-ware.eu/enablers?chapter_tid=3&=Apply Link to code
https://forge.fi- ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecificati Project, plus link on.Data.PubSub ID Card ID Belongs to Telecom Italia. Instances for experimental use can be obtained in the context of Open Innovation Lab. Patents or other IPR Conditions described at http://catalogue.fi-ware.eu/enablers/terms-and- exploitation conditions-19 (licenses) Description The Context Broker GE enables publication of context information by entities, referred as Context Producers, so that published context information becomes available to other entities, referred as Context Consumers, which are interested in processing the published context information. Type Software component Programming language/based technologies Java Anatomy Exposed APIs RESTful implementation of NGSI9 and NGIS10 interfaces Target User(s) Application developers References Adopted Standard(s) NGSI
The Context Broker GE supports two ways of communications: push and pull Capabilities towards both the Context Producer and the Context Consumer. Push services /Opportunities follows publish/subscribe messaging.
Known Restricted access to the FI-WARE enablers. Difficulties to test and evaluate. IPR Assessment Limitations/Threats issues can arise.
ClouT – 31.07.2013 Page 133
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 34. JSON
Proposing Partner CEA
Info Name JSON
Owner(s) http://tools.ietf.org/html/rfc4627 Link to code Project, plus link http://www.json.org/
ID Card ID Patents or other IPR exploitation (licenses) Open specification Description JSON (JavaScript Object Notation) and described in RFC 4627 (RFC4627 s.d.). It is a lightweight data-interchange format. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. Type Data model Programming
language/based technologies Implementations exist for Java, JavaScript, Python, C
Anatomy Exposed APIs
Target User(s) Application developer, database builder, device provider, platform provider References
Adopted Standard(s) IETF rfc4627 (http://www.ietf.org/rfc/rfc4627.txt)
JSON is a text format that is completely language independent Restful compatible Capabilities Efficient lightweight storage solution /Opportunities Even more with Universal Binary JSON specification (http://ubjson.org/) Known Lack of including semantic. However, some recently developed extensions can Assessment Limitations/Threats allow adding contextual semantic information into JSON, e.g., JSON-LD.
ClouT – 31.07.2013 Page 134
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 35. SENSOR ML
Proposing Partner NTTRD
Info Name SensorML (Sensor Model Language) Owner(s) OGC ( Open Geospatial Consortium)
Link to code http://www.opengeospatial.org/standards/sensorml Project, plus link ID Card ID Patents or other IPR exploitation (licenses) SensorML is a forum standard for describing sensors and sensor systems. It is Description a vocabulary of XML.
Type Standard Programming language/based technologies
Anatomy Exposed APIs
Target User(s) References http://www.opengeospatial.org/standard s/sensorml
Adopted Standard(s) Capabilities
/Opportunities It is recognized as spread standard. SmartSantander use this as sensor description.
Known
Assessment Limitations/Threats
ClouT – 31.07.2013 Page 135
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 36. SESAME
Proposing Partner NTTRD
Info Name Sesame Owner(s)
Link to code http://www.openrdf.org/ Project, plus link ID Card ID Patents or other IPR exploitation (licenses) Aduna licenses Sesame 2 under the terms of a BSD-style license SensorML is a forum standard for describing sensors and sensor systems. It is Description a vocabulary of XML. Type Software Programming language/based technologies Exposed APIs
Anatomy Target User(s) References http://www.opengeospatial.org/standards/sensorml
Adopted Standard(s) Capabilities /Opportunities It can be used as metadata repository.
Known
Assessment Limitations/Threats
ClouT – 31.07.2013 Page 136
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 37. NEO4J
Proposing Partner NTTRD
Info Name NEO4J Owner(s) Neo Technology
d Link to code http://www.neo4j.org/ Project, plus link ID Car ID Patents or other IPR exploitation (licenses) Description Neo4J is an open source graph database. Type Software Programming language/based
technologies Java Exposed APIs
Anatomy Target User(s)
References
Adopted Standard(s) Capabilities
/Opportunities It can be used as metadata store.
Known Assessment Limitations/Threats
ClouT – 31.07.2013 Page 137
D2.1 - Reusable components, techniques and standards for the CIaaS
8.4. City Resources Management - Reusable Components
Following all tables with details for reusable components introduced in Chapter 5:
TABLE 38. SERVICE PROVISION GATEWAY
Proposing Partner UC
Info Name Service Provision Gateway Owner(s) SmartSantander Consortium http://www.smartsantander.eu/downloads/2ndOpenCall/Full_Call_Text_Sma Link to code rtSantander_Open_Call_2_def.pdf
http://www.smartsantander.eu Project, plus link ID Card ID
Patents or other IPR exploitation (licenses) To be determined. This module is in charge of receiving the raw data sent by the different devices deployed in the network, storing it in the corresponding database and Description associating it to a determined service. Type Service data management
Programming language/based technologies Module developed in C++. Exposed APIs Anatomy Target User(s) Service Provider/Application developer References
Adopted Standard(s)
Capabilities /Opportunities Include additional services in an easy and straightforward way.
Known Raw data must be coded in a specific format to be correctly processed by the Limitations/Threats Service provision gateway. Assessment
ClouT – 31.07.2013 Page 138
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 39. RESOURCE MANAGER
Proposing Partner UC
Info Name Resource Manager Owner(s) SmartSantander Consortium
http://www.smartsantander.eu/downloads/2ndOpenCall/Full_Call_Text_Sma Link to code rtSantander_Open_Call_2_def.pdf http://www.smartsantander.eu
ID Card ID Project, plus link Patents or other IPR exploitation (licenses) To be determined. This entity is in charge to arbitrate different mechanisms in order to carry out the registration of new devices and to manage them accordingly (failure Description detection, attributes update), within massive deployments. Type Infrastructure management Programming language/based Entities that compose this module are developed in Java and C++. technologies Resource Directory based on MySQL server.
Anatomy Exposed APIs RPI (Resource Publication Interface) and RLI (Resource Lookup Interface) Target User(s) Network manager References
Adopted Standard(s) Capabilities
/Opportunities
Known
Assessment Limitations/Threats
ClouT – 31.07.2013 Page 139
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 40. KNOPFLERFISH
Proposing Partner ST
Info Name Knopflerfish Owner(s) Makewave
Link to code http://www.knopflerfish.org/
Project, plus link http://www.osgi.org ID Card ID
Patents or other IPR exploitation BSD-style license. (licenses) Open Source implementation of the OSGi standard, framework for Java Description applications to be deployed as gateway software. Type Software
Programming language/based technologies Java Exposed APIs OSGi Services Anatomy Target User(s) Gateway/Humans References
Adopted Standard(s)
Capabilities /Opportunities
Known Limitations/Threats Assessment
ClouT – 31.07.2013 Page 140
D2.1 - Reusable components, techniques and standards for the CIaaS
TABLE 41. UNIVERSAL SERVICE DESCRIPTION LANGUAGE
Proposing Partner KEIO
Info Name Universal Service Description Language
Owner(s) Ubiquitous Networking Forum, Japan Link to code
Project, plus link http://www.ubiquitous-forum.jp/documents/usdl/down-e.html ID Card ID Patents or other IPR exploitation (licenses) Creative Commons Attribution 2.1 Japan License USDL is a standard of format for describing ubiquitous service. The specification is opened by the Ubiquitous Networking Forum in Japan. It allows to application to find services from various services in different environment. Description This format also includes the definition of data types. Type Language specification
Programming language/based technologies XML natomy
A Exposed APIs Target User(s) Managers of city resources References http://www.ubiquitous-forum.jp/documents/usdl/down-e.html
Adopted Standard(s) Capable of describing characteristics and specification of ubiquitous services
Capabilities including sensors/actuators hardware, and software running in networked /Opportunities devices.
Known
Assessment Limitations/Threats
ClouT – 31.07.2013 Page 141
D2.1 - Reusable components, techniques and standards for the CIaaS
References
[DoW] FP7 EU Research Project “Cloud of Things for empowering the citizen clout in smart cities ", Grant agreement no: 608641, Version date: 2013-03-26 - Annex I - "Description of Work".
[Andy Stanford-Clark 2007] Andy Stanford-Clark, Hong Linh Truong. "MQTT For Sensor Networks (MQTTs)." Protocol Specification Version 1.0, 2007.
[MQTT IBM] "Building Smarter Planet Solutions with MQTT and IBM WebSphere MQ Telemetry." IBM redbooks, 2012.
[MQTT] http://mqtt.org/ (accessed 07 02, 2013).
[Context Broker] http://catalogue.fi-ware.eu/enablers/publishsubscribe-context-broker-context- awareness-platform (accessed 07 03, 2013).
[EUROTECH] http://www.eurotech.com/en/products/software+services/everyware+device+cloud/edc+what+it +is (accessed 07 02, 2013).
[FI-WARE PUB/SUB] https://forge.fi- ware.eu/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Data.PubSub (accessed 07 03, 2013).
[JSON] http://www.json.org/ (accessed 07 03, 2013).
[JSON ENGINE] http://code.google.com/p/jsonengine/ (accessed 07 03, 2013).
[M2M.IO] http://help.m2m.io/entries/21577233-connecting-to-m2m-io (accessed 07 02, 2013).
[MOSQUITTO] http://mosquitto.org/ (accessed 07 02, 2013).
[Native JSON] https://developer.mozilla.org/en-US/docs/Using_native_JSON (accessed 07 03, 2013).
[NGSI API] https://forge.fi- ware.eu/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Context_Broker_- _Context_Awareness_Platform_-_User_and_Programmer_Guide (accessed 07 03, 2013).
[NGSI10] http://www.openmobilealliance.org/Technical/release_program/docs/NGSI/V1_0- 20101207-C/OMA-TS-NGSI_Context_Management-V1_0-20100803-C.pdf (accessed 07 03, 2013).
[QEST] http://qest.me/ (accessed 07 02, 2013).
[Really Small Message Broker]
ClouT – 31.07.2013 Page 142
D2.1 - Reusable components, techniques and standards for the CIaaS
https://www.ibm.com/developerworks/community/groups/service/html/communityview?commu nityUuid=d5bedadd-e46f-4c97-af89-22d65ffee070 (accessed 07 02, 2013).
[RFC4627] http://www.ietf.org/rfc/rfc4627.txt (accessed 07 03, 2013).
[UBJSON] http://ubjson.org/ (accessed 07 02, 2013).
ClouT – 31.07.2013 Page 143