AbU: A Calculus for Distributed Event-driven Programming with Attribute-based Interaction

In recent years, event-driven programming languages, in particular those based on Event Condition Action (ECA) rules, have emerged as a promising paradigm for implementing ubiquitous and pervasive systems. These implementations are mostly centralized, where a single server (often in the cloud) collects and processes all the inputs from the environment. In fact, placing the computation on the nodes interacting with the environment requires suitable abstractions for eﬀective communication and coordination of (possibly large) ensembles of these distributed components —abstractions that current ECA languages are still missing. To this end, in this paper we present AbU, a calculus for modeling and reasoning about ECA-based systems with attribute-based communication . The latter is an interaction model recently introduced for the coordination of (possibly large) families of nodes: communication is similar to broadcast but the actual receivers are selected on the spot, by means of predicates over nodes properties. Thus, the programmer can specify interactions between nodes in a declarative way, abstracting from details such as nodes identity, number, or even their existence, without the need for a central server: the computation is moved on the “edge”, thus improving reliability, scalability, privacy and security. After having deﬁned syntax and formal semantics of AbU, we showcase its expressiveness by providing some example applications and the encoding of AbC, the archetypal calculus with attribute-based communication. Then, we focus on two key properties of reactive systems: stabilization (i.e., termination of internal steps) and conﬂuence . For both these properties we provide formal semantic deﬁnition, suﬃcient syntactic conditions on AbU systems, and algorithms to statically check such conditions. Hence, AbU is both a basis for the formal analysis of event-driven architectures with attributed-based interaction, and a reference model for a full-ﬂedged language for IoT and edge computing.


Introduction
The ever-growing ubiquitous and pervasive systems, like the (Industrial) Internet of Things, smart homes, smart cities, autonomous agents, etc, are characterized by many complex computational aspects, such as distributed computing, dynamic network topologies, context-awareness, real-time data generated by sensors and users, strict latency bounds, etc.In order to deal with these aspects, applications for ubiquitous and pervasive systems have to efficiently handle events, such as sensor inputs, context changes, and changes in the internal state of components.It is therefore not surprising that event-driven programming has emerged as the prominent paradigm for the development of ubiquitous and pervasive applications [1,2]; indeed, this paradigm can be found in various commercial frameworks like IFTTT, Samsung SmartThings, Microsoft

D R A F T
Power Automate, Zapier, etc.In this approach, the behavior of a system is defined by a set of rules (called also "applets", "zaps", "routines", "flows", and so on) following the well-known Event Condition Action (ECA) structure, originally from the field of active databases [3]: Intuitively, the meaning of this rule is: when Event occurs, if Condition is satisfied then execute Action.
Thus, an ECA system can react to an event (e.g., a variable change or a signal from a sensor) by executing one or more actions, which can update the internal state of the node or act on the environment via some actuator.Of course, the effect caused by the action of a rule can trigger other rules, and so on.However, in most current models and implementations of this paradigm, the rules are stored on, and executed by, a central computing entity, possibly hosted on some server on the cloud and accessible via the Internet.The devices of the system do not communicate and coordinate with each other but with this central node/cloud service only.Although simple, such a centralized architecture suffers of several disadvantages.First, it does not scale well: the increase of IoT and smart devices is going to produce a massive amount of data [4], and transferring, storing and processing this data in cloud data centers will overload network channels.As a consequence, cloud servers will not be able to guarantee acceptable transfer rates and response times; moreover, sending all this data back and forth on the network is a big waste of energy.Secondly, the dependence on Internet connections and of a central node/cloud service hinders availability, which is also a critical requirement for many IoT and other pervasive and autonomic applications; e.g., a smart door lock may be stuck because the server is not reachable.Third, smart and IoT devices often deal with sensible and personal data (think of, for instance, health sensors, surveillance cameras, etc) that the user would prefer to not share with some untrusted server on the cloud.Finally, the dependence of external services increases the attack surface of the smart system; e.g., an attacker can open a house front door, taking advantage of some vulnerability on the server communicating with the door, and unknown to the user.
For all these reasons, in recent years there is a strong and growing interest in the so-called edge computing paradigm [4,5], which aims to move the computation away from cloud data centers towards the "edge" of the network, i.e., the smart objects which are the sources of data.This approach allows to mitigate the previous issues, as it reduces data transfers between the edge and the center of the network -in fact, there can be no center at all, thus increasing scalability, resilience, and security.
At the same time, placing the application logic on many nodes in a truly distributed and decentralized setting, introduces new issues and challenges.In particular, it requires suitable mechanisms and abstractions for communication and coordination of (possibly large) ensembles of distributed components.Traditional point-to-point communication mechanisms (like sockets, request/reply protocols or agent-like message passing) are not quite suited because they require strong coupling between parties, increasing the burden on the programmer, and are hardly scalable to large sets of components.A novel mechanism recently introduced to overcome these limitations is attribute-based communication [6,7,8], a loosely coupled message-oriented interaction model specifically designed for coordinating large numbers of components.The key aspect of attribute-based communication is that the actual receivers are selected "on the fly" by means of predicates over node attributes; dually, a node can "filter" incoming messages by means of predicates.Using a syntax similar to AbC [6] (the archetypal calculus for attribute-based communication), e @ Π .P means "send (the value of) e to all nodes satisfying Π, then continue as P "; dually, (x | Π).P means "when receiving a message x satisfying Π, continue as P ".Many interaction models used in smart systems, such as channels, agents, pub/sub, broadcast and multicast, can be readily implemented using attribute-based communication [8].
Therefore, putting together all the pieces, a promising paradigm for smart systems and edge computing could be obtained by merging the tradition of event-based programming with a new distributed coordination mechanism akin attribute-based communication.Nevertheless, integrating attribute-based communication in the ECA paradigm is not obvious.We could try to add some send/receive primitives similar to AbC's, but this would yield a disharmonious patchwork of different paradigms, i.e., memory-based events vs messagepassing: the latter is best suited to (possibly stateless) agent-oriented models; while most ECA-based systems are meant to react to (internal or external) changes of nodes state, caused by memory updates or inputs.
For solving this conundrum, in this paper we present AbU (for "Attribute-based memory Updates"), a calculus integrating ECA programming with loosely coupled attribute-based interaction.In this model,

D R A F T
interactions are reduced to events of the same kind ECA programs already deal with, i.e., memory updates.More precisely, an AbU system is composed by a set of agents, called nodes, each endowed with a local state (representing local memory, sensors, actuators, etc) and programmed with a set of ECA rules.When a rule of the form x 1 , . . ., x n Π : act is triggered on a given node due to a change in some local variable x i , the action act can update the state of that node (like in normal ECA programming), but it can also update the state of other nodes, selected upon their states by the predicate Π.For instance, a rule like the following: accessTime @(role = logger) : log ← log + accessTime means "when (my local) variable accessTime changes, add its value to the variable log of all nodes whose variable role has value logger".Clearly, the update of log may trigger other rules on these (remote) nodes, and so on.We call this mechanism attribute-based memory updates, and it can be seen as the memory-based counterpart of attribute-based communication, built upon message-passing.Notice that, in this paradigm memory updates are directly "pushed" to remote nodes: a rule can change the state of a remote node without any corresponding "input" step on that node.Clearly, allowing for any update from anyone would be too liberal, as a node may want to keep incoming data under control.In attribute-based communication of AbC, this control is done by filtering incoming messages by means of predicates in input primitives -but in attribute-based memory updates, there are no input primitives.The solution we adopt arises from the observation that very often in state-based machines we can identify a subset of invalid states, which should be avoided for consistency or safety reasons; this is particularly common in IoT and smart systems, where nodes state also effects to the surrounding environment.Formally, the set of valid states of a node can be specified by means of a state invariant, i.e., a predicate over nodes states which should be kept valid during the whole execution.Therefore, any update (possibly from other nodes) leading to an invalid state, i.e., violating the local invariant, have to be rejected.So, invariants in attribute-based memory updates can be seen as the counterpart of message filtering in attribute-based communication.
The importance of a calculus like AbU is twofold.On one hand, it can be used as a reference model for the implementation of full-fledged programming language, or extensions of existing languages, for IoT and edge computing; as an example, a prototypal implementation in Golang of AbU is available at [9].On the other hand, it is the basis for the investigation of important properties of event-driven architectures with attributed-based interaction, and for the development of formal methods for guaranteeing these properties.In this paper, we investigate two of these properties, namely stabilization and confluence, both very relevant in IoT and smart systems: the first guarantees that a chain of rule executions triggered by an external event will eventually terminate; the second guarantees that the effects of the rules are eventually deterministic and do not depend on the rule execution order.For both these properties we provide formal semantic definition, sufficient syntactic conditions on AbU programs, and algorithms to statically check such conditions.Synopsis.After a summary of related work in Section 2, in Section 3 we introduce the syntax and operational semantics of AbU, together with an encoding of a Turing complete computational model.In order to showcase the expressiveness of AbU, in Section 4 we provide various examples of application scenarios for AbU in the IoT.In Section 5 we show how to encode AbC components into AbU, providing encoding correctness and examples.Then, in Section 6 we define stabilization and confluence of AbU systems, discuss correctness requirements for these properties, and provide algorithms for their verification.A distributed implementation for AbU is presented in Section 7. Finally, conclusions and directions for future work are in Section 8. Full proofs of the results are collected in Appendix A.

Related Work
To the best of our knowledge, the only previous work aiming at merging the ECA programming paradigm with attribute-based interaction is the conference version of the present paper [10].Here, the calculus presented in [10] is enhanced with invariants, namely conditions that nodes have to guarantee during runtime.Furthermore, we slightly modify the semantics of the calculus, extending system labels with the committed updates.In this way, when a node performs an input or an execution step, the corresponding

D R A F T
and for direct remote memory access.This mixed approach has been recently applied also in the MAS context [32], where the local behavior of agents is based on shared variables and the global behavior is based on message-passing.These results could be very helpful for the implementation of AbU, since a message-passing with shared-memory approach perfectly fits the attribute-based memory updates setting.Finally, recent work [33,34] on the Reactive Data model adopts a declarative attribute-based interaction similar to AbU's.In this model, ECA rules are given by declarative response relations (introduced in DCR Graphs [35]), while attribute-based interaction is obtained by using dynamic end-points of the relations, defined by graph query languages (e.g., XPath).The papers come with prototype implementations, which are however not distributed.

The AbU Calculus
We present here AbU, a calculus merging a prominent event-driven programming paradigm, i.e., Event Condition Action (ECA) rules, with attribute-based interaction.This solution embodies the programming simplicity prerogative of ECA rules, but it is expressive enough to model complex coordination scenarios, typical of distributed systems.Furthermore, the calculus is fully decentralized, hence perfectly suitable for edge computing.The name AbU is an acronym for Attribute-based memory Updates that is, as we will see in the following, the distributed interaction mechanism on which the calculus relies on.

