programming actor-based collective adaptive systems

Programming Actor-based Collective Adaptive Systems

Roberto Casadei Mirko Viroli

Department of Computer Science and Engineering

University of Bologna

AGERE! Workshop, co-located with SPLASH, Amsterdam 2016

Slides available at http://www.slideshare.net/RobertoCasadei/presentations

R. Casadei (Università di Bologna) Programming Actor-based CASs PMLDC 2016 1 / 23

http://www.slideshare.net/RobertoCasadei/presentations

Outline

1 Aggregate Computing: the Basics

2 Aggregate Computing and the Actor Model

3 Conclusion


Aggregate Computing: the Basics

Outline



3 Conclusion



Problem: design/programming CASs

Collective/Complex Adaptive Systems (CASs)

Structure: Environment + (Mobile, Large-scale) Networks of { people + devices }

Global interpretation: embedded devices collectively form a “diffused” computational system



An approach to CAS development

Issues⇒ approach

• Large-scale⇒ decentralised coordination• Situatedness + distributed autonomy⇒ substantial unpredictability⇒ self-*• Complex collective behavior⇒ good abstractions, layered approach, compositionality

Shifting the mindset: from local to global

• Declarativeness and the global viewpoint• Crowd-aware services• Failure recovery of enterprise services• Distributed monitoring and reacting (e.g., temperature, fire)

• Expected global behavior vs. traditional device-centric interface

⇒ Aggregate Programming [BPV15]: a paradigm for programming whole aggregates of devices.



Aggregate programming [BPV15]From the local/device-centric viewpoint to the global/aggregate viewpoint

Aggregate programming: what

Goal: programming the collective behaviour of aggregates (of devices)⇒ global-to-local

Aggregate programming: how

Prominent approach (generalizing over several prior approaches and strategies [BDU+12])founded on field calculus and self-org patterns• Computational fields as unifying abstraction of local/global viewpoints



Computational fields [DVB16]

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

• “Distributed” data structure working as the global abstraction• The bridge abstraction between local behavior and global behavior

Discrete systems as an approximation ofspacetime



SCAFI: Scala with Computational FieldsGoal: bring Aggregate Computing to the field of mainstream software development

WhatSCAFI [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, efficient impl. of the Higher-Order Field Calculus

semantics [DVPB15]• Distributed platform for execution of aggregate systems.

• Support for multiple architectural styles and system configurations.• Actor-based implementation (based on Akka).

Where• https://bitbucket.org/scafiteam/scafi

libraryDependencies += "it.unibo.apice.scafiteam" % "scafi-core_2.11" % "0.1.0" // on Maven Central


https://bitbucket.org/scafiteam/scafi


Aggregate (computing) systems & Execution model

Structure⇒ (network/graph)

• A set of devices.• Each device is able to communicate with a subset of devices known as its neighbourhood.

Dynamics

Each device is given the same aggregate program and works at async / partially-sync rounds:

(1) Retrieve context⇐ Messages from neighbours⇐ Sensor values

(2) Aggregate program execution⇒ export + output

(3) Broadcast export to neighbourhood(4) Execute actuators



Computing with fields I

Expressing aggregate/field computations in SCAFItrait 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 and partitioning: aggregate, branch

• Reference formal system: field calculus [DVB16, DVPB15]



Computing with fields IIGlobal-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]



Example: the channel I



Example: the channel II

Each device is given the same aggregate program:class ChannelProgram extends AggregateProgram with ChannelAPI {

def main = channel(isSource, isDestination, width)}

Gradient: field of min distances from source(s)

def channel(src: Boolean, dest: Boolean, width: Double) =distanceTo(src) + distanceTo(dest) <= distBetween(src, dest) + width



Example: the channel III1 trait ChannelAPI extends Language with Builtins {2 def channel(src: Boolean, dest: Boolean, width: Double) =3 distanceTo(src) + distanceTo(dest) <= distBetween(src, dest) + width45 def G[V:OB](src: Boolean, field: V, acc: V=>V, metric: =>Double): V =6 rep( (Double.MaxValue, field) ){ dv =>7 mux(src) { (0.0, field) } {8 minHoodMinus {9 val (d, v) = nbr { (dv._1, dv._2) }

10 (d + metric, acc(v))11 }12 }13 }._21415 def broadcast[V:OB](source: Boolean, field: V): V =16 G[V](source, field, x=>x, nbrRange())1718 def distanceTo(source: Boolean): Double =19 G[Double](source, 0, _ + nbrRange(), nbrRange())2021 def distBetween(source: Boolean, target: Boolean): Double =22 broadcast(source, distanceTo(target))2324 def nbrRange(): Double = nbrvar[Double](NBR_RANGE_NAME)25 def isSource = sense[Boolean]("source"); def isDestination = sense[Boolean]("destination")26 }



