On Execution Platforms for Large-Scale Aggregate Computing

On Execution Platforms for Large-Scale Aggregate
Computing
Mirko Viroli Roberto Casadei Danilo Pianini
Department of Computer Science and Engineering
University of Bologna
Workshop on Collective Adaptation in Very Large Scale Ubicomp: Towards a
Superorganism of Wearables (VLSU), Ubicomp/ISWC Adjunct, September
2016, Heidelberg (Germany)
R. Casadei (Università di Bologna) On Execution Platforms for Large-Scale Aggr Comp PMLDC 2016 1 / 47

Outline
1 Context and Issues
2 Aggregate Computing
3 Execution Platforms for Aggregate Computing
4 Summary

Context and Issues
Outline
4 Summary

Context and Issues
Context
Environment + (Mobile, Large-scale) Networks of { people + devices }

Context and Issues
The Crowd Engineering Example I
Wearable devices collectively form a “diffused” computational system.
Upon it, an ecosystem of (CAS) services can be envisioned.

Context and Issues
The Crowd Engineering Example II
Mechanisms Gathering local context

Context and Issues
The Crowd Engineering Example III
Mechanisms Sensing global patterns of data

Context and Issues
The Crowd Engineering Example IV
Services Crowd detection

Context and Issues
The Crowd Engineering Example V
Services Crowd anticipation

Context and Issues
The Crowd Engineering Example VI
Services Crowd-aware steering

Context and Issues
The Crowd Engineering Example VII
Services Crowd dispersal

Context and Issues
The systems of tomorrow today...
The landscape
Driving forces
• Miniaturisation, low cost ⇒ more and more devices embedded into environment
• New business opportunities and trends
Frictions
• Redundant effort in multiple niches
• Fuzzy boundaries, multifaceted, varied, with issues at multiple levels
Key issues
• Large-scale ⇒ decentralisation
• Complex dynamics ⇒ good abstractions
• Situatedness ⇒ substantial unpredictability ⇒ self-adaptivity
How can we reliably engineer situated CASs?
• .. and keep our solutions independent from many aspects?

Aggregate Computing
Outline
4 Summary

Aggregate Computing
The origins: space-time programming [BV15]
Space-oriented computation – Thematic areas
(a) Intensive computing
(b) Computation embedded in space
(c) Space computation
Decentralised spatial computing
Computing “somewhere” [Duc13]
• Location-related information
• Spatial constraints to communication
Space-time programming [BV15]
• Computation expressed in terms of properties of the physical time and
space in which it occurs
• Spatial abstractions

Aggregate Computing
Discrete system vs. continuous space-time

Aggregate Computing
Aggregate programming [BPV15]
Programming (collective adaptive) systems: viewpoints
(a) Local viewpoint (device-centric view)
(b) Global viewpoint (aggregate view)
Aggregate programming: what
Goal: programming the collective behaviour of aggregates
Global-to-local mapping
Aggregate programming: how
Prominent approach founded on ﬁeld calculus and self-org patterns
• Computational ﬁelds as unifying abstraction of local/global viewpoints
Composable self-organisation
• Self-stabilisation
• Building blocks for resilient coordination

Aggregate Computing
Device-centric programming
Issues
• Local-to-global mapping problem (generally intractable)
• Explicit design of adaptation and communication
• Mixing of concerns — state management, interaction, adaptation, resiliency, etc.

Aggregate Computing
Aggregate-level programming
Collective services on the computational fabric available in space
• Automatic global-to-local mapping
• Implicit adaptation and communication
• Composition of loosely coupled services

Aggregate Computing
Aggregate (computing) systems
Structure
A set of networked devices
• Each one is given the same ﬁeld calculus program.
• FC has mechanisms to differentiate local executions within a global
behaviour.
• The execution semantics of FC gets context-dependent via local features
(e.g., sensors) and nbr.
Dynamics
Each device computes the given program at asyn / partially-sync rounds of
execution
(1) Retrieve context
⇐ Messages from neighbours
⇐ Sensor values
(2) Aggregate program execution
⇒ export
(3) Broadcast export to neighbourhood
(4) Execute actuators

Aggregate Computing
SCAFI: Scala with Computational Fields
What
SCAFI [CV16] is an integrated framework for building systems with aggregate
programming.
• Scala-internal DSL for expressing aggregate computations.
• Linguistic support + execution support (interpreter/VM)
• Correct, complete, efﬁcient implementation of the HOFC semantics
• Distributed platform for execution of aggregate systems.
• Support for multiple architectural styles and system conﬁgurations.
• Actor-based implementation (based on Akka).
Where
http://scafi.apice.unibo.it (a better release soon)
Why Scala?