Syntax
An AbU system S is either a node, of the form R, ι Σ, Θ , or a parallel composition S 1 S 2 of systems, which is associative and commutative1 .A state Σ ∈ X − → V, is a map from resources in X to values in V, while an execution pool Θ ⊆ n∈N U n is a set of updates.An update upd is a finite list of pairs (x, v) ∈ U, meaning that the resource x will take the value v after the execution of the update.Moreover, each node is equipped with: an invariant ι (i.e., a boolean expression) that the node has to satisfy at run-time; and a non-empty finite list R of ECA rules, generated by the following grammar.
An ECA rule evt act, task is guarded by an event evt, which is a non-empty finite list of resources.When one of these resources is modified, the rule is fired : the default action act and the task are evaluated.Evaluation does not change resources state immediately; instead, it yields update operations which are added to the execution pools, and applied later on.
An action is a finite (possibly empty) list of assignments of value expressions to local x or remote x resources.The default action can access and update only local resources.On the other hand, a task consists in a condition cnd and an action act.A condition is a boolean expression, optionally prefixed with the modifier @.If @ is not present, the task is local : all resources in the condition and in the action refer to the local node (thus variables of the form x cannot occur).So, the condition is evaluated locally; if it holds, the action is processed.Otherwise, if @ is present, then the task is remote: the task @ϕ : act reads as "for

D R A F T
all external nodes where ϕ holds, do act".On every node where the condition holds, the action is evaluated yielding an update to be added to that node pool.So, in remote tasks each assignment in act is on remote resources only, but still they can use values from the local node.As an example, the task @T : x ← x + x means "add the value of this node's x to the x of every other node".
Rules of the form evt , task, i.e., with empty default action, are written more concisely as evt task.Finally, we implicitly extend the (binary) parallel composition operator to its n-ary version.For instance, when we write S 1 S 2 S 3 we actually mean (S 1 S 2 ) S 3 , which is equivalent, due to associativity, to S 1 (S 2 S 3 ).With a little abuse of notation, we denote with the binary and the non-binary versions of the parallel composition.

Semantics
Given a list R = rule 1 . . .rule n of ECA rules and a set X of resources that have been modified, we define the set of active rules as Active(R, X) {rule i | ∃i ∈ [1..n] .rule i = evt act, task ∧ evt ∩ X = ∅}, namely the rules in R that listen on resources in X and, hence, that may be fired.Given an action act, its evaluation act in the state Σ returns an update.Formally: The evaluation semantics for value expressions ε is standard.As we will see in a moment, the semantic function • is applied only to local actions, that do not contain instances of external resources x.The default updates are the updates originated from the default actions of active rules in R, namely: Similarly, the local updates are the updates originated from the tasks of the active rules in R that act only locally (@ is not present in the task condition) and whose condition is satisfied by the node state, namely: The satisfiability relation for boolean expressions (and, indeed, for invariants) is defined as: Σ |= ϕ ϕ Σ = tt (the evaluation semantics for boolean expressions ϕ is standard as well).
When we have a task containing the modifier @, an external node is needed to evaluate the task condition 2 .In our semantics, when a node needs to evaluate a task involving external nodes, it partially evaluates the task (with its own state) and then it sends the partially evaluated task to all other nodes.The latter, receive the task and complete the evaluation, potentially adding updates to their pool.In particular, the partial evaluation of tasks works as follows.With {|task| }Σ we denote the task obtained from task with each occurrence of a resource x in the task condition and the right-hand side of assignments in the task action replaced with the value Σ(x).After that, each instance of x in the task action is replaced with x and the modifier @ is dropped.For instance, {|@(x ≤ x) : Note that, once the task is partially evaluated and sent to other nodes, it becomes "syntactically local" for the receiving nodes, i.e., its action can be evaluated with the semantic function • .
Finally, we define the external tasks as: given that for each i ∈ [1.
.n] there exists a rule evt act, task i ∈ Active(R, X) such that task i = @ϕ : act, namely the tasks of active rules in R whose condition contains @ (i.e., tasks that require an external node to be evaluated).Operational (small-step) semantics.The small-step operational semantics of an AbU system is modeled as a labeled transition system (LTS).In particular, S 1 α S 2 means that the AbU system S 1 evolves to the AbU system S 2 , producing the LTS label (or simply, label) α.Here, LTS labels are given by: where T is a finite (possibly empty) list of tasks and upd an update.As we will see in a moment, the labels T identify a discovery phase, the labels upd T an update execution and the labels upd T an external input.A transition can modify the state and the execution pool of the nodes of the AbU system.The semantics is distributed, in the sense that each node semantics does not have a global knowledge about the system.The transition rules are in Figure 1.A rule (Exec) executes an update picked from the pool; while a rule (Input) models an external modification of some resources.The execution of an update, or the modification of resources in general, may trigger some other ECA rules in the system.Hence, after updating a node state, the semantics of a node launches a discovery phase, with the goal of finding new updates to add to the local pool (or some pools of remote nodes), given by the activation of some ECA rules.The discovery phase is composed by two parts, the local and the remote one.A node R, ι Σ, Θ performs a local discovery by means of the functions DefUpds and LocalUpds, that add to the local pool Θ all updates originated by the activation of some rules in R.Then, by means of the function ExtTasks, the node computes a list of tasks that may update external nodes and sends it to all nodes in the system.This is modeled with the labels upd T , produced by the rule (Exec), and upd T , produced by the rule (Input).On the other side, when a node receives a list of tasks (executing the rule (Disc) with a label T ) it evaluates them and adds to its pool the actions generated by the tasks whose condition is satisfied.The rule (Step) completes (on all nodes in the system) a discovery phase launched by a given node.
Note that, not necessarily all nodes have to modify their pool (indeed, a task condition may not hold in an external node).At the same time, the rule synchronizes the whole discovery phase, originated by a change in the state of a node of the system.When a node executes an action originating only local updates, the rule (Step) is applied with S 2 = S 2 , producing the label upd or the label upd (i.e., with an empty tasks list).The latter, is matched by a label T = , that all nodes can generate by applying the rule (Disc).
The semantics also checks the fulfillment of invariants, at run-time.Indeed, when a node tries to perform an update that would break an invariant, the rule (Exec) is not applicable.Instead, the rule (Exec-Fail) is performed, that ignores the update (which is removed from the pool but it is not executed); this fact D R A F T is observable by the label upd .Note that, we do not distinguish the case when an update breaks the invariant from the case when the update is idempotent (i.e., when resources hold the same values that the update try to assign).Remark 1. Invariants have been introduced to enforce node safety properties at run-time, namely not reaching erroneous states (e.g., a thermostat can allow its temperature to be set only to values within a given range).In fact, by means of AbU node invariants we can implement some form of access control.For instance, a node can accept updates originated only by white-listed nodes in this way: every update will save in an attribute last-writer the id of the originating node; the invariant will require last-writer to be always in a fixed set (the white-list).We will see in Section 5 that an application of invariants will be the encoding of selective inputs of AbC.
In this respect, we can define the set of all possible AbU execution states that satisfy a given invariant, dubbed legal execution state.
Definition 1 (Legal execution states).Given an AbU invariant ι, we define the set of legal execution states for ι as: Then, an AbU system Θ n is said admissible when its execution state is legal for the corresponding invariants.Formally: Note that, admissible systems are defined in terms of system invariants only, and invariants do not change during execution.It is easy to note that the semantics in Figure 1 guarantees that the execution steps of an AbU system involve admissible systems only.
Wave (big-step) semantics.Initially, the pools of all nodes of an AbU system are empty, namely the system is stable, and to start the computation an input (i.e., an external modification of the environment) is needed.
We will often use R, ι Σ as a shorthand for R, ι Σ, ∅ .Hence, a system is stable when it is of the form R 1 , ι 1 Σ 1 . . .R n , ι n Σ n .In the case of stable systems, only the rule (Input) can be applied, i.e., an external environment change is needed to (re)start the computation.
We can define a sort of big-step semantics S upd S between stable systems, dubbed wave semantics, in terms of the small-step semantics.Let * be the transitive closure of , without occurrences of labels of the form upd T , namely * denotes a finite sequence of internal execution steps (with the corresponding discovery phases), without interleaving input steps.The wave semantics for a system S is: The idea is that a stable system reacts to an external stimulus by executing a series of tasks, which propagate across the nodes like a "wave", until it becomes stable again, waiting for the next stimulus.Note that, in the wave semantics inputs do not interleave with internal steps: this leaves the system the time to reach stability before the next input.Note also that, it could be the case that, after a particular update, an AbU system never becomes stable, since the AbU semantics allows systems to perform infinitely many execution steps.In Figure 2 we have a graphical representation of the AbU execution model.
Remark 2. If we allow arbitrary input steps during the computation, possibly a system may never reach stability since the execution pools could be never emptied.This assumption is justified by the fact that, in the IoT context, usually, external changes (in sensors) take much more time than internal computation steps [36], or, equivalently, hardware is chosen fast enough to keep the pace of the environment changes.
As an example, LoRaWAN connected IoT sensors can transmit their data with intervals of the order of minutes.In this scenario, the devices receive inputs with a very low rate.Therefore, we can assume that AbU nodes have been provided with enough computational power to complete their execution steps before the next input: the faster the inputs happen, the more powerful the nodes have to be.We point out that environment changes possibly happening during an execution phase are not lost; instead, these inputs are queued and processed in FIFO order when the execution phase terminates.Nevertheless, we plan to relax the constraint assuming the mutual exclusion between input and execution phases as a future extension of AbU.Remark 3. Since the semantics in Figure 1 is labeled, one can think of AbU as a calculus with messagepassing.Nevertheless, LTS labels are not actual messages exchanged by AbU nodes, in the sense that such messages are not part of the AbU syntax (has it happens for message-passing process calculi).Indeed, nodes code is not aware of LTS labels and it cannot manipulate them.Clearly, in a distributed network of agents, communication must be implemented by means of messages exchange, but this is an implementation detail.Our point is that AbU does not require messages exchange at design level, namely programmers are not forced to use a message-passing mechanism to coordinate nodes (even if the underlying communication may be implemented by means of a protocol based on message-passing).

On the Expressiveness of AbU
During the presentation of AbU we deliberately left implicit the full definition of boolean and value expressions.Indeed, the latter deeply affect the expressive power of the calculus.It is easy to provide AbU with expressions that make the calculus Turing complete.For instance, adding some simple constructs to value expressions we can easily encode semi-Thue systems, non-deterministic rewriting systems over strings which are Turing complete [37].In brief, a semi-Thue system is composed by a (finite) alphabet of symbol and a (finite) set of rewriting rules of the form u → v, where u and v are strings (i.e., finite sequences of symbols) over the alphabet.Computation is carried out transforming strings: we can transform a string s 1 into a string s 2 if s 1 = xuy, s 2 = xvy and there exists a rewriting rule u → v in the semi-Thue system.Note that, the substitution is non-deterministic, in the sense that if s 1 contains multiple occurrences of u, the occurrence to modify is selected non-deterministically.
Suppose to have the following binary operators on value expressions: #[s] computing the number of elements of the string value s, e.g., #['str'] = 3; s 1 :: s 2 concatenating the two string values s 1 and s 2 , e.g., 'str' :: 'ing' = 'string'; s[-: i] computing the string value composed of the first i elements of the string value s, e.g., 'string'[-: 3] = 'str'; s[i : -] computing the string value composed of the last i elements of the string value s, e.g., 'string'[3 : -] = 'ing'; and s 1 ?|s2 returning the first index in the string value s 1 of one occurrence of the string value s 2 in s 1 , chosen non-deterministically The rule substitutes one occurrence of the string value pointed by y in the string value pointed by x, chosen non-deterministically, with the string value pointed by z.For instance, consider the state [x → 'abuabu' y → 'bu' z → 'bc'].When the rule ( 1) is fired, and its update executed, we have that x can contain, non-deterministically, either 'abcabu' or 'abuabc'.Note that, since the evaluation of a rule action is atomic, we assume that all instances of x ?|y in a given action compute the same value (i.e., an index of x is non-derministically chosen, but it is the same for all occurrences of x ?|y in the action).By using the rule (1), we can easily encode into AbU a generic semi-Thue system, we just have to encode into AbU its rewriting relation.In particular, for each rewriting rule u → v we generate an AbU rule of the form: where 'u' and 'v' are the string values of AbU corresponding to the strings u and v of the semi-Thue system, respectively.The AbU resource input is initialized with the input string that would be passed to the semi-Thue system to execute.Each time the resource input is modified, in the pool of the AbU node all updates of the rules are added, then the AbU scheduler will chose non-deterministically which substitution to apply, as exactly happens for a semi-Thue system.Note that, a semi-Thue system has, by definition, a finite number of rewriting rules, hence we can fully encode any semi-Thue system into AbU.Hence, AbU equipped with non-deterministic string substitutions is Turing complete.
Conversely, if we limit the value domains in expressions to have finite cardinality, then the language loses Turing completeness.Indeed, we have a finite number of rules, a finite number of nodes and a finite number of resource (in AbU we cannot dynamically allocate memory, namely fresh resources).If we also have a finite set of possible values for resources, then we can encode each AbU system into a NFA, hence losing Turing completeness.
Proposition 2. If the value domains of resources in AbU expressions have finite cardinality, then each AbU system corresponds to a NFA.

Proof (Sketch). The encoding of an AbU system
a NFA is straightforward, we provide here just a simple sketch.
The states of the automaton are given by all possible configurations of the 2n-tuple (Σ 1 , Θ 1 , . . ., Σ n , Θ n ), composed by execution states and execution pools of all nodes in the system.The transitions of the automaton are given by the ECA rules in the nodes of the system.
Each execution state Σ i can range over a finite set, whose cardinality is given by its attributes and the corresponding sets of possible values (which are finite by hypothesis).Each pool Θ i is a subset of the set of all possible updates, and these are finite because each update is a finite list of assignments whose right hand values are finite, and are generated by ECA rules which are finite as well.Therefore, the set of states of the automaton defined above is finite, yielding a NFA.Corollary 3. If the value domains of resources in AbU expressions have finite cardinality, then the AbU calculus is not Turing complete.

AbU in Practice
In this section, we provide practical examples of IoT scenarios modeled with AbU, to help the reader to get familiar with the AbU syntax and to understand its semantics.Furthermore, these examples showcase the simplicity of AbU in modeling complex scenarios.

Intrusion Detection System
Let us consider the scenario sketched in the introduction, where an "access" node aims at sending its local access time to all "logger" nodes in the system.The access node is activated when accessT changes, namely when a user performs access; the node aims at sending the IP address of the user and the name of the accessed resource, together with a time-stamp.On the other side, the logger nodes record the access time, the IP address and the resource name.Furthermore, suppose that these nodes contain a black-list of IP addresses.This list can be updated at run-time, by external entities communicating with logger nodes, so it may be the case that different logger nodes have different black-lists.A logger node that notices an access from a black-listed IP is in charge of notifying the intrusion detection system (IDS).
The system is formalized with AbU as follows.We suppose to have two access nodes and two logger nodes.We also suppose that log is a structured type, i.e., a list of records of the form IP, accessT, res .An append to the list log is given by append log IP, accessT, res ; while with IP, accessT, res .IP we denote the access of the field IP , and with tail log we denote the last record inserted in the list log.Given a list of (black-listed) IP addresses Blist, we denote with IP ∈ Blist the fact that IP is an element of the list.
The four AbU nodes are the following, where R a Σ 1 and R a Σ 2 are the access nodes, while R l Σ 3 and R l Σ 4 are the logger nodes.
At the beginning, the AbU system S 1 S 2 S 3 S 4 is stable, since all pools are empty.At some point, an access is made on the resource camera, and it is recorded by first access node.Hence, the rule (Input) can be applied by Now, a discovery phase is performed on all other nodes.In particular, we have that The derivation tree for the resulting system S 1 S 2 S 3 S 4 is depicted in Figure 3[top].Now, the third and the fourth nodes can apply an execution step, since their pools are not empty.Suppose the third node is chosen, namely we have IDS → ] and upd 2 = (log, 167.123.23.2, 15 : 07 : 00, camera ).Note that, in this case, no rule is triggered by the executed update.Since there is nothing to discover, all the other nodes do not have to update their pool and the derivation tree for the resulting system S 1 S 2 S 3 S 4 , where : 00, camera )}.In this case, the execution of the update triggers a rule of the node but the rule is local so, also in this case, the discovery phase does not have effect.
The derivation tree for this step is analogous to the derivation tree for the previous one.Finally, with a further execution on the fourth node, we obtain the system S 1 .Since all pools are empty, the resulting system is stable.This means that we can perform a wave semantics step (where upd 3 = (IDS, 167.123.23.2, 15 : 07 : 00, camera )):