Aggregate Programming Stack


Aggregate Computing and the Actor Model

Outline



3 Conclusion



Embedded actors

• The Actor model & distributed systems – a good fit• Actors for distributed situated systems and IoT – a natural extension• Embedded actor [HCS14]: plain Actor model + situatedness.• Actors for avatars [Zam16]

How can actors be used to implement complex decentralised behaviours?



(Fully operational) Device actors

Responsibilities

(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)

• Each one may be reified as an actor/subcomponent



Execution strategies and architectures [VCP16]



Setup of an (actor-based) aggregate system// STEP 1: CHOOSE INCARNATIONimport scafi.incarnations.{ BasicActorP2P => Platform }import Platform.{AggregateProgram,Settings,PlatformConfig}

// STEP 2: DEFINE AGGREGATE PROGRAM SCHEMAclass Program extends AggregateProgram with CrowdAPI {// Specify a "dangerous density" aggregate computationoverride def main(): Any = dangerousDensity()

}

// STEP 3: PLATFORM SETUPval settings = Settings()val platform = PlatformConfig.setupPlatform(settings)

// STEP 4: NODE SETUPval sys = platform.newAggregateApplication()val dm = sys.newDevice(id = Utils.newId(),

program = Program,neighbours = Utils.discoverNbrs())

val devActor = dm.actorRef // get underlying actor



Integrating Aggregate Computing into actor-based applications

Key idea

• AC system as coordinator or CAS service within alarger system.

• In particular, AC actors can integrate withapplication-specific actors.

– Through the AC system/actor’s in/out messageinterfaces

• This integration can be achieved in multiple ways:

– Application actors as sensors for device actors– Application actors as managers of the aggregate

platform (e.g., fine-tune neighbourhood)– Application actors as observers of device actors– Device actors as actuators for application logic


Conclusion

Outline



3 Conclusion


Conclusion

Summary: key ideas

Aggregate programming

• An programmingengineering approach to CASs, formally grounded in the Field Calculus.• Allows to compose “emergent” phenomena & defines layers of (self-stabilizing) building blocks.• Comes with a Scala framework (SCAFI) for building aggregate systems.

Aggregate computing and the Actor model

• Actors for implementing aggregate systems.• Application actors interacting with aggregate systems through message-oriented boundaries.• Plain actors + embedded actors + "aggregate" actors seems to be nice mix for IoT apps.

Future work• Evolve SCAFI to support scalable computations in cluster- and cloud-based systems.• What does it take to set up a framework for adaptive execution strategies?


Conclusion

Question time

Questions?


Conclusion

What is an aggregate program?

• May take the form of field calculus programs (in the representation given by some PL)• Actually, the field calculus is like FJ for Java, or the lambda calculus for Haskell• An aggregate program consists of

1) A set of function definitions2) A body of expressions.

• Example: an aggregate program in SCAFIclass MyProgram extends AggregateProgram with MyAPI {def isSource = sense[Boolean]("source")

// Entry point for executionoverride def main() = gradient(isSource)

}

– Each device of the aggregate system is given an instance of MyProgram.– Each device repeatedly runs the main method at async rounds of execution.


Conclusion

How do AC achieve reliable CAS engineering?

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


Conclusion

On aggregate computing and abstraction

(Partial) insensitiveness to system structure and situation details [BVPD16a]

Aggregate behaviours are highly insensitive to network size/density/topology [BVPD16b].It makes algorithms intrinsically robust to failures & changes to working conditions [VBDP15].

(Partial) insensitiveness to execution strategy

Note: the nodes of an aggregate system are the logical counterparts of components operating insome context via sensors/actuators.Aggregate computations can be carried out in different ways [VCP16]:

• Computing nodes and “native” local (P2P) communication;• Computations performed by a central server;• Computations performed in the cloud; ...

Idea: opportunistically exploit the underlying infrastructure


Conclusion

(On execution strategies/architectures) Wait! Why are youintroducing 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


Conclusion

(On execution strategies/architectures) Wait! Why are youintroducing centralisations? II

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


Conclusion

(On execution strategies/architectures) Wait! Why are youintroducing centralisations? III

Elements to be considered

• Number of communication acts

• Frequency of execution

• Energetic issues

• Other costs (e.g., pay-per-use in cloud)

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.


Conclusion

The origins: space-time programming, bio-inspired patterns, ... I

Decentralised spatial computing [Duc13] – Computing “somewhere”

