Bridging the Pervasive Computing Gap: An Aggregate Perspective

Bridging the Pervasive Computing Gap
An Aggregate Perspective
Roberto Casadei
PhD Student in CS&Eng
roby.casadei@unibo.it
Department of Computer Science and Engineering (DISI)
Alma Mater Studiorum – Università of Bologna
Pervasive Computing 2018/19 MEng Course
R. Casadei Intro Technology: quick survey AC Wrap-up 1/52

Engineering apps
Outline
1 Intro
Engineering pervasive computing applications
2 Technology: quick survey
3 Aggregate Computing
4 Wrap-up

Engineering apps
Outline
1 Intro
AC: recap
Analysis for an Aggregate Computing Platform (ACP)
4 Wrap-up

Engineering apps
The starting point of any engineering process
A vision that must be made concrete / top-down or bottom-up

Engineering apps
Applications as the interface to the needs
Abstractly deﬁned until some concrete underlying technology is identiﬁed

Engineering apps
End-to-end development of IoT Systems
Three key issues:
1) Applications—i.e., the business logic
2) Middleware—i.e., reducing the abstraction gap
3) Operations—i.e., conﬁguration and deployment

Engineering apps
PC Middlewares [RCKZ13] I
Pervasive Computing (PvC) aims to create a smart environment with embedded
and networked computing devices providing users with seamless service access
Key point: seamless service access
Key point: human-centricity
Middleware: SW and tools that can help hide the complexity and heterogeneity
of the underlying HW and network platforms, can ease the management of
system resources, and can increase the predictability of application executions.
Goal of PvC middleware: match application-needs with available resources,
while ensuring quality and efﬁciency

Engineering apps
PC Middlewares [RCKZ13] II

Engineering apps
IoT Patterns for Edge [QPR+
16] » Edge Provisioning
Problem: how to ensure all edge devices are started with a reliable baseline
environment, as needed?

Engineering apps
16] » Edge Code Deployment
Problem: how to deploy code to many IoT devices automatically, quickly, safely, and
conﬁgure them without a long process of build/deployment/test/release?

Engineering apps
16] » Edge Orchestration
Problem: How can we orchestrate IoT devices in accordance with their tightly
scripted conﬁgurations as node of a cluster remotely?

Outline
1 Intro
4 Wrap-up

Technologies
Message-Oriented Middlewares
Why: decoupling consumers from producers (in both space and time)
Examples: RabbitMQ, Kafka
Streaming
Why: need for continuous processing, as long as data is being produced
Types of datasets: un/bounded — processing: batch vs. streaming
Examples: Kafka, Apache Flink, Apache Storm (+ Trident)
NoSQL and spatial data stores
Why: dealing with situated mobile objects, neighbourhoods, locality..
Examples: Redis (geospatial indexes), Neo4J (graph DB + Spatial plugin),
PostGIS (spatial/geographical objects for PostgreSQL)
Automated cluster management
Why: abstract resources & support distributed/fault-tolerant/elastic deployments
Examples: Apache Mesos (+ Marathon), Docker (+ Swarm), Kubernetes

RabbitMQ
https://www.cloudamqp.com/blog/2015-05-18-part1-rabbitmq-for-beginners-what-is-rabbitmq.html

Kafka

Apache Flink I

Apache Flink II

Kubernetes

Mesos
Mesos architecture
Example: Spark on Mesos & process

Lightbend Fast Data Platform

Choosing the set of technologies
Recipe
Start from the problem
Structure–Interaction–Behaviour
Distinguish logical vs. physical
What non-functional requirements?
Identify an architecture
Identify the abstractions you need
Use imagination: “how may I express X assuming to already have an API/platform?”
Study the tools—what abstractions do they provide?
Meet in the middle from top-down and bottom-up

Recap ACP Analysis
Outline
1 Intro
AC: recap
4 Wrap-up

Recap ACP Analysis
Aggregate Computing: bridging the gap to SASO systems
Supports the development and execution of Aggregate Computing applications

Recap ACP Analysis
Outline
1 Intro
AC: recap
4 Wrap-up

Recap ACP Analysis
Aggregate Computing (AC) » what
Goal: programming the collective behaviour of aggregates of devices
Main ideas
Macro-level programming with automatic macro-micro bridging
Declarativity
Support for “engineered emergence”
Composition of aggregate behaviour with predictable dynamics
Layers of reusable abstractions
Abstraction from interaction-level and platform-level issues
Inherent adaptivity
Inherent resiliency
Operational ﬂexibility