Swarm of Robots
Consider now a scenario where a swarm of drones is in charge of taking specific measurements, randomly picked in a large uninhabited area.Each drone is equipped with a battery that periodically needs to be recharged by returning to a docking station.It may happen that a drone runs out of energy before returning to the charging spot.In this case, the low-battery drone asks for help from its neighbors.If a drone has some energy to share and it is close enough to the requester, it will enter the "rescue" mode.A drone in "rescue" mode will reach the drone in distress, sharing with it some energy.This phase is not modeled in the example for space reasons.We can model this scenario in AbU as follows.
Suppose to have four drones.For each drone we have an AbU node with a resource battery, indicating the battery level of the drone; a resource position, indicating where is located the drone; a resource mode, indicating in which operative state is the drone; and a resource helpPos, indicating the position of a drone that needs help.Formally, the AbU system modeling the drone The first rule says that when the current drone battery level is low (i.e., when battery < 5), then the current drone have to send to all neighbors (using @) that have some energy to share (i.e., that have battery > 80) its position, performing a remote update (i.e., helpPos ← position).In the example, the first node can fire the rule, since its battery level is low.Then, it pre-evaluates the task condition, yielding (4 < 5 ∧ battery > 80), which is sent to the other nodes, together with the pre-evaluation of the task action, i.e., helpPos ← 2.0.Among all receivers, only the second and the third nodes are interested in the communication, since they are the only nodes with battery level greater than 80.So, they both add to their pool the update (helpPos, 2.0).This ends the discovery phase originated by the first node.
The second rule, instead, is fired when a drone receives a help request (i.e., when its resource helpPos changes) and basically checks if the current drone position is close to the requester node position (i.e., when |position − helpPos| < 7.0).If it is the case, the current drone enters the rescue mode performing a local update (mode ← rescue).In the example, when the second and the third nodes execute the update (helpPos, 2.0), the task of the rule may be executed.For the second node this does not happen, since |15.0 − 2.0| < 7.0 is not true (the node is too far from the first node).Instead, |6.0 − 2.0| < 7.0 is true and the third node can execute the rule task, adding to its pool the update (mode, rescue).

A Vineyard Irrigation System
Finally, let us consider a scenario where a winegrower wants to optimize the irrigation system of a vineyard.Optimization here means that the system should irrigate each vine with the correct amount of water, maintaining the moisture level of the soil within a given range.The system is composed by a set of water valves, each one attached to a vine.The vineyard is divided in zones, as depicted in Figure 4, each one equipped with a moisture sensor.The vines falling into a given zone are watered depending on the moisture level of the corresponding sensor: when the zone soil is too dry, the water valves of the vines in the zone are opened; dually, the valves are closed when the zone soil is sufficiently moist.
The system also provides to the winegrower a console, to monitor (and log) the status of the water valves (open/close).Furthermore, from the console it is possible to change the moisture range of the sensors.We can model this scenario in AbU as follows.
As depicted in Figure 4, suppose to have sixty vines, divided in fifteen zones.This means that the irrigation system comprises fifteen moisture sensors and sixty water valves.Note that, even if in Figure 4 sensors (m i ) and valves (v i ) have a name, in AbU the nodes are typically anonymous.
Indeed, we have fifteen (unnamed) AbU nodes representing the moisture sensors, each one equipped with a resource position, indicating where is located the sensor; a resource range indicating the size of area D R A F T covered by the sensor; a resource moisture, indicating the (average) moisture level of the soil; and two resources minMoist and maxMoist, indicating the minimum and the maximum moisture levels, respectively.Furthermore, we have sixty (unnamed) AbU nodes representing the water valves, each one equipped with a resource position, indicating where is located the valve; and a resource valve, indicating if the valve is open or close.We also have an AbU node representing the console, equipped with a resource log, to record the actions performed on the valves in the system; and two resources deltaMin and deltaMax, indicating the variation of the lower and upper moisture level bounds to be applied to sensors, respectively.Finally all nodes have a resource node, to indicate if a node is a moisture sensor (sensor), a water valve (valve) or a console (console).Formally, the AbU system modeling the vineyard irrigation system is .15], are the execution states of moisture sensor nodes; Σ v,i , with i ∈ [1..60], are the execution states of water valve nodes; and Σ c is the execution state of the console node.
The system is controlled by means of the following AbU rules, where R s are those equipped on moisture sensor nodes; R v are those equipped on water valve nodes; and R c are those equipped to the console node.The first rule in R s basically closes a water valve when a moisture sensor detects a change in the soil moist, and the new moisture level is above the maximum allowed level.The selected valves to close are those falling in the area covered by the sensor, i.e., valves with position position such that |position − position| < scope.The second rule in R s is the dual, that opens a water valve when the new moisture level is below the minimum allowed level.
The rule in R v notify the console, when a water valve changes status, by selecting all nodes with node = console.The console resource log is appended with current (water valve) node position and the new status of the valve.Finally, the rule in R c modifies the minimum and maximum moisture level boundaries of all sensors, by deltaMin and deltaMax, respectively.The latter values can be set by the winegrower at any time, then the rule is fired when a button on the console is pressed.
Finally, to avoid misconfigurations due to improper usage of the console, sensor nodes have an invariant guaranteeing that lower and upper moisture level bounds always form a valid numeric interval: Indeed suppose that a sensor node has minMoist → 2.5 and maxMoist → 5.3, and suppose that the console sends, by mistake, un update with deltaMin → 3.0 and deltaMax → 0.0.If applied, the update would yield [5.5, 5.3], that is not a valid interval, possibly corrupting the sensor intended behavior.This scenario is

D R A F T
prevented by the invariant ι s .Indeed, such update would fire the semantic rule (Exec-Fail), discarding the update, instead of the semantic rule (Exec).
Remark 4. Note that, nodes in AbU are anonymous, and they are programmed by means of predicates.For instance, we can select groups of nodes by changing (at any time) the sensors area (i.e., the zones) or the sensors moisture level boundaries, without knowing the actual water valves position.This is particularly useful in the context of large IoT systems, where the huge number of nodes makes unfeasible to identify a precise node and where the nodes topology frequently changes (nodes may change their position or can be lost and must be replaced).Nevertheless, we can still adopt a classic single node programming strategy in AbU, by just keeping each node name in a dedicated resource and defining a predicate selecting the nodes with a particular name.

