1. Cloud Based IoT Applications
Mobile Crowdsensing, Social and Big Data as Innovation Enablers for Future Internet Cloud-based Architectures and Services
Cloud Based IoT Applications
Prof. Antonio Puliafito
Athens - March 18, 2014

2. “Game Changers” “Just On” Cloud Computing is …
“Biggest Paradigm Shift in 20 years”
“Game Changers”
“Just On”
“Pay As You Go”
“Tremendous Cost Cutting”

3. Hype cycle for Cloud Computing
Source: Gartner, Hype Cycle for Cloud Computing, 2011 David Mitchell Smith Publication Date: 27 July 2011 ID Number: G © 2011

4. Cloud Services Beyond the IT Industry
Business
(Process-as-a-service)
Every Other
Industries’
Cloud Services
Cloud
Applications
(Apps-as-a-service)
App Dev/Test
Cloud
(Application)
Platforms
App Deploy
The IT Industry’s
Cloud Services
Cloud
Infrastructure
(Infrastructure-as-a-Service)
Source: IDC Executive Telebriefing
29 September 2009

5. NIST Cloud Computing New Reference Architecture
“Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This Cloud model promotes availability [...].”

6. Why Cloud Computing?
Cloud computing brings a new level of efficiency and economy to delivering IT resources on demand just like public facilities and it opens up new business models and market opportunities.
It offers more than a “pay-per-use” model. The major trends are:
IT Efficiency. Companies are minimizing costs, converting them from capital expenses to operating expenses through technologies such as virtualization (i.e. an enterprise do not have to buy expensive equipments to build its business but can build its infrastructure compousing services).
Business Agility. Companies are maximizing return using IT as a competitive weapon through the rapid time to market, by mean of integrated application stacks, instant machine image deployment, and parallel programming

7. Virtualization
Virtualization is the main technology behind the clouds.
It allows servers, storage devices, and other hardware to be treated as a pool of resources rather than discrete systems.
These resources can be allocated on-demand.
It allows also to exploit and migrate resources, regardless of the underlying real physical infrastructure.
Virtualization solves several core challenges of datacenter managers and delivers specific advantages, including:
Higher utilization rates
Resource consolidation
Lower power usage/costs
Space savings
Disaster recovery/business continuity
Reduced operations costs

8. WSNs/mobiles: towards the IoT
smart things get linked through the Net
IoT/Future Internet, the current trends underlying the ubiquitous convergence of devices and Web

9. Next frontiers for IoT Key features Abstraction Virtualization
semantic enablement
autonomous cooperation
Key features
Abstraction
Virtualization
Management

10. Cloud towards sensing
Widespread availability of cheap sensing devices
On-board components built into a wide range of systems (e.g., smartphones, indash units, body sensor networks...)
Advances in pervasive computing techniques
Many application scenarios: healthcare, smart city, domotic, traffic assistant, ...
Many concepts, standards and projects:
Internet of Things (IoT)
OGC Sensor Web Enablement (SWE),W3C Semantic Sensor Networks (SSN),...
 SIMONE(Sistema Integrato per il MONitoraggio della produzione di Energia elettrica), DAMOCLES (Developing Arctic Modeling and Observing Capabilities for Long-term Environmental Studies), CASA (Center for Collaborative Adaptive Sensing of the Atmosphere), Portolan Network Sensing Architecture,...
Sensing devices expose an all-round smart behavior, thus becoming active devices able to e.g., selfprobe and advertise hardware equipment and software components

11. Towards a sensing Cloud: a new take
Geographic SN
IaaS-like, on-demand service provisioning of (virtual) sensing and actuation resources
Device-driven approach, i.e. provisioning of actual (even if virtual) sensing resources – vs data-driven i.e. SaaS-like
Basic functionalities:
Abstraction, virtualisation, customisation of sensing resources
Enrolment, management of contributing nodes (static and mobiles – SN and smart devices)
On-demand provisioning of virtual sensing resources: discovery, monitoring, management, etc.

12. New challenges
Heterogeneous sensing environments
smart sensors/actuators
embedded systems
sensor networks
...
Uniform management of resources
data monitoring
application deployment
remote system control
...
on the one hand… on the other hand
A framework able to abstract many types of HW and SW resources enabling an integration between application requirements and sensors capabilities

13. Cloud computing
Cloud computing might be the GLUE for aggregating heterogeneous systems able to gather information from the environment
Data Consumers
Sensing Devices (SDs)
Sensor Networks (SNs)
A Cloud Data provisioning system:
for capturing information from the physical world
interacting with heterogeneous devices and observation environments
HW and SW sensing
able to store and manage huge amount of data
virtualization, it is the most suitable approach to guarantee the high level of interoperability. It allows a world-wide and cross-related range of services