Recap ACP Analysis
Compositionality in AC: example
trait DistributedSum extends AggregateProgram {
def distribMean(size:Double, metric: =>Double, v:Double): Double = {
???
}
}
trait Broadcast extends BlockG with ... { s: AggregateProgram =>
def broadcast[V: Bounded](src: Boolean, value: V): V =
G(src, value)(x => x, nbrRange)
}
trait SumCollect extends BlockC with ... { s: AggregateProgram =>
def sumCollect(target: Boolean, value: Double): Double =
C(value)(distanceTo(target,nbrRange))(_+_,0)
}
:
Distributed sum
Split the space into regions with grain size
Calculate the mean of ﬁeld v in each region
Collect the values and the number of nodes in the region
Compute the average
Propagate the computed value

Recap ACP Analysis
trait DistributedSensing extends AggregateProgram
with BlockG with BlockC with BlockS
with Broadcast with SumCollect with Utilities
{
val leaders = S(size, metric)
???
}
}
:

Recap ACP Analysis
trait DistributedSensing extends AggregateProgram
with BlockG with BlockC with BlockS
with Broadcast with SumCollect with Utilities
{
val potential = distanceTo(leaders, metric)
???
}
}
:

Recap ACP Analysis
trait DistributedSensing extends AggregateProgram ... with SumCollect {
val collection = sumCollect(leaders, v)
val count = sumCollect(leaders, 1.0)
val avg = collection / count
}
}
:

Recap ACP Analysis
trait DistributedSensing extends AggregateProgram ... with Broadcast {
val collection = sumCollect(leaders, v)
val count = sumCollect(leaders, 1.0)
val avg = collection / count
broadcast(leaders, avg)
}
}
:

Recap ACP Analysis
Aggregate Computing (AC) » how
Repeated execution
Provides reactivity and incremental adaptivity
Broadcast + aligned interaction
Allows the construction of a “local” context for computation

Recap ACP Analysis
Outline
1 Intro
AC: recap
4 Wrap-up

Recap ACP Analysis
Requirements for an Aggregate Computing platform
High-level, Functional
FR1 Support the speciﬁcation and conﬁguration of AGGREGATE-SYSTEMs
FR2 Support the runtime execution of AGGREGATE-APPLICATIONs
High-level, Non-functional
NR1 Scalability to a large number of NODEs
NR2 Reliability
An AGGREGATE-SYSTEM made of unreliable INFRASTRUCTURAL-COMPONENTs and
unreliable NODEs should be able to continue operation even in face of faults.

Recap ACP Analysis
Requirements analysis
Approach: informal but systematic (Cartesian)
Give names to things
Reﬁne meaning and relationships
Explore in (mentally simulated) use, adopt perspectives and visualize
(Then, formalize early, when enough committed)
AGGREGATE-LOGIC: the representation-independent view of some
aggregate-level behaviour in space/time
AGGREGATE-PROGRAM: an AGGREGATE-LOGIC expressed in some executable
representation
AGGREGATE-APPLICATION: AGGREGATE-LOGIC + APP-CONFIGURATION
AGGREGATE-SYSTEM: a set of networked NODEs supporting the collective
execution of AGGREGATE-APPLICATIONs

Recap ACP Analysis
High-level, logical, informal model
Starting point for a systematic characterisation of our (fuzzy) class of systems
We think of no speciﬁc application/system, but a range of applications/systems
to support/drive analysis and be concrete

Recap ACP Analysis
Structure / Interaction / Behaviour decomposition
(Logical) Structure
DEVICEs (aka NODEs, AGENTs)
Have an identity (UID)
Have SENSORs and ACTUATORs
(Logical) Behaviour/Interaction
A DEVICE can only directly communicate with the DEVICEs of its
NEIGHBOURHOOD
A DEVICE computes its part of AGGREGATE-LOGIC on a round-by-round basis
Steps of a round of execution
1) Retrieve the device’s CONTEXT (SENSOR-DATA, NBR-DATA)
2) Execute LOCAL-AGGREGATE-LOGIC to produce OUTPUT + EXPORT
3) Broadcast EXPORT to NEIGHBOURHOOD
4) Feed ACTUATORS with OUTPUT
This characterization is mainly logical and “standard”
Many questions arise: who? what? where? when? how?

Recap ACP Analysis
Analysis » execution rounds I
SCHEDULING-POLICY: who decides when a round has to be executed?
A SCHEDULER (owned by a device or external)
Construction of the CONTEXT using up-to-date SENSOR-DATA and NBR-DATA
Ideally, we’d like to separate the time/frequency in which these information are
collected from the time in which they are received
Retrieval of SENSOR-DATA: request/response to device’s SENSOR or sampling of
an incoming SENSOR-DATA-STREAM
Note: location data (e.g., GPS coords) may need to be sent to the
TOPOLOGY-MANAGER
Retrieval of NBR-DATA: request/response to a FIELD-MANAGER or sampling of an
incoming NBR-DATA-STREAM
Who actually executes the AGGREGATE-LOGIC for a given DEVICE?
An AGGREGATE-LOGIC-EXECUTOR (owned by a device or external)