Encoding Attribute-based Communication into AbU
To showcase the generality of our calculus, in this section we encode the archetypal calculus AbC [6] into AbU.Our aim is not to prove that AbU subsumes AbC: the two calculi adopt different programming paradigms, with different peculiarities, that fit different application scenarios.Our goal here is to show that we can model attribute-based communication within the ECA programming paradigm.

The AbC Calculus
We focus on a minimal version of AbC [6], for which we define an operational semantics, as in [8].As already pointed out, we do not target a full-fledged version of AbC, since the aim of this section is to encode into AbU the essence of the attribute-based communication, comprehensively expressed by the core version of AbC that we will present in the following paragraphs.
An AbC component C can be a process paired with an attribute environment, written Γ : P , or the parallel composition of components, written C 1 C 2 .An attribute environment Γ maps attributes a ∈ A to values v ∈ V. Our syntax of AbC processes is as follows.In particular, the input (x | Π) receives a message that satisfies the predicate Π, savint it in the variable x.The output e @ Π sends (the value of) the expression e to all components that satisfy the predicate Π.The awareness process [Π]P waits until Π is satisfied and then continues the execution as P .The other constructs are exactly as in [6]: the inactive process 0; the non-deterministic choice between P a + P b ; and the process call K. Predicates Π and expressions e are standard.We refer the reader to [6] for more details.We now briefly explain the semantics for AbC. e (Γ) evaluates an expression e in the environment Γ and yields a value, while Π (Γ) evaluates a predicate Π in Γ and yields tt or ff.Their formal definition is straightforward, the only interesting cases are: a (Γ) = this.a(Γ) = Γ(a).When Π (Γ) is tt we say that Γ satisfies Π, written Γ |= Π.We assume that processes do not have free variables, i.e., x is always under the scope of an input (x | Π).Finally, in {|Π| }(Γ) we substitute expressions of the form this.a with Γ(a).The semantics for processes (Figure 5[top]) and for components (Figure 5[bottom]) is given by a labeled transition system, where a process label δ is of the form Π v (output) or Π(v) (input) and a component label λ can be either a process label δ or a silent action τ (i.e., a communication to a false predicate).Transitions rules in Figure 5 are self-explanatory (symmetric rules are omitted).
Note that, if the rule (Comm) is applicable then Π cannot be false, since the rule (Rcv) cannot be applied with false predicates.When Π is false, (Int) is applied, representing an internal execution step of C 1 .This rule also applies when C 2 is not ready (or it does not want) to communicate, allowing C 1 to progress.

Encoding AbC into AbU
Given a AbC component Γ 1 : P 1 . . .Γ n : P n , we define an AbU system R 1 , ι 1 Σ 1 . . .R n , ι n Σ n composed by n nodes, where the state Σ i of the i th node is given by the i th attribute environment Γ i (with some modifications that we will see in a moment).The execution pools of all nodes are initially empty.In order to simulate process communication, we add to each node a special resource msg.If a node wants to communicate a message, it has to update the msg resource of all the selected communication partners.The execution of each AbC component is inherently sequential while AbU nodes follow an event-driven architecture.In order to simulate AbC causality, we associate each generated AbU rule with a special resource, a rule flag, whose purpose is to enable and disable the rule.The sequential execution flow of an AbC component is reconstructed modifying the active flag of the rules: this simulates a "token" that rules have to hold in order to be executed.Formally, the state of the i th nodes is augmented as follows: .n] Res j (P j ) A rule is generated for each process instance present in the AbC component to be encoded.To this end, each node is augmented with all rule flags, of all rules, given by the translation of all processes of the AbC component.Rule flags are resource of the form P h r i , with h ∈ [1.
.n] and i ≥ 0, representing the i th rule generated from the component h.The function Res h , given a process of the component h, with h ∈ [1..n], computes the resources to add to the nodes.Here, Res h is parametric in h since rules are binded to the component generating them.In particular, Res h returns ∅ for the inactive process and for process calls, i.e., Res h (0) Res h (K) ∅, and nothing is added.For the other processes, it returns Res h (P ) {(P h r 0 , ff)} ∪ Res h (P, 0).The flag P h r 0 is the starting point of the computation, indeed it does not represent any actual rule, and it is set to tt in order to start the computation.The function Res h (P, i), for i ≥ 0, is defined inductively on the structure of P .In the base cases P = 0 and P = K, it returns ∅ (i.e., nothing is added), otherwise it is defined as follows, where the auxiliary function Next generates a fresh index for the next rule to add.Let Next(i) = j and Next(j) = k, then: if P = [Π]P or P = [a := e]P or P = e @ Π .P In particular, if the process is an input, we add the flag for the current rule and another resource for the variable x.If the process is a non-deterministic choice, we add two flags, one for each branch, that will originate two different rules.In all other cases, we just add the flag for the current rule.

D R A F T
Concerning the translation of AbU rules, we adopt the following mechanism.The i th generated rule, of the component h, listens on the rule flag P h r i : when the latter becomes tt, the rule can execute.Its execution disables P h r i (it is set to ff) and enables the next rule, setting the flag P h r j , with j = Next(i), to tt.In this way, the execution token can be exchanged between rules.The function Enc h , given a process of the component h, with h ∈ [1..n], generates the rules to add to the translation.It relies on Next, that outputs a fresh index for the next rule to generate.We assume that Next in Enc h is consistent with Next in Res h , i.e., they have to produce the same sequence of indexes given a specific process.The function Enc h (P, i), for i ≥ 0, is defined inductively on the structure of P .In the base case P = 0, it returns (i.e., nothing is added), otherwise it is defined as follows.
If the process is a call to K, a new call rule is added.This rule enables the first flag (the dummy rule r 0 ) of the called process, defined by K.In other words, given K P k : If the process is an input x on the predicate Π, a new receive rule is added.The rule checks the condition given by the translation of the predicate Π.Here, Repl replaces, in a given AbU boolean expression, every instance of a specific variable (x in this case) with msg.As an example, the predicate Π = x < n is translated to Repl(Enc(Π), x) = msg < n.When the condition is satisfied, the rule saves the value msg received from the sender (in the resource x), ends the communication and enables the next rule.In other words, given j = Next(i): If the process is a non-deterministic choice between P a and P b , two new choice rules are added.Both rules listen to the same flag, so the scheduler can choose non-deterministically the one to execute.The action of the first choice rule enables the next rule given by the translation of P a , while the action of the second choice rule enables the next rule given by the translation of P b .In other words, given j = Next(i) and k = Next(j): Enc h (P a + P b , i) P h r i (P h r i = T) : P h r i ← F P h r j ← T Enc h (P a , j) P h r i (P h r i = T) : If the process is waiting on the predicate Π (awareness), a new awareness rule is added, that listens on the resources contained in Π.The latter are retrieved by the function Vars that inspects the predicate Π and returns a list of resource identifiers.In particular, variables x are left untouched, while AbC expressions a and this.a are both translated to the resource a.The condition in the rule task is the translation of Π.When it is satisfied, the next rule is enabled.In other words, given j = Next(i): If the process updates the attribute a with the expression e, an update rule is added, assigning the translation of e to a and enabling the next rule.In other words, given j = Next(i): If the process is an output of the expression e on the predicate Π, a new send rule is added.The rule checks the condition given by the translation of the predicate Π.Note that, in the AbC semantics, the predicate is partially evaluated before the send, namely expressions of the form this.a are substituted with Γ(a).To simulate this mechanism in AbU we use an auxiliary transformation Ext that takes a AbC predicate Π and returns its translation Enc(Π) where each instance (in Π) of an attribute a not prefixed by this. is translated to a.As an example, the predicate Π = this.n< n is translated to Ext(Π) = n < n.For each external node satisfying the predicate Π, the rule writes the translation of e to the external node resource msg (with msg ← Enc(e)).Outputs are non-blocking, so the rule has a default code, executed without caring RECV x from ϕ 2 node 2 checks ϕ 2 , and x ← msg is executed node1 selected, and ϕ2 satisfied RECV x from ϕ 3 node 3 checks ϕ 3 , but nothing is executed about the satisfaction of the condition.It disables the current rule and enables the next one.In other words, given j = Next(i): Enc h ( e @ Π .P , i) P h r i P h r i ← F P h r j ← T, @(P h r i = T ∧ Ext(Π)) : msg ← Enc(e) Enc h (P , j) Finally, the translation of predicates Enc(Π) and expressions Enc(e) is recursively defined on Π and e, respectively.Its definition is straightforward, the only interesting cases are: Enc(this.a)Enc(a) a.To start the execution of the translated system, an (Input) is needed, enabling all rule flags P h r 0 , of all nodes.
In the following, we denote with Enc(C) the AbU encoding of C, where node states are defined as explained above, node pools are empty and nodes ECA rules are generated by Enc (for each process of C).
In Figure 6 we graphically explain how an attribute-based communication is performed in AbU, by means of attribute-based memory updates.The node node 1 aims to send the value v to nodes node 2 and node 3 , since they satisfy ϕ 1 = Ext(Π 1 ).So, it updates with v the resource msg on the remote nodes node 2 and node 3 .On the other side, node 2 and node 3 check if some node aims to communicate and node 1 is indeed selected.Since node 1 satisfies ϕ 2 = Repl(Enc(Π 2 ), x) and does not satisfy ϕ 3 = Repl(Enc(Π 3 ), x), only node 2 accepts the value v, saving it in the resource x, while node 3 ignores the communication.
Encoding example.We now show an example encoding of an AbC component into AbU.The example is taken from [27] (Subsection 2.1).Given N agents, each associated with an integer in [1..N ], we wish to find one holding the maximum value.This problem can be modeled in AbC by using one component type P with two attributes: s, initially set to 1, indicating that the current component is the max; and n, that stores the component value.Formally, the process P (with Max P ) is: Basically, P waits until s becomes 1 and then either: it sends its own value n to all other components with smaller n; or it receives (on x) a value from another component with a greater n and sets s to 0. Supposing N = 3, the problem is modeled in AbC with the component ] : P .This AbC component translates to AbU as follows.

Correctness of the Encoding
We finally provide a correctness result for the previously defined encoding.In particular, we prove that translated AbU systems preserve the semantics of the original AbC components.Since an AbU node contains auxiliary resources, in addition to those corresponding to AbC attributes, we have to establish a notion of compatibility between AbU node states and AbC attribute environments.Given an AbU node state Σ and an AbC attribute environment Γ, we say that Σ is compatible with Γ, written Σ Γ, when for each (a, v) ∈ Γ there exists (a, v) ∈ Σ (i.e., when Γ ⊆ Σ).This basically means that Σ agrees, at least, on all attributes of Γ.This notion can be extended to systems and components.Definition 3 (AbU to AbC compatibility).Given an AbC component C = Γ 1 : P 1 . . .Γ n : P n and an AbU system The AbU translation Enc(C) of C yields n (one for each process) initial rule flags P 1 r 0 , . . ., P n r 0 , initially set to ff.In order to start the computation of Enc(C), the latter have to be initialized (i.e., set to tt).In this regards, we assume an initial input phase, comprising n AbU (Input) steps, enabling all initial rule flags (without interleaving execution steps).Let * be the transitive closure of without occurrences of labels of the form upd T .In other words, * denotes a finite sequence of internal input steps (with the corresponding discovery phases), without interleaving execution steps.Now we are ready to state the correctness of the AbC encoding.The following Theorem 4 says that if an AbC component performs some computation steps, producing a residual component C , then the AbU translation of C, after an initial input phase, is able to perform an arbitrary number of computation steps, yielding a residual system attribute compatible with C .This basically means that Enc(C) is able to "simulate" each possible execution of C. Proof.The proof is quite complex and it requires some preliminary results.In order to simplify the reading, we moved the full proof to Appendix A.1.

