Time-Fluid Field-Based Coordination through Programmable Distributed Schedulers

Abstract

Emerging application scenarios, such as cyber-physical systems (CPSs), the Internet of Things (IoT), and edge computing, call for coordination approaches addressing openness, self-adaptation, heterogeneity, and deployment agnosticism. Field-based coordination is one such approach, promoting the idea of programming system coordination declaratively from a global perspective, in terms of functional manipulation and evolution in "space and time" of distributed data structures called fields. More specifically regarding time, in field-based coordination (as in many other distributed approaches to coordination) it is assumed that local activities in each device are regulated by a fair and unsynchronised fixed clock working at the platform level. In this work, we challenge this assumption, and propose an alternative approach where scheduling is programmed in a natural way (along with usual field-based coordination) in terms of causality fields, each enacting a programmable distributed notion of a computation "cause" (why and when a field computation has to be locally computed) and how it should change across time and space. Starting from low-level platform triggers, such causality fields can be organised into multiple layers, up to high-level, collectively-computed time abstractions, to be used at the application level. This reinterpretation of time in terms of articulated causality relations allows us to express what we call "time-fluid" coordination, where scheduling can be finely tuned so as to select the triggers to react to, generally allowing to adaptively balance performance (system reactivity) and cost (resource usage) of computations. We formalise the proposed scheduling framework for field-based coordination in the context of the field calculus, discuss an implementation in the aggregate computing framework, and finally evaluate the approach via simulation on several case studies.

ScaFi: A Scala DSL and Toolkit for Aggregate Programming

“…Using this API, a developer can integrate ''aggregate functionality'' into its system-what remains to be specified are the details of the aggregate execution model and the communication among devices, that may change in different applications. Devices must continuously run the aggregate program, but the scheduling of these computation rounds can be tuned as the application needs [32]. Exports must be shared with neighbouring devices to allow them to properly set up their Contexts, but the network protocol to be used to do so can be selected independently of the program.…”

A field-based computing approach to sensing-driven clustering in robot swarms

“…A field-based program steers the collective adaptive behaviour of a system, which unfolds by having each agent in the system evaluate that program according to the discussed round-based execution model. Notice that such a program specifies both what local processing the agents must perform and what data they must share with neighbours; also, notice that generally the program does not affect the round-based execution protocol-unless advanced forms of scheduling are desired (Pianini et al, 2021a). The distributed execution protocol may be provided by a middleware, which will ensure that messages are exchanged and rounds properly scheduled.…”

“…The distributed execution protocol may be provided by a middleware, which will ensure that messages are exchanged and rounds properly scheduled. The reader can refer to Pianini et al (2021a) and Casadei et al (2022b), respectively, for a more comprehensive discussion on execution and deployment aspects.…”

Addressing Collective Computations Efficiency: Towards a Platform-level Reinforcement Learning Approach

“…We are interested in stabilisation times as, in cases when the execution of other algorithms depend on the network partitioning (as in the case of the SCR pattern [10]), then even a small improvement on the stability or convergence time can lead to much faster adaptation. This potentially translates to fewer rounds required to stabilise and lower power consumption, especially if advanced scheduling strategies (reactive or partially reactive, as in [46]) are used. One simple metric would have been the time required for the whole network to stabilise, but such a metric can not tell apart "almost stabilised" scenarios from completely off ones, while we want an indication of the quality of the transient.…”