Recap ACP Analysis
Analysis » execution rounds II
Broadcast of EXPORT to NEIGHBOURHOOD
By the DEVICE itself (if it knows how to reach its NEIGHBOURHOOD)
But the DEVICE’s awareness of communication is questionable
“No matter who you are! I know where you are” [ZM04]
The DEVICE may simply send its computation descriptors (EXPORTs) to the
FIELD-MANAGER
The FIELD-MANAGER in turn may delegate the task to an EXPORT-PROPAGATOR
which must then know the NEIGHBOURHOODs and how to reach them
Invocation of ACTUATORs
In general, we may have ACTUATION-DATA-STREAMs directed to ACTUATORs
which may be controlled by (but still decoupled from) rounds.

Recap ACP Analysis
Analysis » neighbourhood
NBR-POLICY: how is NEIGHBOURHOOD determined?
May be communication-determined (i.e., my neighbours are those I can reach)
May be spatially-determined (i.e., derived from the devices’ position in space)
May be ad-hoc (i.e., application-speciﬁc)
Who owns the knowledge of a device’s NEIGHBOURHOOD?
A TOPOLOGY-MANAGER (owned by a device or external)
Who uses the knowledge of a device’s NEIGHBOURHOOD?
The EXPORT-PROPAGATOR
Properties of NEIGHBOURHOOD
It is usually dynamic
Can be asymmetric

Recap ACP Analysis
Analysis » conﬁguration
How do components locate (the address of) other components?
DEVICEs should be addressable to support e.g. peer-to-peer interaction or the
the delivery of ACTUATION-DATA
The mappings between DEVICEs’ UIDs and their ADDRESS may be kept in a
REGISTRY
Devices should also be given some CONFIGURATION data – so that they know the
ADDRESS of required services
How do AGGREGATE-LOGIC-EXECUTOR obtain the AGGREGATE-LOGIC to execute?
Can be provided at deployment or conﬁguration time

Recap ACP Analysis
Logical components emerging from analysis (dev-centric)
It comes natural to assign many responsibilities to the DEVICEs (cf., p2p setup)..

Recap ACP Analysis
Logical components emerging from analysis (sys-centric)
It comes natural to consider DEVICEs only as situated contexts..

Recap ACP Analysis
Many kinds of deployments
Such ﬂexibility demands for ﬂuid responsibilities

Recap ACP Analysis
The data perspective
Data payloads
SENSOR-DATA: map from sensor UIDs to sensor values
ACTUATION-DATA: map from actuator UIDs to actuation values
NBR-DATA (i.e., EXPORTS): map from neighbour UIDs to exports
CONTEXT-DATA = SENSOR-DATA + NBR-DATA
Control data
SCHEDULE-DATA (i.e., TICKs)
...
Configuration data
Deployment data, addresses, ...
...
Analysis from a data (flow) perspective
» On an app-specific basis, analysis of Volume-Velocity-Variety-Veracity
» Further analysis: persistent vs. transient data
» Further analysis: replication, partitioning, ...
» Analysis of data flow can help architectural design (cf., reactive architectures)

Outline
1 Intro
4 Wrap-up

Summary: key ideas
Pervasive Computing Platforms
PervComp needs platforms/middlewares to reduce the abstraction gap!
Aggregate Computing
• A macro-programming approach to CASs, formally grounded in Field Calculus
• Allows composition of (self-stabilizing) SASO patterns
• Is a fully operational approach that requires proper tooling
=⇒ SCAFI: a Scala framework for Aggregate Programming
• Provides an internal DSL for ﬁeld-based computations
• Provides simulation facilities
• Provides an actor-based platform for building aggregate systems
• The abstract model is decoupled from the execution strategy
• Developing a ﬂexible platform for AC is not easy

Aggregate Computing » Food for thought
1 Spatial Computing interpretation—Aggregate Systems as approximation of
space/environment; programs can be used to analyse or manipulate such space.
2 Programming ecosystems—expressing global laws to regulate the dynamics of
large-scale, situated, heterogeneous systems.
3 Context-oriented perspective—Devices can be seen as “contextual probes”;
programs can be used to reify contexts at different levels (from local to global).
4 Aggregate applications and system details—aggregate programs “assume” a
certain execution model and neighbouring relationship; how much can we stretch
such notions still preserving our properties of interest? how much can/should we
hide them?
5 Human-Robot systems—how may we use aggregate speciﬁcations to also
integrate humans in collective activities?
Conciliate autonomy and prescription
Handling unpredictability
6 Non-situated systems—can Aggregate Computing be still useful for
non-situated/spatial systems?