Correctness Requirements for AbU Systems
Correctness requirements aim at preventing the nodes of an AbU system to exhibit unintended behaviors.For instance, the wave semantics (and, hence, an AbU system) may exhibit internal divergence: once an input step starts the computation, the subsequent execution steps may not reach a stable system, even if no other inputs are performed.
As a motivating example, consider the curious case of the book "The Making of a fly", that reached the stellar selling price of $23,698,655.93 on Amazon, in 2001 4 .Two Amazon retailers, profnath and bordeebook, used Amazon automatic pricing primitives to set the price of their book copy, depending on the competitor book price.The strategy of profnath was to automatically set the price 0.99 times the bordeebook price; conversely, the strategy of bordeebook was to set the price 1.27 times the profnath price.Obviously, each retailer was not aware of the competitor's strategy.This scenario can be modeled by means of the following (informal) ECA rules:

D R A F T
when bordeebook-price changes, set profnath-price as bordeebook-price decreased by 1% when profnath-price changes, set bordeebook-price as profnath-price increased by 27% that translate to AbU as: bordeebook-price (T) : profnath-price ← bordeebook-price * 0.99 profnath-price (T) : bordeebook-price ← profnath-price * 1.27 It is easy to see that these rules generate a loop, leading to an uncontrolled raise of the book price (as it happened).In order to prevent these situations, we may define a syntactic condition on the rules that guarantees (internal) termination.In other words, each system satisfying the condition eventually becomes stable, after an initial input and without further interleaving inputs.
Another quite import requirement for AbU systems is confluence, that can be seen as a sort of schedulerindependence.In other words, confluence says that no matter which is the order of execution of the updates in the pools (given by the AbU scheduler), the system eventually produces a unique result.This can be useful in contexts where the final result of rules application must be predictable.
In the following, we first formally define stabilization and confluence requirements, then we provide syntactic sufficient condition that guarantee the satisfaction of these requirements by a given AbU system.

Stabilization and Confluence
Before formally defining the correctness requirements, we have to introduce some notions and notations.Given the set N of natural numbers, with cardinality |N| = ω, we denote with N * and N ω the set of finite sequences and infinite sequences, respectively, over naturals.We denote with N ∞ N * ∪ N ω the set of (finite and infinite) sequences over naturals and with the empty sequence.Given a sequence n ∈ N ∞ , we define the set of its (finite) prefixes as: An infinite sequence n ∈ N ω approximates (to the limit) a set of finite sequences X ⊆ N * when n have an infinite number of prefixes in common with X.In this case, n is exactly the Eilenberg limit [39,40] of X, and it is formally defined as: As an example, the Eilenberg limit of the (infinite) set i∈N {(5 7) i } = { , 5 7, 5 7 5 7, 5 7 5 7 5 7, . ..} is the infinite sequence (5 7) ω .Note that, E-limit(X) = ∅ when X is finite.
Given a set of sets X, we denote with max(X) {X ∈ X | ∀X ∈ X .X ⊆ X ⇒ X = X } the set of maximal elements of X.Then, given a set X, we define the set of its maximal subsets as: where the symbol ℘ denotes the powerset operator.In other words, each element of ℘ max (X) is closed under maximal elements and saturates X.
As we will see in a moment, to reason about complex AbU system behaviors we need a detailed notion of system trace, that comprises execution states, execution pools and LTS labels.We want to stress the fact that the usage of labels in the semantics and in the definition of system trace does not imply that AbU is based on messages exchange.LTS labels are used by the AbU semantics only to record nodes state variation, they do not carry any actual semantic information regarding nodes.In other words, what we actually observe of the AbU semantics is not the messages (LTS labels) exchanged but, rather, the variation of nodes state.
We now formally define the internal termination requirement, that we call stabilization.We denote with ExecLabels the set of all possible execution labels, namely AbU labels of the form upd T , for some upd and T .Recall that, S * S means that that S can be obtained from S by applying execution steps only,

D R A F T
namely in * we can only have labels belonging to ExecLabels.Note that, when S * S then there exists k ∈ N such that S α0 . . .
S .The latter is a finite computation (of length k) originated by S. A finite computation may lead to a stable system (i.e., all pools in S are empty) or to a not stable system (i.e., we have at least one non-empty pool in S ).Stabilization states that after some execution steps a system becomes stable.Definition 4 (Weak stabilization).An AbU system S is weakly stabilizing when there exists S such that S * S and S is stable.
Weak stabilization does not exclude that S may originate both computations leading to a stable system and computations not leading to any stable system.Indeed, we can have an infinite sequence of applications of the AbU semantics involving execution steps only.In other words, S may originate an infinite computation S α0 S 0 α1 . . .(with α i ∈ ExecLabels and i ∈ N) that does not lead to any stable system.
Definition 5 (Stabilization).An AbU system S is stabilizing when there are no infinite computations, namely S cannot originate infinite sequences S α0 S 0 α1 . . .(with α i ∈ ExecLabels and i ∈ N).
In other words, a weakly stabilizing system may become stable, i.e., there exists a scheduling that yields a stable system; while a stabilizing system must become stable, i.e., all possible schedulings yield, eventually, a stable system.The reader familiar with Term Rewriting Systems can note that stable AbU systems are conceptually analogous to terms in normal form [41]. Indeed, a term is in normal form when no rewriting rules can be applied to it; analogously, an AbU system is stable when no (Exec) rules can be applied to it.Similarly, weak stabilization is analogous to weak normalization [41] (all terms admit a normal form) and stabilization is analogous to strong normalization [41] (all rewriting sequences are finite).We now define the second requirement for AbU systems, i.e., confluence, that can be seen as a sort of scheduler-independence.In other words, confluence says that no matter which is the order of execution of the updates in the pools (given by the AbU scheduler), the system eventually produces a unique result.Definition 6 (Confluence).An AbU system S is confluent when for all S 1 and S 2 such that S * S 1 and S * S 2 there exists S such that S 1 * S and S 2 * S .
In other words, if S * S 1 and S * S 2 , for different systems S 1 and S 2 , we have two different scheduling that we can apply from S. Nevertheless, if S is confluent, both scheduling eventually yield a unique system S .Note that, confluence does not implies that the system stabilizes, indeed, we can have confluent systems that generates infinite computations.
Definition 7 (Convergence).An AbU system S is convergent when it is confluent and stabilizing.
Convergence means that a system eventually stabilizes, yielding an unique result, no matter what scheduling have been chosen.Continuing the previous parallelism, AbU confluence and convergence are analogous to the Church-Rosser property 5 and convergence [41] of Term Rewriting Systems, respectively.Indeed, the latter holds when a Term Rewriting System is both strongly normalizing and Church-Rosser, like AbU convergence holds when a system is both stabilizing and confluent.Definition 8 (Wave weak stabilization, stabilization, confluence and convergence).A stable AbU system S is wave weakly stabilizing, wave stabilizing, wave confluent or wave convergent when for all input upd we have that S upd T S implies S is weakly stabilizing, stabilizing, confluent or convergent, respectively.
Wave weak stabilization means that given an input, then the system may become stable again, after executing that input.In other words, if S upd T S then there exists S such that S upd S .Wave stabilization means that given an input, then the system must become stable again, after executing that input.

D R A F T
In other words, if S upd T S then all execution path starting from S eventually yield a stable system.
Wave confluence means that given an input, then system eventually reaches a unique system after executing that input.In other words, if S upd T S then S eventually reaches a unique system (possibly not stable).
Finally, wave convergence means that given an input, then system eventually stabilizes to an unique system after executing that input.
As we have seen in Subsection 3.3, AbU is in general Turing complete, hence checking requirements as stabilization and confluence is an undecidable problem.For instance, if we were able to decide stabilization for AbU with non-deterministic substitutions we were also able to decide termination of Turing machines.Similarly, if we were able to decide confluence for AbU with non-deterministic substitutions we were also able to decide confluence of rewriting systems, which is known to be undecidable in general [42].Nevertheless, we can still aim for verification procedures for stabilization and confluence that are sound but possibly not complete, i.e., they may fail to recognize stabilizing or confluent systems as such.In the following we will present two sound verification mechanisms for checking stabilization and confluence of AbU systems.

