Results 11 - 20
of
64
Causality Interfaces and Compositional Causality Analysis
- FIT 2005 PRELIMINARY VERSION
, 2005
"... In this paper, 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 w ..."
Abstract
-
Cited by 10 (8 self)
- Add to MetaCart
In this paper, 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 transfer of control. Examples of such models of computation include the classical actor model, synchronous languages, dataflow models, and discrete-event models. 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 discrete-event models for uniqueness of behaviors, synchronous models for causality loops, and dataflow models for schedulability.
Classes and Inheritance in Actor-Oriented Design
, 2007
"... Actor-oriented components emphasize concurrency and temporal semantics and are used for modeling and designing embedded software and hardware. Actors interact with one another through ports via a messaging schema that can follow any of several concurrent semantics. Domainspecific actor-oriented lang ..."
Abstract
-
Cited by 9 (5 self)
- Add to MetaCart
Actor-oriented components emphasize concurrency and temporal semantics and are used for modeling and designing embedded software and hardware. Actors interact with one another through ports via a messaging schema that can follow any of several concurrent semantics. Domainspecific actor-oriented languages and frameworks are common (Simulink, LabVIEW, SystemC, etc.). However, they lack many modularity and abstraction mechanisms that programmers have become accustomed to in object-oriented components, such as classes, inheritance, interfaces, and polymorphism, except as inherited from the host language. This paper shows a form that such mechanisms can take in actor-oriented components, gives a formal structure, and describes a prototype implementation. The mechanisms support actor-oriented class definitions, subclassing, inheritance, and overriding. The formal structure imposes structural constraints on a model (mainly the “derivation invariant”) that lead to a policy to govern inheritance. In particular, the structural constraints permit a disciplined form of multiple inheritance with unambiguous inheritance and overriding behavior. The policy is based formally on a generalized ultrametric space with some remarkable properties. In this space, inheritance is favored when actors are “closer” (in the generalized ultrametric), and we show that when inheritance can occur from multiple sources, one source is always unambiguously closer than the other.
crystallization papers
- Science
, 1998
"... Cyber-Physical Systems (CPS) are integrations of computation with physical processes. Embedded computers and networks monitor and control the physical processes, usually with feedback loops where physical processes affect computations and vice versa. In the physical world, the passage of time is ine ..."
Abstract
-
Cited by 5 (1 self)
- Add to MetaCart
Cyber-Physical Systems (CPS) are integrations of computation with physical processes. Embedded computers and networks monitor and control the physical processes, usually with feedback loops where physical processes affect computations and vice versa. In the physical world, the passage of time is inexorable and concurrency is intrinsic. Neither of these properties is present in today’s computing and networking abstractions. I argue that the mismatch between these abstractions and properties of physical processes impede technical progress, and I identify promising technologies for research and investment. There are technical approaches that partially bridge the abstraction gap today (such as real-time operating systems, middleware technologies, specialized embedded processor architectures, and specialized networks), and there is certainly considerable room for improvement of these technologies. However, it may be that we need a less incremental approach, where new abstractions are built from the ground up. The foundations of computing are built on the premise that the principal
Actor-Oriented Control System Design: A Responsible Framework Perspective
- IEEE Transactions on Control System Technology , Draft version
, 2003
"... Complex control systems are heterogeneous, in the sense of discrete computer-based controllers interacting with continuous physical plants, regular data sampling interleaving with irregular communication and user interaction, and multilayer and multimode control laws. This heterogeneity imposes grea ..."
Abstract
-
Cited by 5 (0 self)
- Add to MetaCart
Complex control systems are heterogeneous, in the sense of discrete computer-based controllers interacting with continuous physical plants, regular data sampling interleaving with irregular communication and user interaction, and multilayer and multimode control laws. This heterogeneity imposes great challenges for control system design in terms of end-to-end control performance modeling and simulation, traceable refinements from algorithms to software/hardware implementation, and component reuse. This paper presents an actor-oriented design methodology that tackles these issues by separating the data-centric computational components (a.k.a. actors) and the controlflow-centric scheduling and activation mechanisms (a.k.a. frameworks). Semantically different frameworks are composed hierarchically to manage heterogeneous models and achieve actor and framework reuse. We introduce a notion of responsible frameworks to characterize the property that a framework can aggregate individual actor’s execution into a well-defined composite execution such that heterogeneous models can be composed. This methodology is implemented in the Ptolemy II software environment. We discuss how some of the most useful models for control system design are implemented as responsible frameworks. As an example, the methodology and the Ptolemy II software environment is applied to the design of a distributed, real-time software implementation of a pendulum inversion and stabilization system.
An Introduction to Modeling Embedded Analog/Mixed-Signal Systems using SystemC AMS Extensions By
"... ..."
Execution Strategies for PTIDES, a Programming Model for Distributed Embedded Systems
"... Abstract—We define a family of execution policies for a programming model called PTIDES (Programming Temporally Integrated Distributed Embedded Systems). A PTIDES application (factory automation, for example) is given as a discreteevent (DE) model of a distributed real-time system that includes sens ..."
Abstract
-
Cited by 5 (5 self)
- Add to MetaCart
Abstract—We define a family of execution policies for a programming model called PTIDES (Programming Temporally Integrated Distributed Embedded Systems). A PTIDES application (factory automation, for example) is given as a discreteevent (DE) model of a distributed real-time system that includes sensors and actuators. The time stamps of DE events are bound to physical time at the sensors and actuators, turning the DE model into an executable specification of the system with explicit real-time constraints. This paper first defines a general execution strategy that conforms to the DE semantics, and then specializes this strategy to give practical, implementable and distributed policies. Our policies leverage network time synchronization to eliminate the need for null messages, allow independent events to be processed out of time stamp order, thus increasing concurrency and making more models feasible (w.r.t. real-time constraints), and improve fault isolation in distributed systems. The policies are given in terms of a safe to process predicate on events that depends on the time stamp of the events and the local notion of physical time. In a simple case we show how to statically check whether program execution satisfies timing constraints. 1 I.
Source-to-Source Architecture Transformation for Performance Optimization in BIP
"... Abstract—BIP (Behavior, Interaction, Priorities) is a component framework for constructing systems from a set of atomic components by using two kinds of composition operators: interactions and priorities. In this paper we present a method that transforms the interactions of a component-based program ..."
Abstract
-
Cited by 5 (2 self)
- Add to MetaCart
Abstract—BIP (Behavior, Interaction, Priorities) is a component framework for constructing systems from a set of atomic components by using two kinds of composition operators: interactions and priorities. In this paper we present a method that transforms the interactions of a component-based program in BIP and generates a functionally equivalent program. The method is based on the successive application of three types of source-to-source transformations: flattening of components, flattening of connectors and composition of atomic components. We show that the system of the transformations is confluent and terminates. By exhaustive application of the transformations, any BIP component can be transformed into an equivalent monolithic component. From this component, efficient C code can be generated. The method combines advantages of component-based description such as clarity, incremental construction and reasoning with the possibility to generate efficient monolithic code. It has been integrated in the design methodology for BIP and it has been successfully applied to two non trivial examples described in the paper. I.
Model Engineering using Multimodeling ⋆
"... Abstract. We study the simultaneous use of multiple modeling techniques in the design of embedded systems. We begin with a pre-existing Statecharts model of a simple case study, a traffic light for a pedestrian crossing, using it to illustrate the need for multimodeling and the pitfalls. The origina ..."
Abstract
-
Cited by 4 (2 self)
- Add to MetaCart
Abstract. We study the simultaneous use of multiple modeling techniques in the design of embedded systems. We begin with a pre-existing Statecharts model of a simple case study, a traffic light for a pedestrian crossing, using it to illustrate the need for multimodeling and the pitfalls. The original model combines two distinct models of computation (MoCs), finite state machines (FSMs) and synchronous/reactive (SR). We add an additional MoC, a discrete-event (DE) model of the environment in which the traffic light operates, including a simple fault model, yielding a model that combines three different modeling techniques. We construct a second model of a hardware deployment and a third model that is an abstraction used for formal verification. The result is that this simple example uses three distinct models of the system (functional, deployment, verification), two of which hierarchically combine distinct modeling techniques (DE, SR, FSM). This exercise reveals some pitfalls of model-based design where multiple models are needed as well as some of the opportunities. 1