• Location-related information + spatial constraints to communication

Space-time programming [BV15]

• Computation expressed in terms of the physical space/time in which it occurs

• Discrete system vs. continuous space-time


Conclusion

The origins: space-time programming, bio-inspired patterns, ... IIBio-inspired self-organisation patterns [FMSM+13]

Generalizing from several prior approaches and strategies [BDU+12]

• Making device interaction implicit – e.g., TOTA

• Means to compose geometric/topological constructions – e.g., Origami Shape Language

• General space-time computing approaches – e.g., Protelis, Proto, MGS

• Automatically splitting computational behavior for cloud-style execution – e.g., MapReduce


Conclusion

Related works

[BDU+12] provides an analysis of several prior (spatial computing) approaches for CASdevelopment.

A number of approaches sharing one or more aspects include:

• ActorSpace [CA94] extends Actors with destination patterns.• ActorNet [KSMA06] is a mobile actor platform for WSNs.• AmbientTalk [VCMB+07] is a DSL for orchestrating service discovery and composition in

MANETs.• Bulk Synchronous Parallel (BSP) model [Val90] (and BSP-based models such as

Diderot [RS15]) – based on a sequence of parallel supersteps separated by globalsynchronization barriers.

• Kairos [GGG05]: a macro-programming approach to WSNs


Appendix References

References I

[BDU+12] Jacob Beal, Stefan Dulman, Kyle Usbeck, Mirko Viroli, and Nikolaus Correll.Organizing the aggregate: Languages for spatial computing.CoRR, abs/1202.5509, 2012.

[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.

[BVPD16a] 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

[BVPD16b] Jacob Beal, Mirko Viroli, Danilo Pianini, and Ferruccio Damiani.Self-adaptation to device distribution changes in situated computing systems.2016.To appear.

[CA94] Christian J Callsen and Gul Agha.Open heterogeneous computing in actorspace.Journal of Parallel and Distributed Computing, 21(3):289–300, 1994.

[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.


Appendix References

References III

[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 of computationalfields.volume 9039 of Lecture Notes in Computer Science, pages 113–128. SpringerInternational Publishing, 2015.

[FMSM+13] Jose Luis Fernandez-Marquez, Giovanna Di Marzo Serugendo, Sara Montagna,Mirko Viroli, and Josep Lluís Arcos.Description and composition of bio-inspired design patterns: a complete overview.Natural Computing, 12(1):43–67, 2013.


Appendix References

References IV

[GGG05] Ramakrishna Gummadi, Omprakash Gnawali, and Ramesh Govindan.Macro-programming wireless sensor networks using kairos.In International Conference on Distributed Computing in Sensor Systems, pages126–140. Springer, 2005.

[HCS14] Raphael Hiesgen, Dominik Charousset, and Thomas C Schmidt.Embedded actors – towards distributed programming in the IoT.In 2014 IEEE Fourth International Conference on Consumer Electronics Berlin(ICCE-Berlin), pages 371–375. IEEE, 2014.

[KSMA06] YoungMin Kwon, Sameer Sundresh, Kirill Mechitov, and Gul Agha.Actornet: An actor platform for wireless sensor networks.In Proceedings of the fifth international joint conference on Autonomous agents andmultiagent systems, pages 1297–1300. ACM, 2006.


Appendix References

References V

[RS15] John Reppy and Lamont Samuels.Bulk-synchronous communication mechanisms in diderot.2015.

[Val90] Leslie G Valiant.A bridging model for parallel computation.Communications of the ACM, 33(8):103–111, 1990.

[VBDP15] Mirko Viroli, Jacob Beal, Ferruccio Damiani, and Danilo Pianini.Efficient engineering of complex self-organising systems by self-stabilising fields.2015.

[VCMB+07] Tom Van Cutsem, Stijn Mostinckx, Elisa Gonzalez Boix, Jessie Dedecker, andWolfgang De Meuter.Ambienttalk: object-oriented event-driven programming in mobile ad hoc networks.In Chilean Society of Computer Science, 2007. SCCC’07. XXVI InternationalConference of the, pages 3–12. IEEE, 2007.


Appendix References

References VI

[VCP16] Mirko Viroli, Roberto Casadei, and Danilo Pianini.On execution platforms for large-scale aggregate computing.In Proceedings of the 2016 ACM International Joint Conference on Pervasive andUbiquitous Computing: Adjunct, pages 1321–1326. ACM, 2016.

[Zam16] Franco Zambonelli.Towards a general software engineering methodology for the internet of things.arXiv preprint arXiv:1601.05569, 2016.