Verifying Stabilization
We now show how stabilization can be statically checked, for a given AbU system, namely we provide a verification mechanism that can be used before the deployment of the system.It basically consists in checking if there are chains of AbU rules in the system that form cycles.
The output resources of an AbU rule, namely the resources involved in the actions performed by the rule, are given by the resources assigned in the default action and in the rule task.The output resources of an action act are the set Out(act The input resources of an AbU rule are the resources that the rule listen on, namely the set In(evt act, task) {x | ∃i ∈ N .evt[i] = x}.Given a list R of AbU rules, its output resources Out(R) are the union of the output resources of all rules in the list.Analogously, its input resources In(R) are the union of the input resources of all rules in the list.More formally: Out(rule i ) and In(rule In(rule i ) Definition 9 (ECA dependency graph).Given an AbU system S = R 1 , ι 1 Σ 1 , Θ 1 . . .R n , ι n Σ n , Θ n , the ECA dependency graph of S is a directed graph (V, E) where vertices (or nodes) V and edges E are: The sufficient syntactic condition for the termination of the wave semantics (i.e., stabilization) consists in the acyclicity of the ECA dependency graph.
Theorem 5 (Soundness for stabilization).Given a stable AbU system S, if the ECA dependency graph of S is acyclic, then S is wave stabilizing.
Proof.The proof is quite long and involved and it requires some preliminary results.For sake of readability, we moved the full proof to Appendix A.2.
A naive termination verification mechanism consists in computing the transitive closure E + of E and to check if it contains reflexive pairs, i.e., elements of the form (x, x), for a resource x.If there are no reflexive elements then the graph is acyclic and the condition is fulfilled.A more efficient solution consists in Algorithm 1.It is a DFS-based algorithm to check cycles in directed graphs.It maintains a stack of visited nodes in the DFS to check back edges.If a back edge in the DFS-traversing of the graph is found, then the graph is not acyclic (Algorithm 1 returns False).The time complexity of Algorithm 1 is mainly due to the DFS search, hence it is O(|V | + |E|), in the worst case.Notice that, in counted once even if it is present in more than one node; hence, |V | counts the number of different variables appearing in the whole system.On the other hand, |E| is bound by the total number of rules of the system.Nevertheless, between each pair of variables there can be at most one edge; hence different rules connecting the same pairs of resources are counted once.
All three AbU systems presented in Section 4 are wave stabilizing, and our verification mechanism is able to correctly state that the systems satisfy the requirement.Indeed, all ECA dependency graphs in the examples are acyclic.
Remark 5. Note that, in some cases, the proposed approach based on the ECA dependency graph may be too restrictive.For instance, many distributed algorithms (e.g., the Bracha-Toueg crash consensus algorithm [43] or the Franklin's election algorithm [44]) are based on rounds, thus requiring some synchronization between nodes.AbU is asynchronous by design, but round computations can be simulated by using indexed variables: each resource x can be an array of variables x 1 x 2 . . .and at round i + 1, events and updates read from ith elements of the array (i.e., x i ) and update the i + 1-th.For instance, an update x ← x * 2 at round i + 1 would be translated to x i+1 ← x i * 2. This round-based mechanism introduces a cyclic dependency on resources, thus failing the proposed stabilization check.This is, in principle, not necessarily bad since rounds-based algorithms may diverge, if not properly designed, and convergence can be proved in different ways (as for [43,44]).Nevertheless, the static condition we have proposed, based on the acyclicity of the ECA dependency graph, is a sufficient but not necessary condition for stabilization.As future work, we plan to develop more precise solutions, i.e., allowing also for some programs having a cyclic ECA dependency graph but that are not actually diverging (as in the case of [43,44]).

Verifying Confluence
In order to verify confluence, the information contained in the ECA dependency graph is not sufficient.Indeed, we need to track not only which resource depends on another, but the ECA rule introducing that dependency as well.We can extend the ECA dependency graph with a label on arcs containing the rule that justifies the dependency.An arc of the form (x, rule, y) means: modifying x we may modify y as well, by applying the rule rule.In the following, we denote an AbU rule of an AbU system by means of a numeric index: r i,j stands for the j th rule of the i th node of the system.Definition 10 (Labeled ECA dependency graph).Given an AbU system S = R 1 , ι 1 Σ 1 , Θ 1 . . .R n , ι n Σ n , Θ n , the labeled ECA dependency graph of S is a directed graph (V, E) where vertices (or nodes) V and labeled edges E are: A finite walk in the labeled ECA dependency graph between the resources x and y is a sequence of rules that connect the two resources (a sort of transitive dependency) and it is given by the labels of the graph.Roughly speaking, a finite walk in the labeled ECA dependency graph represents a possible schedule of updates execution.More formally, given a labeled ECA dependency graph (V, E), two arcs (x, r, y) and (x , r , y ) are joinable, written (x, r, y) (x , r , y ), when y = x .We then define the finite walks between two resources x and y as: Note that, all sequences in the set finite-walks(x, y) are finite, but the set may have an infinite number of elements (meaning that x and y are involved in a cycle).In order to precisely verify confluence, we have to separate finite computations from computations involved in cycles, that not necessarily break confluence.In this respect, since a finite walk is a sequence of indexes (i.e., natural numbers), we can use the Eilenberg-limit in order to represent an infinite set of finite walks by means of a finite set of infinite walks.In particular, we define the set of limit walks between the resources x and y as: limit-walks(x, y) E-limit(finite-walks(x, y)) In this way, we can distinguish finite computations from infinite ones, involved in cycles.Hence, we can formally define the walks that link two resources, consisting in the limit walks, together with the finite walks that are not approximated by any limit walk.Formally, the walks between the resources x and y are: walks(x, y) limit-walks(x, y) ∪ finite-walks(x, y) \ n ∈ pref(n ) n ∈ limit-walks(x, y) The sufficient syntactic condition for the confluence of the AbU semantics consists in checking the cardinality of the walks in the labeled ECA dependency graph between all pairs of nodes.Indeed, if |walks(x, y)| > 1, we have different sequences of rules (i.e., scheduling) that may lead to a modification of y when we modify x, hence possibly breaking confluence.
Unfortunately, confluence depends also on the input that has been performed, not only on the syntactic structure of the AbU rules.Consider the following two rules: x (T) : y ← 1 and z (T) : y ← 2 (2) that seems to be confluent (and, indeed, we have at most 1 walk between each pair of resources).Actually we may have different results if an input changes x and z simultaneously.Indeed, the final value for y can be either 1 or 2, depending on the scheduling.For this reason, we need to augment the labeled ECA dependency graph with dummy vertices and arcs, simulating simultaneous inputs.Let input S i∈[1.
.n] In(R i ) be the input resources of the system We define an input sampling family as an element F ∈ ℘ max (input S ).The latter corresponds to the possible combination of inputs (of S) that can be simultaneously changed by the environment.Chosen a sampling family F = {S 1 , . . ., S k }, which is a finite set, we add to the labeled ECA dependency graph of S all the arcs (s i , r input , x) such that: i ∈ [1..k] and x ∈ S i .Here s i , for i ∈ [1..k], are dummy fresh resources not present in S, and r input represents a dummy rule not present in S. The best case corresponds to the sampling family such that |F| = |input S |, namely when F contains only singletons.In this case, we have that we can change only one resource at each input step 6 .Conversely, the worst case corresponds to the sampling family such that |F| = 1, namely when F contains only the set input S .In this case, we have that we can simultaneously change all (input) resources at each input step.
Continuing the example with the AbU rules in Equation ( 2), suppose to have a sampling family F = {{x, z}}, namely x and y can be simultaneously changed by input steps.The augmented labeled ECA dependency graph of the system can be depicted as: with walks(d, y) = 2, hence we can find the confluence fail.Indeed, with the augmented labeled ECA dependency graph, the cardinality of the walks between each pair of resources provides us a verification mechanism for confluence.
Theorem 6 (Soundness for confluence).Given a stable system S, if for each pair of resources x, y in the (augmented) labeled ECA dependency graph of S we have that |walks(x, y)| ≤ 1, then S is wave confluent.
Proof.The proof is quite long and involved and it requires some preliminary results.For sake of readability, we moved the full proof to Appendix A.2.
A confluence verification mechanism consists in computing the cardinality of the sets walks(x, y), for each pair of resources x and y.Algorithm 2 checks if the number of walks between each pair of resources in the labeled ECA dependency graph is greater than 1 (in that case it returns False).The algorithm first initializes the adjacent matrix adj of the graph (line 1) and then computes the successive powers of the adjacent matrix (lines 2..6), in order to find multiple finite walks.Indeed, in each element (i, j) of adj n we have the number of finite walks of length n between the nodes v i and v j .Hence, computing adj |V |−1 we obtain all the possible finite walks, since we cannot have walks longer than, or equal to, the number of nodes, if we exclude cycles.At each iteration, in line 4 we check if we already have multiple walks between the resources: if it is the case then the algorithm says that the system is not confluent.Once we have checked the finite walks, we need to check eventual multiple limit walks (lines 7..8).If no cycles are detected, then the system is confluent.When adj |V | is not zero, then we have a walk of length |V | involving at most |V | nodes, hence we have a cycle.In this case, we check the out-degree of the nodes in the (initial) adjacent matrix involved in cycles (lines 9..12).To select such nodes, we look at adj |V | , selecting its columns that have at least one non-zero element.Indeed, if a column i has a non-zero element then the corresponding node v i is the last step of a walk with length |V |, hence it is involved in (or it is reachable from) a cycle.For the selected nodes, we compute the out-degree, making the sum of the corresponding row in the initial adjacent matrix adj.If for all nodes the out-degree is less than 2 we have confluence.
The time complexity of the procedure multipleWalks is O(|V | 2 ), in the worst case.Matrix multiplication can be implemented in O(|V | 3 ), hence the total time complexity of the loop at lines 3..6 is O(|V | 4 ), in the worst case.The loop at lines 9..12 has time complexity O(|V | 2 ), in the worst case.Finally, the time complexity of the procedure initWalksCount is O(|V | 2 + | E|), in the worst case.Indeed, the computation of the direct dependencies between resources in the procedure initWalksCount requires to access all elements of E, that may have a cardinality less, equal or greater than the cardinality of V .Hence, the time complexity of the whole Algorithm 2 is O(|V | 4 + | E|), in the worst case.
All three AbU systems presented in Section 4 are wave confluent, but our verification mechanism is able to correctly state that the systems satisfy the requirement only for the first two.Indeed, for the vineyard example, we have two (finite) walks between the resources moisture and valve (one originated by the rule in R s that opens the valve and another originated by the rule in R s that closes the valve).Nevertheless, these two rules cannot yield non-confluent behaviors, since their conditions are disjoint (the two conditions cannot be true at the same time).In this case we have a false positive, since the verification mechanism flags as not correct a system that actually fulfills the requirement.We plan to improve our verification mechanism with more "semantic" checks as a future work.

Towards a Distributed Implementation
In this section, we discuss how the proposed calculus AbU can be implemented.We can basically follow two approaches.We can implement the calculus from scratch, dealing with all the problems related to a

D R A F T return False
Algorithm 2: Detect multiple walks between all pairs of resources in a labeled ECA dependency graph.
distributed infrastructure; or we can extend an existing distributed language with an abstraction layer to support ECA rules and their event-driven behavior.The latter approach can be less efficient, but more suitable for fast prototyping.
In any case, we have to deal with the intrinsic issues of distributed systems.In particular, by the CAP theorem [45] we cannot have, at the same time, consistency, availability and partition-tolerance.Hence, some compromises have to be taken, depending on the application context.For instance, in a scenario with low network traffic we can aim for correctness, implementing a robust, but slow, communication protocol.Vice versa, when nodes exchange data at a high rate (or when the network is not stable), communication should take very short time, hence we may prefer to renounce to consistency in favor of eventual consistency.
For these reasons, a flexible and modular implementation is mandatory, where modules can be implemented in different ways, depending on the application context.Hence, we present a modular architecture suitable to implement AbU nodes, that is summarized in Figure 7.
An AbU node consists in a state (mapping resources to values), an execution pool (a set of updates to execute) and a list of ECA rules (modeling the node behavior).An ECA Rules Engine module is in charge of executing the updates in the pool and to discover new rules to trigger, potentially on external nodes (distributed discovery).This module also implements the attribute-based memory updates mechanism and deals with IoT inputs (from sensors) and outputs (to actuators), which are accessed by means of a dedicated interface.A separate Device Drivers module translates low-level IoT devices primitives to high-level signals for the rule engine and vice versa.
The Distribution module is in charge of joining a cluster of AbU nodes and exchanging messages with them.It embodies all distributed infrastructure-related aspects, that can be tuned to meet the desired context-related requirements.Moreover, it provides the communication APIs needed by the rule engine to implement the (distributed) discovery phase (and, in turn, attributed-based memory updates).For instance, the labels upd T and upd T of the AbU semantics generate a broadcast communication.
In some respects, AbU is quite close to AbC, so we can borrow from one of its implementation the mechanisms that can be easily adapted to AbU.In particular, we can exploit the GoAt [28,29] library, in order to implement the Distribution module.GoAt is written in Golang, so we can delegate the communication layer to a Go routine, encapsulating the send and receive primitives of AbC and the cluster infrastructure, both provided by GoAt.Finally, the Device drivers module can be built on top of GOBOT [46], a mature Go library for the IoT ecosystem, with a great availability of IoT devices drivers.Indeed, in Figure 7   Device Drivers and the Distribution modules can exploit GOBOT and GoAt, respectively.Remark 6. Filling the gap between the theoretical model provided by AbU and an actual implementation of the calculus is not a trivial task.Indeed, some crucial implementation choices should be made.For instance, the implementation should be space-uncoupled: apart from an operation to allow a new node to join an AbU system, the implementation shall provide complete location transparency.In particular, a user shall not (need to) know the address of any node in the system and shall program interactions using AbU primitives only.This requires the development of a suitable distribution module enforcing such requirement; e.g., membership and of member failure detection can be implemented by using a SWIM-like [47] gossip-based protocol.As another example, in the operational semantics of AbU, the discovery phase is executed in a single atomic step.This implies that the partially evaluated tasks must be delivered, to the other nodes, with an atomic "all or none" operation, similarly to causally ordered reliable broadcast.We can enforce such requirement by means of distributed transactions, viewing an AbU system as a distributed data store and performing the discovery phase using a two-phase commit protocol [48].We refer to [49] for more details about the design and implementation of a DSL based on AbU.
At the time of writing, we are developing a prototype implementation for the AbU calculus, written in Golang and following the modular architecture sketched above.The Distribution module is now based on HashiCorp's Memberlist [50], a popular Go library for cluster membership and failures detection that uses a gossip based protocol.We plan to integrate the module with GoAt in the near future.

Conclusion
In this paper we have presented AbU, a calculus merging the simplicity of ECA programming with attribute-based memory updates, This new loosely-coupled interaction mechanism can be seen as the memorybased counterpart of attribute-based communication hinged on message-passing, and fits neatly within the ECA programming paradigm.Therefore, AbU aims to be a formal programming paradigm for smart systems, IoT scenarios and edge computing.To showcase the expressiveness and generality of this calculus, we have modeled with AbU some application situations typical of IoT and smart systems, discussed the Turing completeness of the calculus, and encoded AbC, the paradigmatic calculus for attribute-based communication, into AbU.This result is not meant to prove that AbU subsumes AbC, but to highlight that it is possible to encode attribute-based communication within the ECA rules programming paradigm.
Then, we have used AbU for studying stabilization and confluence, two properties very relevant for IoT and smart devices: the first guarantees that a chain of rule executions triggered by an external event will eventually terminate; the second guarantees that the effects of the rules are eventually deterministic and do not depend on the rule execution order.For both these properties we have provided formal definition, sound syntactic verification criteria, and effective algorithms to statically check such criteria.
Summarizing, AbU, as a formal model, is the basis for investigating important properties of event-driven architectures with attributed-based interaction, and for the development of formal methods for guaranteeing these properties.
Moreover, due to its decentralized nature, AbU helps IoT systems in being more scalable, dropping the dependency on a central controlling service and allowing inter-node (direct) communication.This D R A F T also mitigates availability issues, since no Internet connection and no external controlling nodes, prune to failures, are needed in local executions.In addition, not having the necessity to interact with external unknown/untrusted parties (e.g., the central controlling service on the cloud) results in a more secure setting, by design.Indeed, actual IoT systems should implement complex mechanisms to enforce privacy and security (e.g., by using an encrypted communication), since data is continuously sent on the cloud.Unfortunately, very often these mechanisms are weak, or not present at all, opening to potential attacks.In AbU this problem is mitigated, since no communication to external/untrusted parties is mandatory.Nevertheless, in contexts where an external communication is required, also in the case of AbU suitable security mechanisms should be deployed.
Finally, AbU can be used as a reference model for the implementation of full-fledged programming language, or extensions of existing languages, for IoT and edge computing.Finally, the new interaction model we have introduced in this paper, namely attribute-based memory updates, can be of interest also in other settings and applications, beyond IoT and edge computing.
Future work.The present work is the basis for several research directions.First, we can use AbU for defining suitable behavioral equivalences, e.g., based on bisimulations, to compare systems with their specifications and to specify other properties, such as non-interference.Some results in this direction for verifying safety and security requirements, have been presented in [51].
The smooth integration of attribute-based communication within the ECA paradigm makes easier to extend to the distributed setting many known results and techniques from the literature.In particular, we are interested in porting to AbU the verification techniques developed for ECA languages, such as IRON, a real-world ECA language for IoT [19,17,18].This will also go in par with refining the verification techniques for stabilization and confluence proposed in Section 6, which are sound but sometimes too restrictive; e.g., programs which stabilize even if their ECA dependency graph is cyclic, are ruled out by these conditions.
Concerning implementations, a prototype in Golang of AbU is under development [9,49], as discussed in Section 7. Efficient distributed implementations of AbU could be obtained using RPCs or message-passing, taking inspiration from the implementations of AbC [28,27,29].
Another important subject is distributed run-time verification and monitoring; this would allow us to detect at run-time the violations of given properties, e.g., expressed in temporal logics like the modal µcalculus [52].These would be useful, for instance, to extend (and refine) the criteria presented in Section 6.
Most IoT systems relies on a notion of time to operate.We can reason about AbU system time aspects externally, by counting, for instance, the number of inter-node communications or the internal execution steps.But, an AbU semantics directly embedding a notion of time, possibly stochastic, would result in a more effective and elegant way of reasoning about time aspects of AbU systems.As a future work, we plan to apply the general approach presented in [53,54] to our calculus.
Finally, we plan to investigate the connection between the Field Calculus [13,14] and AbU, in particular whether it is possible to encode the former in our calculus.This would require to define a notion of global goal function (if any) for an AbU system, that is carried out by AbU system nodes taken as whole.
Then, for all Γ , P such that Γ : P δ Γ : P , for some δ, there exists an AbU system Case (Brd).Then: δ = Π v , for some Π and v; P = e @ Π .P , for some P , Π such that {|Π | }(Γ) = Π and e such that e (Γ) = v; P = P ; and Γ = Γ.Let P h r i = firing(P ) be the firing rule of P and j = Next(i).The translation of P generates the following AbU rule: . By definition of Enc and since Next(i) = j, we have that firing(P ) = P h r j .Hence, we have that Θ The last two requirements of Definition 11 are satisfied by the definition of (StepL), that guarantees to perform the discovery of T = ExtTasks(R k , {P h r i , P h r j }, Σ k ) by applying the rule (Disc) with T on all nodes w ∈ [1.
.n] \ {k}.This means that S Furthermore, no attributes of Γ are modified (only auxiliary resources added by the translation are involved in the update).Hence, we also have that S C , concluding the proof for this case.
Case (Rcv).Then: δ = Π(v), for some Π such that Γ |= Π and v; P = (x | Π ).P , for some P and Π such that Γ |= Π [v/x]; P = P [v/x]; and Γ = Γ.Let P h r i = firing(P ) be the firing rule of P and D R A F T j = Next(i).The translation of P generates the following AbU rule: We assumed that Γ : P is the AbC component Γ k : P k of C , so we are on the node k of the AbU translation, i.e., R k , ι k Σ k , Θ k .Since S is firing for C , we have that Θ k contains the update upd = (x, v)(P h r i , ff)(P h r j , tt), by definition of Note that, the satisfiability of the condition Repl(Enc(Π), x)) is guaranteed by Proposition 7B.Since Rule (A.2) is local and it does not have default actions, we have that DefUpds When the AbU semantics evolves with the rule (StepL) (or, equivalently, with the symmetric rule (StepR)) applied to the system S, performing an execution step (Exec), the update upd is committed, obtaining . By definition of Enc and since Next(i) = j, we have that firing(P ) = P h r j .Hence, we have that Θ k is a superset of The last two requirements of Definition 11 are satisfied by the definition of (StepL), that guarantees to perform the discovery of T = ExtTasks(R k , {x, P h r i , P h r j }, Σ k ) by applying the rule (Disc) with T on all nodes w ∈ [1.
.n] \ {k}.This means that ] in P is recorded by updating the resource x with the value v).Furthermore, no attributes of Γ are modified (only auxiliary resources added by the translation are involved in the update).Hence, we also have that S C , concluding the proof for this case.
Case (Upd).Then: P = [a := e]P , for some P and e; Γ = Γ[v/a] , given e (Γ) = v and Γ[v/a] : P δ − → Γ[v/a] : P .Let P h r i = firing(P ) be the firing rule of P and j = Next(i).The translation of P generates the following AbU rule:  Case (Aware).Then: P = [Π]P , for some P and Π such that Γ |= Π, given Γ : P δ − → Γ : P .Let P h r i = firing(P ) be the firing rule of P and j = Next(i).The translation of P generates the following AbU rule: i.e., a linear ordering of the vertices such that for every arc (x, y) of the graph, x comes before y in the ordering.Given |V | = n, we denote with v 1 . . .v n such topological sort, and with indexOf(x) the index in the ordering that correspond to the resource x, namely indexOf(x) = i, with i ∈ [1.
When we modify a resource, by means of an (Input) or (Exec) rule, we may trigger some AbU rules of the system, potentially leading to new updates to add to the pools.The ECA dependency graph provides an over-approximation of the resources involved in such updates.
Definition 12 (Potential updates).Consider an AbU system with acyclic ECA dependency graph.Let v 1 . . .v n a topological sort of its nodes.The set of potential updates originated by a resource x consists of all resources that may be updated when x is modified, and it is defined as: It is easy to note that, mayBeUpdated(x) decreases in the number of elements as indexOf(x) increases.In particular, x / ∈ mayBeUpdated(x) and mayBeUpdated(x) = ∅ when indexOf(x) = n.Similarly, we can define the updates that are actually originated when some resources are modified at runtime.

Definition 13 (Discovered updates). Given the systems S
Given an update upd = (x 1 , v 1 ) . . .(x n , v n ), we define its resources as Vars(upd) {x 1 , . . ., x n }.For a pool Θ (or a generic set of updates), its resources are defined as Vars(Θ) upd∈Θ Vars(upd).Similarly, given an AbU rule rule = evt act, task we define its resources as Vars(rule) Vars(act) ∪ Vars(task), where Vars(act) for an action act, is the set of resources in the left-hand side of the assignments in act and Vars(task), for a task task = cnd : act, is Vars(act).Given a set of rules X, its resources are defined as Vars(X) rule∈X Vars(rule).Given list of AbU rules R = rule 1 . . .rule n and a set of resources X, we define the rules that may modify the resources in X as: mayModifyRules(R, X) {rule i | i ∈ [1..n] ∧ Vars(rule i ) ∩ X = ∅}.Lemma 12. Let S = R 1 , ι 1 Σ 1 , Θ 1 . . .R n , ι n Σ n , Θ n be an AbU system with acyclic ECA dependency graph.Consider a list of AbU rule R i , with i ∈ [1..n], and a set of resources X, then we have: Proof.By definition, Vars(rule) = Out(rule) and rule ∈ Vars(Active(R i , X)) iff In(rule) ∩ X, for any AbU rule rule.By definition of the ECA dependency graph, for any rule ∈ Vars(Active(R i , X)) we have that for any x ∈ In(rule) there exists y ∈ Out(rule) such that (x, y) is an arc of the ECA dependency graph.This means that for any y ∈ Vars(Active(R i , X)) there exists x ∈ X such that (x, y) is an arc of the ECA dependency graph.Since the graph is acyclic, we have that y follows x in the topological sort of the ECA dependency graph, hence y ∈ mayBeUpdated(x).This applies for any y ∈ Vars(Active(R i , X)) and x ∈ X, hence Vars(Active(R i , X)) ⊆ x∈X mayBeUpdated(x).Proof.We have to prove that for all input upd, if S upd T S then S is stabilizing.Consider an arbitrary input upd, we have that S upd T S , for some S .Since the ECA dependency graph of S is acyclic, we have that Vars(discovered(S, upd, S )) ⊆ x∈Vars(upd) mayBeUpdated(x), by applying Lemma 13.This also means that Vars(upd) ∩ Vars(discovered(S, upd, S )) = ∅, namely we cannot discover new updates involving resources that have been currently modified.Similarly, if S upd T S , for some S , by applying again Lemma 13, we have that Vars(discovered(S , upd , S )) ⊆ x∈Vars(upd ) mayBeUpdated(x) and Vars(upd ) ∩ Vars(discovered(S , upd , S )) = ∅.Since the resources of a system are finite, at each execution step we remove an update and, due to Lemma 13, we cannot discover already updated resources (i.e., we cannot add a new update concerning the resources modified by the removed update).This means that the discovered updates set will eventually be empty.Since the initial pools of S are empty, we can conclude that eventually all pools in the system will become empty again, after executing the input upd.In other words, there exists k ∈ N such that S upd 0 T 0 S 0 upd 1 T 1 . . .
Hence, S is stabilizing.Since the initial input upd has been chosen arbitrarily, we can conclude that S is wave stabilizing.
Proof of Theorem 6.In order to prove the theorem, we need some supporting lemmas and some preliminary notions.Given a label α = upd T , we denote with lastof(x, α) the value of the last assignment to the resource x in upd.Formally, given upd = (x 1 , v 1 ) . . .(x k , v k ), we have that lastof(x, upd T ) v i iff x i = x and for all j > i we have that x j = x (the function is undefined when x is not present in upd).Given an update upd = (x 1 , v 1 ) . . .(x k , v k ), we define as Vars(upd) {x 1 , . . ., x n } the set of its resources.Similarly, we define the set of resources of a label α = upd T as Vars(α) Vars(upd).
In the sake of simplicity, when X is a singleton {x}, for some resource x, we write = x in place of = {x} .
The following proposition says that if an AbU system S evolves in two systems S 1 and S 2 that differ in the value of a resource y, then during the execution of S two updates must be discovered (or they are already present in the pools of S), that assign y with two different values.
Lemma 15.If S (x,v) T S and S α1 . . .α l S l then for all l ≤ l there exists a walk w l in the labeled ECA dependency graph of S connecting x with y, given y ∈ Vars(α l ).
Proof.The proof is by induction on l.Suppose l = 1.Since S is stable (i.e., all its pools are empty), we have that the update in α 1 has been discovered during the input step (x, v) T .Then we have that there exists an AbU rule rule such that Vars(α 1 ) = Out(rule) and x ∈ In(rule).This means that (x, rule, y), with y ∈ Out(rule), is an arc of the labeled ECA dependency graph of S. Hence, we have a walk of length 1 connecting x with y, given y ∈ Vars(α 1 ).Suppose now l = k > 1.By inductive hypothesis we have that S (x,v) T S , S α1 . . .
S k−1 and for all k ≤ k − 1 there exists a walk w k in the labeled ECA dependency graph of S connecting x with y, given y ∈ Vars(α k ).Since S is stable (i.e., all its pools are empty), we have that the update in α k has been discovered during the input step (x, v) T or during one of the execution step α k .In the first case, we have a walk of length 1 connecting x with y, given y ∈ Vars(α k ), as it happens in the case l = 1.Otherwise, we can use the inductive hypothesis.So, suppose that the update in α k has been discovered during one of the execution step α k .This means that there exists an AbU rule rule such that Vars(α k ) = Out(rule) and Vars(α k ) ∩ In(rule) = ∅.This means that (y, rule, y ), with y ∈ Vars(α k ) ∩ In(rule) and y ∈ Out(rule), is an arc of the labeled ECA dependency graph of S. By inductive hypothesis, we have that there exists a walk w k connecting x with y, given y ∈ Vars(α k ).Hence, w k = w k rule is a walk connecting x with y , given y ∈ Vars(α k ).Proof.Applying Lemma 15, we have that there exists a walk in the labeled ECA dependency graph of S connecting x with y, given y ∈ Vars((x 1 , v 1 ) . . .(x n , v n ) T ).Since Vars((x 1 , v 1 ) . . .(x n , v n ) T ) = {x 1 , . . ., x n }, we have that there exists a walk connecting x with x i for all x i , with i ∈ [1..n].Hence, walks(x, x i ) = ∅, for all i ∈ [1..n].

Figure 1 :
Figure 1: AbU semantics for nodes and systems.

Figure 3 :
Figure 3: Derivation trees for AbU semantic steps of Subsection 4.1: (Input) [top] and (Exec) [bottom].For space reasons, we abbreviate semantic rule names and omit the premises of leaf semantic rules.

Figure 4 :
Figure 4: A vineyard irrigation system divided in fifteen zones.Each zone has a moisture sensor m i , with i ∈ [1..15], and it covers four vines.Each vine in a zone has a dedicated water valve v i , with i ∈ [1..4].

Figure 6 :
Figure 6: Attribute-based communication in AbU, a receive phase (right) after a send phase (left).

Theorem 4 (
AbC to AbU correctness).For any AbC component C, let S = Enc(C); then for all C such that C * C there exists an AbU system S such that S * * S and S C .

r 2 r
xy : index of x (T) : y ← 1 r zy r zy : index of z (T) : y ← in pu t r in pu t

Figure 7 :
Figure 7: High-level view of a AbU node implementation.
and S is firing for C , with C = C [Γ : P Γ : P ].Proof.The only rule applicable is (Comp), namely Γ : P δ Γ : P is obtained from Γ : P δ − → Γ : P .The proof is by induction on the derivation tree for Γ : P δ − → Γ : P .Depending on the last rule used in the derivation, we have the following cases.Case (Zero).Then: δ = ff 0 ; P = P = 0; and Γ = Γ.Setting S = S, we have the conclusion, since C = C.
a] : P ].Furthermore, the only attribute modified in Γ is a, which is updated with the value v by the AbU semantics in Σ k .Hence, we also have that S C .Since the derivation tree for Γ[v/a] : P δ − → Γ[v/a] : P is smaller than the derivation tree for Γ : P δ − → Γ[v/a] : P , by inductive hypothesis we have that there exists S such that S C and S is firing for C , noting that C = C [Γ[v/a] : P Γ[v/a] : P ].This concludes the proof for the case.

