Causality interfaces for actor networks

Abstract

We consider concurrent models of computation where "actors" (components that are in charge of their own actions) communicate by exchanging messages. The interfaces of actors principally consist of "ports," which mediate the exchange of messages. Actor-oriented architectures contrast with and complement object-oriented models by emphasizing the exchange of data between concurrent components rather than transformation of state. Examples of such models of computation include the classical actor model, synchronous languages, dataflow models, process networks, and discrete-event models. Many experimental and production languages used to design embedded systems are actor oriented and based on one of these models of computation. Many of these models of computation benefit considerably from having access to causality information about the components. This paper augments the interfaces of such components to include such causality information. It shows how this causality information can be algebraically composed so that compositions of components acquire causality interfaces that are inferred from their components and the interconnections. We illustrate the use of these causality interfaces to statically analyze timed models and synchronous language compositions for causality loops and dataflow models for deadlock. We also show that that causality analysis only needs to be performed for one port in each directed communication cycle, and we give a conservative approximation technique for handling dynamically changing causality properties.

Time-Centric Models For Designing Embedded Cyber-physical Systems

“…PTIDES relies on software components providing information about model delay they introduce. This information is captured by causality interfaces [24], and causality analysis is used to ensure that DE semantics is preserved in an execution. The precise causality analysis when modal models are allowed is undecidable in general, but we expect that common use cases will yield to effective analysis.…”

“…This analysis is done at design time. PTIDES components include causality interfaces with algebraic compositionality properties [24], enabling automatic analysis. At runtime, the only test performed to ensure DE semantics is to compare timestamps to physical time with an offset (in the previous example, the offset is −d 2 + n + s).…”

Requirements for Hybrid Cosimulation

“…The FMI 2.0 specification supports an optional element for specifying such dependencies between input and output ports. For a detailed discussion of such causality relations, see [23]. …”

Linking multiple workflow provenance traces for interoperable collaborative science

“…This rule for ddep is a default assumption in many models of provenance: unless further information is available, one assumes that all outputs of invocation a may depend on all inputs of that invocation a. In some models of computation (MoCs), however, this is an overestimate of the true dependencies: e.g., sometimes not all output ports depend on all input ports [27], or not all input data items are used in the computation of the output items (e.g., in a sliding-window aggregate [19], or in MoCs such as COMAD that pass some (out-of-scope) items through an actor, without "seeing" those items [6]). In the following, we focus on data dependencies ddep as the main provenance relation, whether it has been derived via the above rule or recorded directly by the workflow system.…”