## 4 Application to Aggregate Computing  
Aggregate Computing[15; 66] is a programming paradigm arising from the general need for capturing, linguistically and computationally, the self-organizing behavior of a (possibly large-scale, dynamic) collection of components. Its core idea is to shift from the traditional _device-centric_ viewpoint, which focusses on the behavior of each individual agent, to an _aggregate-centric_ viewpoint that emphasizes the global behavior of a _collective_ or _aggregate system_ (i.e., a whole set of interacting autonomous entities). This stance is not just conceptual, but also pragmatical: the collective logic can be expressed as an _aggregate program_ that is executed by an _\"aggregate virtual machine\"_ consisting of an entire (possibly distributed) system of networked agents. Aggregate programs are written in some _aggregate programming Domain-Specific Language (DSL)_ such as the standalone DSL _Protelis_[16] or the Scala-internal DSL _ScaFi_[17]. In this paper, we do not extend the aggregate computing model itself, but rather describe it as an instance of the model outlined in Section 3, as follows. A logical aggregate system is a cyber system, and its deployment is an allocation map between its component and a platform system. An aggregate cyber system comprises the following elements:  
* _Global program_. All devices run the same program \(\beta\). In aggregate computing, it is possible to express collective behavior through a single, global program which yields different results and actions when _interpreted_ against different contexts. Notice that other macro-programming languages [67] adopt a different approach where local programs for the individual nodes are obtained by _compilation_ of a global program, so leading to multiple \(\beta\)s.
* _Context_ and _Local computation_. The same program is meant to be _iteratively_ and _asynchronously_ evaluated _locally_ against each device's up-to-date context, which consists of a tuple extracted from \(\kappa\) with (i) a map of the most recent sensor values for the named sensors in \(\sigma\) used by the program itself, and (ii) a map from neighbors to their most recent exported value. That is, only the last message for each neighbor is to be stored. Moreover, messages are usually retained for an application-specific amount of time. This suffices to guarantee progression and steering (via self-organization). * _Program output_. According to the aggregate operational semantics [64], the output of a local execution of an aggregate program is a _vtree_, i.e., a tree of values. A vtree already embeds both (i) local state to support stateful computations; (ii) information needed for coordination, to be broadcast to neighbors; and (iii) prescriptions about actuations to be performed by \(\alpha\). In other words, the output of an aggregate program is directly usable as an _export_ (see Section 3.1.1). * _Messages_. Messages sent to neighbors through \(\chi\) components are (specific parts of) vtrees. Details about _how_ compositions of aggregate computing constructs give rise to self-organizing behavior are deeply covered in [64]. It suffices to say that aggregate programs can be defined as _compositions_ of functional blocks that describe how a system should collectively behave through a manipulation of _computational fields_[64], i.e., dynamic maps from logical devices to computational values. However, each device computes against partial fields given by the most recent information gathered from neighbors. The key insight delivered in this paper is that the execution of such aggregate programs can be \"pulverized\" into micro-steps of sensing, computation, interaction, and actuation (Section 3.1) that can also be distributed across different machines.