Aggregate Computing
Computational ﬁelds
• (Abstract interpretation) Mapping space-time to computational objects
• (Concrete interpretation) Mapping devices to values: φ : δ →
• “Distributed” data structure working as the global abstraction

Aggregate Computing
Computing with fields I
Expressing aggregate/field computations in SCAFI
trait Constructs {
def rep[A](init: A)(fun: (A) => A): A
def nbr[A](expr: => A): A
def foldhood[A](init: => A)(acc: (A,A)=>A)(expr: => A): A
def aggregate[A](f: => A): A
// Not primitive, but foundational
def sense[A](name: LSNS): A
def nbrvar[A](name: NSNS): A
def branch[A](cond: => Boolean)(th: => A)(el: => A): A
}
• Mechanisms for context-sensitiveness: nbr, nbrvar, sense
• Mechanisms for field evolution: rep
• Mechanisms for interaction: nbr
• Mechanisms for field domain restriction: aggregate, branch
• Reference formal system: field calculus [DVB16, DVPB15]

Aggregate Computing
Computing with ﬁelds II
Global-level semantics, intuitively
0
(x)=>x+1
true t<0,1>
()0
1
+
-
1
-1
ef(0,1)
ef
rep
0
(x)=>x+1
t
v0
t
v1
..
rep(0){(x)=>x+1}
nbr de
nbr{e}
φd=[d1→v1,..,dn→vn]

Aggregate Computing
Example: the channel I
def channel(src: Boolean, dest: Boolean, width: Double) =
distanceTo(src) + distanceTo(dest) <=
distBetween(src, dest) + width

Aggregate Computing
Example: the channel (full code)
def channel(src: Boolean, dest: Boolean, width: Double) =
distanceTo(src) + distanceTo(dest) <=
distBetween(src, dest) + width
def distanceTo(source: Boolean): Double =
G[Double](source, 0, _ + nbrRange(), nbrRange())
def distBetween(source: Boolean, target: Boolean): Double =
broadcast(source, distanceTo(target))
def G[V:OB](src: Boolean, field: V, acc: V=>V, metric: =>Double): V =
rep( (Double.MaxValue, field) ){ dv =>
mux(src) { (0.0, field) } {
minHoodMinus {
val (d, v) = nbr { (dv._1, dv._2) }
(d + metric, acc(v))
}
}
}._2
def broadcast[V:OB](source: Boolean, field: V): V =
G[V](source, field, x=>x, nbrRange())
def nbrRange(): Double = nbrvar[Double](NBR_RANGE_NAME)
def isSource = sense[Boolean]("source")
def isObstacle = sense[Boolean]("obstacle")

Aggregate Computing
Aggregate Programming Stack

Aggregate Computing
Ex. of concrete system: nbr counting in p2p, ad-hoc net
// STEP 1: CHOOSE INCARNATION
import it.unibo.scafi.incarnations.{ BasicActorP2P => Platform }
// STEP 2: DEFINE AGGREGATE PROGRAM SCHEMA
class Demo0C_AggregateProgram extends Platform.AggregateProgram {
override def main(): Any = foldhood(0){_ + _}(1)
}
// STEP 3: DEFINE MAIN PROGRAM
object Demo0C_MainProgram extends Platform.CmdLineMain
1) Demo_MainProgram -h 127.0.0.1 -p 9000
-e 1:2,4,5;2;3 --subsystems
127.0.0.1:9500:4:5
--program "demos.Demo_AggregateProgram"
2) Demo_MainProgram -h 127.0.0.1 -p 9500
-e 4;5:4
--program "demos.Demo_AggregateProgram"

Aggregate Computing
Summary: the AC approach to the engineering of CASs
The Aggregate Computing way
• Abstraction gap — i.e., the distance from the problem to the solution
=⇒ Abstractions close to problem domain
=⇒ Declarative approach – from how to what
=⇒ Layered approach – raising abstraction incrementally
• Capturing complex behaviours in a simple way
=⇒ Instrumental assumptions + effective building blocks
=⇒ Balance of top-down and bottom-up problem solving (sort of
match-in-the-middle)
• Supporting modularity and reusability
=⇒ Compositional approach
• Guiding engineering for resilience
=⇒ Adaptation by construction

Execution Platforms for Aggregate Computing
Outline
4 Summary