14. From IaaS/DaaS to SAaaS
traditional Infrastructure as a Service: computing and storage resources
the next step, SAaaS: Sensing/Actuating resources as new infrastructure to be served according to the current Cloud paradigm

15. Volunteer approaches
glueing in-advance (steady) and opportunistic participation
enabling fully unassisted contributing node setup
exploiting optional crowd-sourced content to build metadata, thus adding value and building new services

16. architecture
PRIN 2008
A new computing paradigm merging Volunteer computing and Cloud computing allowing open computing service market.

17. SIGMA: SISTEMA INTEGRATO DI SENSORI IN AMBIENTE CLOUD PER LA GESTIONE MULTIRISCHIO AVANZATA
Goal
acquire, integrate and compute heterogeneous data, from various sensor networks (weather, seismic, volcanic, water, rain, car and marine traffic, environmental, etc.), in order to strengthen control and monitoring systems to provide useful data for the prevention and management of risk situations through services provided to citizens and businesses, both public and private.
Innovations
Cloud platform: develop a federated cloud management systems
Security: technology for specifying/enabling security features
Sensors and Cloud integration: define methods to grab data and interact with sensors
Advanced Capabilities for Cloud-based Storage: support delivery of data-intensive services securely, at the desired QoS, at competitive costs
Data Mobility and Federation: enable comprehensive data migration and interoperability across remote locations
Facts
A 2-year project, started May 2013
€ M (total budget all partners)

18. Sensor Cloud: scenarios

19. Data-driven approach
Storage of information related to the physical and virtual resources, middleware working status and data for clients
Management of physical sensing resources hiding underneath technologies.
Management of physical resource in a datacenter, providing
user accounting, Service Level Agreements (SLAs), Billings,...

20. Data-driven approach
Sensor Web Enablement standard, defined by the Open Geospatial Consortium
SOS (Sensor Observation Service)
interface for requesting, filtering, and retrieving observations and sensor system information;
SPS (Sensor Planning Service)
interface for requesting user-driven observations;
SAS (Sensor Alert Service)
interface for publishing and subscribing alerts from sensors.
SensorML
models and XML schemas for describing sensors systems and processes;
O&M (Observation and Measurements)
models and XML Schema for encoding observations from a sensor network;