Perspectives, projects, future works I
Aggregate Computing is a huge effort that deals with several aspects & challenges!
Note: you have multiple choices
You have multiple choice on the style of the activity and level of engagement:
Course ←→ Thesis
Engineering ←→ Research
General ←→ Speciﬁc
Novelty, investigation ←→ Well-known challenges
Your activity may touch one or more of the following ﬁelds:
Mathematics
Complex Systems
Distributed algorithms
Programming languages/paradigms
Software engineering
Simulation
Devops
Computer security
Read carefully these slides and contact us for any doubt.
Feel free to ask or propose the kind of activity you prefer.

Perspectives, projects, future works II
Past projects
Actor-based SCAFI platform bootstrap
Support for a CI process in SCAFI
Improved support for distribution in SCAFI platform
SCAFI-Alchemist integration
Addition of mobility actuators in the SCAFI simulator to support e.g. ﬂocking
Anticipative Gradient algorithm
SCAFI on Android

Perspectives, projects, future works III
Algorithms and SCAFI library
Testing of algorithms through simulations
Design of novel algorithms or implementation of “better” variants
E.g., flocking
SW engineering (AC as a case study)
Analysis/design and impl/refactoring of an AC Platform (Scala)
Scafi Simulator
Extensions to the ScaFi simulator
Extension of simulator GUI to support 3D simulations
Distributed simulations in a cluster
Analysis of a complete, flexible middleware solution for AC systems
Devops: IoT/Edge deployment of aggregate applications (containers)

Perspectives, projects, future works IV
Integration and applications
Web/RESTful interfaces to AC systems (à la WoT)
AC and IoT/Edge/Cloud Computing
AC and IoT platforms
Development of a custom PaaS for AC
Comparative study of IoT/PervComp middlewares and platforms
Prototyping a scalable AC cluster with open-source solutions
Reactive AC architecture
Fields like Big Data and NoSQL solutions

Perspectives, projects, future works V
Innovative themes and experiments
AC and computer security, trust, privacy
Aggregate processes
AC and context-oriented programming
AC and service choreographies (cf., Jolie, Chor)
AC and social networks
AC and complex networks
AC and topological methods (math-oriented)
Miscellaneous
Comparing AC to BSP-based graph processing systems (Pregel/Giraph)
Missing something? Provide your own ideas!

Application scenarios
Crowd engineering
Distributed sensing
Contextual services
Smart city (e.g., intelligent lighting)
Smart building
Industry 4.0
WSNs
Swarm intelligence (robots, drones)
Rescue scenarios

Project examples
1 Middleware—Analyse the problem of providing flexible cloud/flog/edge
middleware support for Aggregate Computing applications. Identify the key
general concerns, abstractions, non-functional requirements that might arise in
some application scenarios.
2 3DSim—Develop a prototype of a 3D Simulator for Aggregate Systems on the
JVM.
3 Edge—Study how Aggregate Computing techniques can be used to orchestrate
task scheduling in Edge Computing scenarios.
4 Flocks—Extend the ScaFi standard library with high-level flocking capabilities,
and provide nice demos.
5 Processes—Experiment with the process-oriented API of Scafi, and contribute
with additions and demos.

References
References I
[QPR+
16] Soheil Qanbari, Samim Pezeshki, Rozita Raisi, Samira Mahdizadeh,
Rabee Rahimzadeh, Negar Behinaein, Fada Mahmoudi, Shiva
Ayoubzadeh, Parham Fazlali, Keyvan Roshani, et al.
Iot design patterns: computational constructs to design, build and
engineer edge applications.
In Internet-of-Things Design and Implementation (IoTDI), 2016 IEEE First
International Conference on, pages 277–282. IEEE, 2016.
[RCKZ13] Vaskar Raychoudhury, Jiannong Cao, Mohan Kumar, and Daqiang Zhang.
Middleware for pervasive computing: A survey.
Pervasive and Mobile Computing, 9(2):177–200, 2013.
[ZM04] Franco Zambonelli and Marco Mamei.
Spatial computing: An emerging paradigm for autonomic computing and
communication.
In Workshop on Autonomic Communication, pages 44–57. Springer, 2004.
R. Casadei Appendix 51/52

Bridging the Pervasive Computing Gap: An Aggregate Perspective

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Bridging the Pervasive Computing Gap: An Aggregate Perspective

Similar to Bridging the Pervasive Computing Gap: An Aggregate Perspective (20)

More from Roberto Casadei

More from Roberto Casadei (20)

Recently uploaded

Recently uploaded (20)

Bridging the Pervasive Computing Gap: An Aggregate Perspective