Aggregate computing and abstraction
(Partial) insensitiveness to system structure and situation details [BVPD16]
Aggregate behaviours are highly insensitive to:
• network size
• network density
• network topology
This makes algorithms intrinsically robust to failures and changes to working
conditions [VBDP15].
(Partial) insensitiveness to execution strategy
Note: network nodes ultimately correspond to components operating in some
context via sensors/actuators.
Aggregate computations can be carried out in different ways:
• Computing nodes and “native” local communication;
• Computations performed by a central server;
• Computations performed in the cloud; ...
Idea: opportunistically exploit the underlying infrastructure

(Fully operational) Device actors
Responsibilities (each one can be reiﬁed as an actor/subcomponent)
(i) Sensing/actuating
(ii) Aggregate program execution
(iii) Broadcasting/receiving the exports of computation to/from neighbours
(iv) Storing state (last computation, exports from neighbours)

Peer-to-peer
Peer-to-peer platform style
• Each device processes the aggregate program on-site and directly
communicates with other devices.
• Suited for ad-hoc networks.

Mediating server
Communication mediator
• Device-to-device communications are mediated by a server component.
• Hence, the neighbouring logic is moved away from devices.

Demo: server-based, mobile spatial net I

Demo: server-based, mobile spatial net II
import it.unibo.scafi.distrib.actor.server.{SpatialPlatform =>
SpatialServerBasedActorPlatform}
import it.unibo.scafi.incarnations.BasicAbstractActorIncarnation
import it.unibo.scafi.space.{Point2D, BasicSpatialAbstraction}
object Platform extends BasicAbstractActorIncarnation
with SpatialServerBasedActorPlatform
with BasicSpatialAbstraction with Serializable {
override val LocationSensorName: String = "LOCATION_SENSOR"
override type P = Point2D
override def buildNewSpace[E](elems: Iterable[(E,P)]): SPACE[E] =
new Basic3DSpace(elems.toMap) { override val proximityThreshold = 1.1 }
}
// STEP 2: DEFINE AGGREGATE PROGRAM SCHEMA
class AggregateProgram extends Platform.AggregateProgram {
def hopGradient(source: Boolean): Double = {
rep(Double.PositiveInfinity){
hops => { mux(source) { 0.0 } { 1+minHood(nbr{ hops }) } }
}
}
def main() = hopGradient(sense("source"))
}

Demo: server-based, mobile spatial net III
// STEP 3: DEFINE MAIN PROGRAMS
object ServerMain extends Platform.ServerCmdLineMain {
override def refineSettings(s: Platform.Settings) = {
s.copy(profile = s.profile.copy(
serverGuiActorProps = tm => Some(ServerGUIActor.props(Platform, tm))
))
}
}
object MainProgram extends Platform.CmdLineMain {
override def refineSettings(s: Platform.Settings) = {
s.copy(profile = s.profile.copy(
devGuiActorProps = ref => Some(DevGUIActor.props(Platform, ref))
))
}
override def onDeviceStarted(dm: Platform.DeviceManager,
sys: Platform.SystemFacade) = {
dm.addSensorValue(Platform.LocationSensorName, Point2D(dm.selfId%5,(dm.
selfId/5.0).floor))
dm.addSensorValue("source", dm.selfId==4)
dm.start
}
}

Computing server
Computation mediator
• The processing logic is moved away from devices.
• Devices send sensor values to the server and receive actuations.
• The server has to keep state (sensor values, neighbour exports).

Cloud-based
Aggregate computing cloud
• Like server-based solution: the centralisation consists in the cloud access point.
• The whole computational ﬁeld stored as a big data.
• The cloud-based execution is structured as stateless services insisting on a
shared database.
Relaxation of consistency constraints; in-memory; space-based partitioning
& locality
• Plausible technology: RESTful WS on GAE + Redis/Datastore

Wait! Why are you introducing centralisations? I
p2p
• Processing occurs locally
• The export of computation has to be broadcasted to the neighbourhood
• Sensor and actuator values readily available
• Device-to-device communication may be onerous
server/cloud
• Sensor values upstream, actuations downstream
⇒ convenient when sensor readings do not change quickly
• Neighbour exports readily available
• Necessary when p2p interactions not supported at infrastructure-level
• Because of (i) communication technology, or (ii) logical neighbouring relation
• Necessary when devices have no processing capabilities (i.e., may only
sense/act/communicate)
• Even if p2p is possible, may still be useful for optimisations or for easier management