21. C-SENSOR Architecture
It implements the SWE-SOS standard (Sensor Observation Service)
request, filter, and retrieve observations and sensor system information
SEDNA DB
It implements the SWE-SAS (Sensor Alert Service) and the SWE-SPS ((Sensor Planning Service) standards
provisioning of sensing information towards Data Consumers
actuation of remote Data Consumers directives

22. Inter host (inter cluster) Communication: p2p
Zero configuration: ZeroConf
Monitoring
Advanced Security features
XMPP based: host presence, open standard
Fault Tolerance: no central point of failure
Official CLEVER's web site
The source code hosted on

23. ST Microelectronic testbed
Monitoring Energy consumption in an industrial site
MeshNetics devices
FRER Q96U4 analyzer
WhereX middleware

25. Device-driven approach: SAaaS High Level Architecture
The SAaaS reference architecture comprises three modules, Hypervisor, Autonomic Enforcer and VolunteerCloud Manager.
The Hypervisor allows to manage, abstract, virtualise and customise sensing and actuation resources that could be provided by enrolling either mobile device or SN nodes. Among key features are: abstraction of devices and capabilities, virtualization of abstracted resources, communications and networking, customization, isolation, semantic labeling, and thing-enabled services.
At a higher level with respect to the Hypervisor, the Autonomic Enforcer and the VolunteerCloud Manager deal with issues related to the interaction among nodes. The former is responsible of the enforcement of local and global Cloud policies, subscription management, cooperation on overlay instantiation. The VolunteerCloud Manager is in charge of exposing the Cloud of sensors via Web service interfaces, indexing of resources, monitoring Quality of Service (QoS) metrics and adherence to Service Level Agreements (SLAs).

26. SAaaS: Hypervisor
The Hypervisor is a foundational component of our device-driven approach to infrastructure-focused Clouds of sensors: it manages the resources related to sensing and actuation, introducing layers of abstraction and mechanisms for virtualization, operating at the level of a single SAaaS node, defined either as an entire sensor network, as long as under exclusive tenancy, or a set of sensors, as built-in to a standalone device.
The Hypervisor is split among a centralized (nodal) device, possibly embedding one or more sensors, and the motes, i.e. small-footprint edge devices in a SN.
The Adapter, plays several distinct roles mainly related to the interface with on-board resources and its customisation.
The Node Manager works only at the node level and is in charge of sensing resources operations and implementing policies.
The Abstraction Unit replicates facilities of the Adapter but on a node-wide scale, combining the pool of resources of the whole SN or smartphone.
The Virtualization Unit main task is slicing, i.e. generating possible partitioning schemes for the cluster of resources exposed by the Abstraction Unit.

27. SAaaS: Adapter
The Observation Agent requests, retrieves and eventually pre-processes measurements.
In terms of both behaviour and implementation details, the Planning Agent pushes requests for actions (tasks) to the device, for preparing the resource to carry out a variety of duties (reservation of functionalities, tuning of parameters, scheduling of observations). These commands allow management of operating parameters such as duty cycle, sampling frequency, etc. The jargon we are using talking about observation and planning operations traces back to our aim to be compliant with the SWE standards. These two agents rely on the presence of a platform-specific driver, the Translation Engine, responsible for converting the high-level directives in native commands. The Hypervisor is also in charge of processing requests for reconfiguration of the device, using the Customization Engine, an interpreter able to execute on the sensing device the code needed to tailor the sensing activities to customer-mandated requirements. Finally, an autonomic approach is adopted delegating some management tasks of the Adapter to the Mote Manager running mote-side, performing specific operations such as power-driven self-optimization in collaboration with the Node Manager.

28. The Planning Agent (PA)
The main functionalities provided by the SAaaS PA are:
tuning of sampling parameters according to user-defined preferences
Extensible standards-compliant encoding of requests for tasks, and corresponding responses
scheduling of observations
following a predefined schedule, or
upon the occurrence of a particular event, or
simply on user demand
exposing all underlying knobs to make them available for customers to operate on transparently

29. PA Architecture – Interaction Workflow
Request Dispatcher has to identify and demultiplex a request to the modules underneath.
The lowest Interface has to interact with low-level services, i.e. the Customization Engine, the Translation Engine and the Mote Manager.
The Sensor Prober is in charge of enumerating all the sensors and actuators within a sensors platform.
The Task Explorer is responsible for enumeration of available tasks, to be provided by probing sensors as listed by the Prober.
The Task Manager controls tasks’ lifecycle, since feasibility assessment through reservation/submission stages, then following up, and acting upon, running task progress.
The Feasibility Controller has to check if a task is feasible.
The Task Updater is in charge of updating configuration parameters of a task, if some modifications have to be pushed after tasks enter into processing stages.
The Task Canceller empowers users to stop and therefore retire a task, when already submitted or under reservation.
Finally, once a task has been serviced, resulting observations get stored. Any observation will be accessible through the Observation Agent only. In terms of observations, the sole duty up to the PA lies in the Observation Access Provider ability to provide endpoints to access measurements.
A possible User SAaaS provider is highlighted on the left and can be described into three phases:
i. Sensors & Tasks Acquisition: providing users with all available tasks, as offered by the SAaaS provider;
ii. Sensor Use / Interaction: selecting and preparing a task to be then submitted to the SAaaS provider, while keeping the ability to manage the task during its execution;
iii. Observation Access: in case one or more observations were the expected output of the task (e.g. scheduling or confirmed reservation), providing users with methods to retrieve stored measurements.

30. PA Android Implementation – SAaaS4Mobile
Example of the previous described interactions on SAaaS4Mobile
Discovery
Task Listing
Task Submission
Results Retrieval

31. SAaaS killer application: Mobile CrowdSensing

32. Mobile Crowdsensing: current issues
volunteer enrolment:
requires out-of-band campaign (social network) to get attention
involves user-initiated activity (website download) to begin contributing
slow and unpredictable uptake
app/service availability/reliability:
degradation with node churn
real-time info may translate into severe burden on resources (battery)

33. Mobile Crowdsensing: SAaaS possibities
MCS app providers may leverage automatic management of SAaaS-enabled infrastructure:
no need for targeted ads or direct interaction
(app) provider-initiated involvement workflow
uptake rates just limited by chosen area of interest and widespread coverage of SAaaS contributors (and by willingness to pay/barter)
in typical PaaS fashion:
placing a platform layer over Cloud-enabled infrastructure
leaving no dependency (either explicit or strictly needed) between the two levels

34. MCSaaS - MCS as a Service

35. MCSaaS: a Cloud platform for deploying MCS apps on SAaaS infrastructure
readily available infrastructure:
a platform provider only needs booking resources for MCS, sending client-side platform code
SAaaS will take care of (one-time) client deployment
automatic deployment:
fire-and-forget experience for the app provider - just send a request to MCSaaS provider for resources, attaching the payload
(SAaaS-unaware) dissemination carried out by the platform

36. MCSaaS: a Cloud platform for managing MCS apps on SAaaS infrastructure
churn management(s), each at its own layer:
transparent
built-in, as part of the framework(s) management
real-time info:
built-in, platform-level sharing of monitoring data
low device-side load from infrastructure-level stats collection
optional on-demand feature, may be disabled at will
lower strain on constrained resources

37. Mobile Crowdsensing application: PotHole Detector
based on two components:
an Android app running on volunteer-owned mobiles
a Back-End system to collect data, and also filter, analyze and mine it
exploiting mobile-carrying volunteering commuters to detect and classify automatically road surface conditions
combined sampling of:
acceleration data from on-board motion detection sensors
geospatial coordinates as provided by the GPS

38. Mobile Crowdsensing application: PotHole Detector
enables generating a quality map of traversed roads, pinpointing any distress condition and potential presence of potholes
performs uninterrupted sampling of parameteres coming from accelerometers
computes changes in the sampled values for acceleration (intuitively, when bumping into a pothole on the way, or more generally going down a distressed road surface, these changes may turn out to be hefty) and marks the presence of a potentially critical condition at the corresponding geospatial coordinates
info thus acquired to be stored in a centralized DB, as data source for a Web application in order to enable monitoring of roads condition
the same information base could be useful for local government and competent authorities to plan carefully targeted maintenance actions and aptly arranging those according to levels of priority
most business logic, data filtering and analysis routines reside inside the Web aplication, in order to keep computational duties for involved mobiles at a minimum, e.g. just essential mechanisms and filtering rules to drop false positives

39. Mobile Crowdsensing application: PotHole Detector

40. Mobile Crowdsensing application: PotHole Detector

41. Arduino Yún

42. Arduino Yún
The Yún distinguishes from other Arduino boards in that it can communicate with the Linux distribution onboard, offering a powerful networked computer with the ease of Arduino.
The Atheros AR9331 processor supports a Linux distribution based on OpenWRT named Linino.

43. A MIPS GNU/Linux box for Arduino
Combining the Linux OS with Arduino HW + certified WiFi n connectivity and use OpenWRT and Peer-to-Peer (AllJoyn) technology to customize your own project.
Linino.org is a dog hunter-sponsored community project.
An installation of Python is included with Linino, with which you can write applications or scripts.
Linino uses REST for clients and servers. It is a software architecture that exposes various parts of the Arduino hardware through URLs.

44. A Common Language for the Internet of Everything
The other great thing about the Yún is the integration with AllJoyn™
AllJoyn™ is the open source project that lets the compatible smart things around us recognize each other and share resources and information across brands, networks, and operating systems.

45. AllSeen Alliance is a Linux Foundation Collaborative Projects.
provides a software framework and set of Services that enable interoperability among connected products and software applications, across manufacturers, to create dynamic proximal networks.
Originally developed by Qualcomm Innovation Center, Inc. (QCE), and now hosted on AllSeen Alliance.
AllSeen Alliance is a Linux Foundation Collaborative Projects.
Reference
Andrea Rocco Lotronto AllJoyn Framework

46. AllJoyn bus
The most basic abstraction of the AllJoyn system is the AllJoyn bus. It provides a fast, lightweight way to move marshaled messages around the distributed system

47. What new experiences can AllJoyn enable?

48. Conclusions
a novel approach: IaaS-like sensing Cloud through the SAaaS
Device-driven vs Data-driven
basic low-level mechanisms for interfacing with the device
SAaaS4mobile: an Android implementation of the stack (Planning agent and SWE std.)
first design and implementation steps into an IaaS-enabled platform

49. Future work
SAaaS engineering of customisation, virtualisation, self-management and volunteer- Cloud features
porting core SAaaS4mobile logic to other embedded platforms, e.g. typical WSN nodes
extending MCSaaS with user preference profiles and sandboxing capabilities
Cloud of Things, Things as a Service (TaaS)
semantically tagging devices
Integration of CLEVER modules inside YUN
Integrazione con CoAP

50. A journey of a thousand miles begins with a single step
Lao - tzu

51. Antonio Puliafito
University of Messina