Computing at the aggregate level

Danilo Pianini, Mirko Viroli, Roberto Casadei

University of Bologna
  • "Situatedness"
  • Unpredictability (humans)
  • High density
  • Heterogeneity
  • Mobility
  • Openness
  • Safety concerns

Engineering this thing I

Throw everything at the cloud, and let it process it

  • Lots of information is only locally relevant
  • Misuse of bandwidth and computational power
  • Does not play well with high densities
  • Privacy concerns

Engineering this thing II

Rely on opportunistic communication

write software with nature inspiration
  • Communication issues
  • Lack of composability
  • Local-to-global (kinda bottom-up)
  • Side effects on multiple scales


something as small as the flutter of a butterfly’s wing can ultimately cause a typhoon halfway around the world

  • Controlling emergency is hard
  • Engineers don’t like lack of control

The good part

Basically the foundation of

  • Stigmergy
  • Nature inspired coordination

simple behavioural and communicational rules, global effects

Side effects on multiple scales

simple local behaviours


complex global behaviour

effects reified on different scales

The bad part

emergent behaviour is difficult to forecast

simple behavioural and communicational rules, global effects


small mistakes, global consequences

The bad part

  • hard to engineer properly
  • no composability
  • poor reusability

nature can bet on numbers, we can't.

Aggregate programming: idea


Aggregate programming: idea

logical network

Aggregate programming: idea

each device holds some values

Aggregate programming: idea

interpret such values as a field in space-time

Aggregate programming: idea

(computational field)

Aggregate programming: idea

↑↑↑ Compute on these things ↑↑↑

Aggregate programming

  • our machine is the ensemble of situated devices
  • computing happens by means of combining fields

    straightforward mapping to functional languages

    • compositionality by function composition (divide et impera)
    • nothing new, software people know them already!
    • networking and platform hidden under the hood

↓Nice place to work↓

Reusable aggregate library

Self-stabilizing blocks

Language primitives


Device abstraction (sensors, actuators)

Underlying platform (cloud? actors? LoRaWAN?)

The feel of it

red means overcrowding

The feel of it

import ...
// A field counting people around each point in space
def countNearby(range) {
  let human = rep(h <- env.has("human")) { h };
  sumHood PlusSelf(
    mux(human && nbrRange() < range) { 1 } else { 0 })

actual code from Modelling and simulation of Opportunistic IoT Services with Aggregate Computing

The feel of it

import ...
// A field estimating people density in an area
def densityEst(p, range, w) {
  countNearby(range) / (p * pi * range ^ 2 * w)

(actual code from Modelling and simulation of Opportunistic IoT Services with Aggregate Computing)

The feel of it

import ...
// A field of boolean, true if the area is overcrowded
def dangerousDensity(p, range, dangerousDensity, groupSize, w) {
  let partition = S(range, nbrRange);
  let localDensity = densityEst(p, range, w);
  let avg = summarize(partition, sum, localDensity, 0)
    / summarize(partition, sum, 1, 0);
  let count = summarize(partition, sum, 1 / p, 0);
  avg > dangerousDensity && count > groupSize

(actual code from Modelling and simulation of Opportunistic IoT Services with Aggregate Computing)

The feel of it

import ...
/* A field that partitions space in safe, overcrowded,
   and overcrowding areas, given a certain time window */
def crowdTracking(p, range, w, maxDense,
      dangerThr, groupSize, time) {
  if (isRecentEvent(densityEst(p, range, w) > maxDense, time)) {
    if (dangerousDensity(p, range, dangerThr, groupSize, w)) {
    } else { atRisk() }
  } else { none() }
// Application code: crowd density tracking in a 60s window
crowdTracking(0.005, 30, 0.25, 1.08, 2.17, 300, 60);

(actual code from Modelling and simulation of Opportunistic IoT Services with Aggregate Computing)

Engineering toolchain


  • Requirements:
    • Devices exchange data with their “neighbors”
      • Whatever a “neighborhood” is
  • No assumption on the deployment
  • No assumption on communication means


Computation may happen:

  • on each device
  • on the edge
  • on the cloud

the aggregate software does not change at all


No magic, deployment-specific complexity is simply incapsulated under the hood

divide et impera

  • Write the application thinking of what it should do
  • Write the platform thinking of where it should run
    • And reuse it for future applications

Silver bullet?


  • Very handy for expressing the "coordination"
  • Other paradigms are better at the good ol' "local" programming
    • e.g. I wouldn't develop a GUI in aggregate...
    • (although technically doable)
  • The final software is usually a mixture of paradigms

abstraction is not a free lunch

abstraction raised by hiding networking and protocols


  • engineering applied to the problem, regardless of the underlying platform
    • first what
    • then where


  • language-based, top-down, global-to-local
    • easier design
    • high composability
    • better guarantees


  • rich set of tools
  • lots of work to do on optimization and security

enabling technology for projects dealing with the Internet of Things and Smart Cities

Appendix: play with it!

A tutorial for learning Protelis is available

Scafi is better learned by reading a paper (for now)