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

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, ﬁre)
• 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 ﬁeld calculus and self-org patterns
• Computational ﬁelds as unifying abstraction of local/global viewpoints

Computational ﬁelds [DVB16]
• (Abstract interpretation) Mapping space-time to computational objects
• (Concrete interpretation) Mapping devices to values: φ : δ →
• “Distributed” data structure working as the global abstraction
• The bridge abstraction between local behavior and global behavior
Discrete systems as an approximation of
spacetime

SCAFI: Scala with Computational Fields
Goal: bring Aggregate Computing to the field of mainstream software development
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, 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

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 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 and partitioning: aggregate, branch
• Reference formal system: field calculus [DVB16, DVPB15]

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]

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: ﬁeld 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 III
1 trait ChannelAPI extends Language with Builtins {
2 def channel(src: Boolean, dest: Boolean, width: Double) =
3 distanceTo(src) + distanceTo(dest) <= distBetween(src, dest) + width
4
5 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 }._2
14
15 def broadcast[V:OB](source: Boolean, field: V): V =
16 G[V](source, field, x=>x, nbrRange())
17
18 def distanceTo(source: Boolean): Double =
19 G[Double](source, 0, _ + nbrRange(), nbrRange())
20
21 def distBetween(source: Boolean, target: Boolean): Double =
22 broadcast(source, distanceTo(target))
23
24 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 ﬁt
• 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 reiﬁed as an actor/subcomponent

Execution strategies and architectures [VCP16]

Setup of an (actor-based) aggregate system
// STEP 1: CHOOSE INCARNATION
import scafi.incarnations.{ BasicActorP2P => Platform }
import Platform.{AggregateProgram,Settings,PlatformConfig}
// STEP 2: DEFINE AGGREGATE PROGRAM SCHEMA
class Program extends AggregateProgram with CrowdAPI {
// Specify a "dangerous density" aggregate computation
override def main(): Any = dangerousDensity()
}
// STEP 3: PLATFORM SETUP
val settings = Settings()
val platform = PlatformConfig.setupPlatform(settings)
// STEP 4: NODE SETUP
val 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 a
larger system.
• In particular, AC actors can integrate with
application-speciﬁc actors.
– Through the AC system/actor’s in/out message
interfaces
• 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., ﬁne-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 & deﬁnes 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 definitions
2) A body of expressions.
• Example: an aggregate program in SCAFI
class MyProgram extends AggregateProgram with MyAPI {
def isSource = sense[Boolean]("source")
// Entry point for execution
override 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 in
some 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 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

Conclusion
introducing 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
introducing 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 ﬂow "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, ... II
Bio-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 CAS
development.
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 global
synchronization 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 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.

Appendix References
References III
[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.
[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, pages
126–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 ﬁfth international joint conference on Autonomous agents and
multiagent 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.
Efﬁcient engineering of complex self-organising systems by self-stabilising ﬁelds.
2015.
[VCMB+
07] Tom Van Cutsem, Stijn Mostinckx, Elisa Gonzalez Boix, Jessie Dedecker, and
Wolfgang De Meuter.
Ambienttalk: object-oriented event-driven programming in mobile ad hoc networks.
In Chilean Society of Computer Science, 2007. SCCC’07. XXVI International
Conference 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 and
Ubiquitous 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.

Programming Actor-based Collective Adaptive Systems

More Related Content

What's hot

Viewers also liked

Similar to Programming Actor-based Collective Adaptive Systems

More from Roberto Casadei

Recently uploaded

Programming Actor-based Collective Adaptive Systems