On Execution Platforms for Large-Scale Aggregate Computing

On Execution Platforms for Large-Scale AggregateComputing

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 aSuperorganism 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 andspace 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 field calculus and self-org patterns• Computational fields 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) systemsStructureA set of networked devices• Each one is given the same field calculus program.

• FC has mechanisms to differentiate local executions within a globalbehaviour.• 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 ofexecution

(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

WhatSCAFI [CV16] is an integrated framework for building systems with aggregateprogramming.

• Scala-internal DSL for expressing aggregate computations.• Linguistic support + execution support (interpreter/VM)• Correct, complete, efficient implementation of the HOFC semantics

• Distributed platform for execution of aggregate systems.• Support for multiple architectural styles and system configurations.• Actor-based implementation (based on Akka).

Wherehttp://scafi.apice.unibo.it (a better release soon)

Why Scala?


http://scafi.apice.unibo.it

Aggregate Computing

Computational fields

• (Abstract interpretation) Mapping space-time to computational objects• (Concrete interpretation) Mapping devices to values: φ : δ 7→ `

• “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): Adef nbr[A](expr: => A): Adef foldhood[A](init: => A)(acc: (A,A)=>A)(expr: => A): Adef aggregate[A](f: => A): A

// Not primitive, but foundationaldef sense[A](name: LSNS): Adef nbrvar[A](name: NSNS): Adef 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 fields 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+1t

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 INCARNATIONimport it.unibo.scafi.incarnations.{ BasicActorP2P => Platform }

// STEP 2: DEFINE AGGREGATE PROGRAM SCHEMAclass Demo0C_AggregateProgram extends Platform.AggregateProgram {override def main(): Any = foldhood(0){_ + _}(1)

}

// STEP 3: DEFINE MAIN PROGRAMobject Demo0C_MainProgram extends Platform.CmdLineMain

1) Demo_MainProgram -h 127.0.0.1 -p 9000-e 1:2,4,5;2;3 --subsystems127.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 workingconditions [VBDP15].

(Partial) insensitiveness to execution strategy

Note: network nodes ultimately correspond to components operating in somecontext 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 reified 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 directlycommunicates 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.BasicAbstractActorIncarnationimport it.unibo.scafi.space.{Point2D, BasicSpatialAbstraction}

object Platform extends BasicAbstractActorIncarnationwith SpatialServerBasedActorPlatformwith 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 SCHEMAclass 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 PROGRAMSobject 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 field 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 onlysense/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

Avera

ge n

um

ber

of

rounds

execu

ted

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

Avera

ge n

um

ber

of

rounds

execu

ted

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

Num

ber

of

devic

es

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 flow "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 directionsAggregate 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 computingsystems.In IEEE Conference on Self-Adaptive and Self-Organising Systems (SASO2016). 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 DistributedComputing, 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 fields.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 ofcomputational fields.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.Efficient engineering of complex self-organising systems by self-stabilisingfields.2015.


On Execution Platforms for Large-Scale Aggregate Computing

Science

Transcript of On Execution Platforms for Large-Scale Aggregate Computing