Wait! Why are you introducing centralisations? II
Elements to be considered
• Number of communication acts
• Frequency of execution
• Energetic issues
• Other costs (e.g., pay-per-use in cloud)
Case study (simulation): crowd management in urban mass event
• Test-bed used in [APNF13]
• Real-world traces
• Device broadcasts in 100m range

Wait! Why are you introducing centralisations? III
0 20 40 60 80 100 120 140 160 180
Time (simulated minutes)
0
50
100
150
200
Averagenumberofroundsexecuted
Rounds executed locally
Full P2P
Hybrid L1
Hybrid L2
Full cloud
0 20 40 60 80 100 120 140 160 180
0
2000
4000
6000
8000
10000
12000
Averagenumberofroundsexecuted
Rounds executed in cloud
Full P2P
Hybrid L1
Hybrid L2
Full cloud
0 20 40 60 80 100 120 140 160 180
0
100
200
300
400
500
600
700
800
Numberofdevices
Devices subject to a warning
Full P2P
Hybrid L1
Hybrid L2
Full cloud
Hybrid L1: warning devices execute in cloud – Hybrid L2: dispersal devices execute in cloud

(Dynamic) Hybrid-style platform
Key idea
• Use available infrastructure and adapt so as to maximize QoS!
Dynamic and opportunistic exploitation of networking/computing resources.
• Computation may ﬂow "up" and "down" depending on context and contingencies.
• In this sense, AC is similar to MapReduce—but for distributed and situated
computations.

Summary
Outline
4 Summary

Summary
Summary: key ideas and future directions
Aggregate programming
• An (((((((
programmingengineering approach to CASs
• Formally grounded in the Field Calculus
• Allows to compose “emergent” phenomena
• Provides layers of building blocks (proven to self-stabilise!)
• Comes with a Scala framework (SCAFI) for building aggregate systems
The abstract model is decoupled from the execution strategy
• Aggregate computing is suitable for exec across several platforms/infrastructures
• From ad-hoc networks to cloud/fog computing
• It could be extended to dynamically exploit available and heterogeneous
infrastructure
Future work
• Evolve SCAFI into a framework supporting scalable computations in cluster- and
cloud-based systems
• What does it take to set up a framework for adaptive execution strategies?

Appendix References
References I
[APNF13] Bernhard Anzengruber, Danilo Pianini, Jussi Nieminen, and Alois Ferscha.
Predicting social density in mass events to prevent crowd disasters.
In Proceedings of SocInfo 2013, pages 206–215, 2013.
[BPV15] Jacob Beal, Danilo Pianini, and Mirko Viroli.
Aggregate Programming for the Internet of Things.
IEEE Computer, 2015.
[BV15] Jacob Beal and Mirko Viroli.
Space–time programming.
Phil. Trans. R. Soc. A, 373(2046):20140220, 2015.
[BVPD16] Jacob Beal, Mirko Viroli, Danilo Pianini, and Ferruccio Damiani.
Self-adaptation to device distribution changes in situated computing
systems.
In IEEE Conference on Self-Adaptive and Self-Organising Systems (SASO
2016). IEEE, 2016.
To appear.

Appendix References
References II
[CV16] Roberto Casadei and Mirko Viroli.
Towards aggregate programming in Scala.
In First Workshop on Programming Models and Languages for Distributed
Computing, PMLDC ’16, pages 5:1–5:7, New York, NY, USA, 2016. ACM.
[Duc13] Matt Duckham.
Decentralized Spatial Computing - Foundations of Geosensor Networks.
Springer, 2013.
[DVB16] Ferruccio Damiani, Mirko Viroli, and Jacob Beal.
A type-sound calculus of computational ﬁelds.
Science of Computer Programming, 117:17 – 44, 2016.
[DVPB15] Ferruccio Damiani, Mirko Viroli, Danilo Pianini, and Jacob Beal.
Code mobility meets self-organisation: A higher-order calculus of
computational ﬁelds.
volume 9039 of Lecture Notes in Computer Science, pages 113–128.
Springer International Publishing, 2015.

Appendix References
References III
[VBDP15] Mirko Viroli, Jacob Beal, Ferruccio Damiani, and Danilo Pianini.
Efﬁcient engineering of complex self-organising systems by self-stabilising
ﬁelds.
2015.

On Execution Platforms for Large-Scale Aggregate Computing

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to On Execution Platforms for Large-Scale Aggregate Computing

Similar to On Execution Platforms for Large-Scale Aggregate Computing (20)

More from Roberto Casadei

More from Roberto Casadei (17)

Recently uploaded

Recently uploaded (20)

On Execution Platforms for Large-Scale Aggregate Computing