Lemma 16 .
If S (x,v) T S and S * (x1,v1)...(xn,vn) T S , then for all x i , with i ∈ [1..n], there exists a walk in the labeled ECA dependency graph of S connecting x with x i .In other words, walks(x, x i ) = ∅, for all i ∈ [1..n].
When s 2 does not occur in s 1 , then s 1 ?|s2 returns −1.By means of these operators we can implement non-deterministic string substitutions.Consider the following AbU rule: by applying the rule (Exec), with Σ 3 = [role → logger log → 167.123.23.2, 15 : 07 : 00, camera Blist → by applying the rule (Exec).Here, Σ 4 = [role → logger log → 167.123.23.2, 15 : 07 : 00, camera Blist → 167.123.23.2 IDS → ] and Θ = {(IDS, 167.123.23.2, 15 : 07 Observations A and B are trivial, they hold by definition of the translation function Enc.For the observation C, we can note, by the definition of Enc, that each action in the translated rule originated from P 1 is local, hence all modifications are on the current node 1.This means that no updates on attributes and rule flags are made on other nodes i, with i ∈ [2..n].The only rules updating external nodes are the send rules, with the action msg ← Enc(e), which modifies a state in a node i such that i ∈ [2..n].But, msg is an auxiliary resource introduced by the translation, it is not an attribute of any Γ i , with i ∈ [2..n], nor a rule flag of any i, with i ∈ [2..n].Finally, for the observation D, we have that {|Π| }(Γ i ) substitutes the instances this.a with Γ i (a) = v in Π, and lets untouched the instances a. Instead, Ext(Π) substitutes the instances of a not prefixed by this.(in Π) with a (and then apply the translation Enc).It is easy to note that in Γ j |= Π each original instance of this.a in Π now takes the value Γ i (a) and each instance of a takes the value Γ j (a).Similarly, in Σ j |= {|Ext(Enc(Π))| }Σ i each original instance of this.a in Π takes the value Σ i (a) and each instance of a takes the value Σ j (a).But, by the observation A, we have that Γ i (a) = Σ i (a) and Γ j (a) = Σ j (a).Consider an AbC component C = Γ 1 : P 1 . . .Γ n : P n and an AbU system S = R 1 , ι 1 Σ 1 , Θ 1 . . .R n , ι n Σ n , Θ n , such that R i = Enc i (P i ), for i ∈ [1..n].Let C = Γ 1 : P 1 . ..Γ n : P n be a residual of C such that SC and S is firing for C .Let Γ : P be a component of C , namely Γ : P = Γ k When the AbU semantics evolves with the rule (StepL) (or, equivalently, with the symmetric rule (StepR)) applied to the system S, performing an execution step (Exec), the update upd is committed, obtaining Σ k = Σ k [ff/P h r i tt/P h r j ].The discovery phase launched during (StepL) computes Θ 1)We assumed that Γ : P is the AbC component Γ k : P k of C , so we are on the node k of the AbU translation, i.e., R k , ι k Σ k , Θ k .Since S is firing for C , we have that Θ k contains the update upd = (P h r i , ff)(P h r j , tt), by definition of DefUpds(R k , {P h r i }, Σ k ).Since Rule (A.1) is not local we have that LocalUpds(R k , {P h r i }, Σ k ) = ∅.For the same reason, we have that ExtTasks(R k , {P h r i }, Σ k ) = T , with T = (Ext(Π)) : msg ← v, given Enc(e) Σ k = v (justified by Proposition 7A).Furthermore, for all w ∈ [1..n] \ {k} we have that Θ w is a superset of {(msg, v) | Σ w |= Ext(Π)}.
LocalUpds(R k , {P h r j }, Σ k ).The last two requirements of Definition 11 are satisfied by the definition of (StepL), that guarantees to perform the discovery of T = ExtTasks(R k , {a, P h r i , P h r j }, Σ k ) by applying the rule (Disc) with T on all nodes w ∈ [1..n] \ {k}.This means that S 3)We assumed that Γ : P is the AbC component Γ k : P k of C , so we are on the node k of the AbU translation, i.e., R k , ι k Σ k , Θ k .Since S is firing for C , we have that Θ k contains the update upd = (a, v)(P h r i , ff)(P h r j , tt), by definition of LocalUpds(R k , {P h r i }, Σ k ).Here, the value v in (a, v) is justified by Proposition 7A.Since Rule (A.3) is local and it does not have default actions, we have that DefUpds(R k , {P h r i }, Σ k ) = ∅ and ExtTasks(R k , {P h r i }, Σ k ) = ε.When the AbU semantics evolves with the rule (StepL) (or, equivalently, with the symmetric rule (StepR)) applied to the system S, performing an execution step (Exec), the update upd is committed, obtaining Σ k = Σ k [v/a ff/P h r i tt/P h r j ].The discovery phase launched during (StepL) computes Θ k = Θ k \ {upd} ∪ DefUpds(R k , {a, P h r i , P h r j }, Σ k ) ∪ LocalUpds(R k , {a, P h r i , P h r j }, Σ k ).By definition of Enc and since Next(i) = j, we have that firing(P ) = P h r j .Hence, we have that Θ k is a superset of DefUpds(R k , {P h r j }, Σ k ) ∪ that S upd T S or S upd T S , we define the discovered updates discovered(S, upd, S ) as the new updates inserted in the pools, given by the actuation of the update upd.Formally: discovered(S, upd, S ) i∈[1..n]