Tour of What's New in Version 8.0.beta

See also What's New in other versions.

Contents:

Highlights

 

Model Transformation

The model transformation facility provides a framework for the analysis and transformation of actor models using model transformation techniques.

The design of large-scale models poses a number of challenges. As the size of the models increases to thousands of actors or hundreds of thousands of actors, analysis and consistent modification on the models become extremely hard. Furthermore, to maximize component reuse, a systematic approach is needed for the specification and maintenance of common patterns in the models and the transformation of those patterns.

The model transformation framework to be developed in this project aims to support the flexible specification of patterns and replacements by means of rules in graph grammar. An intuitive graphical user interface will be built. For novice users, a set of common transformations will be included in a library to facilitate their common tasks.

The transformations are models in their own right. They can be embedded in larger models hierarchically. Heterogeneous models of computation can be used to control the application of individual "atomic" transformations. This makes it easy to create sophisticated transformations by composing simple ones in a manageable and disciplined way. The sophisticated transformations will also take advantage of the concurrency inherent in those models of computation.

Model transformation can be applied as an optimization of modal models. These are hierarchical state machines with refinements in their states, which are sub-models to be executed when those states are active. The current implementation includes the complete description of each refinement in the model description, even though refinements of the states in a state machine tend to have large commonality. With the transformation technique, only one refinement needs to be stored completely. The others are obtained by transformations performed on the stored refinement. This eliminates redundancy and eases the job of modifying multiple refinements consistently.

Other applications of the model transformation technique include recognizing common design patterns in the models in a static analysis, replacing exiting design patterns with more efficient ones, and reusing design patterns by incorporating them into new models.

References

Model Transformation Demonstrations

Primary Model Transformation Developer: Thomas Huining Feng

 

Ptera (Ptolemy Event Relationship Actor) Domain

The Ptera (Ptolemy Event Relationship Actor) domain is a discrete-event model of computation. A model in Ptera is represented with a graph of nodes and edges, where nodes represent events and directed edges between events represent scheduling relation. One or more events can be selected as initial events, which are scheduled at model time 0.0. When an event is fired, it possibly performs certain actions, and if there are outgoing edges from that event, the events at the end points of those edges are scheduled after non-negative delays. One or more events can also be selected as final events. The firing of final events causes the event queue to be emptied after their actions are performed, and therefore no more events can be processed.

The Ptera domain supports a different kind of modal models called PteraModalModels, compared to modal models using FSMs (Finite State Machines) as the control. A PteraModalModel uses Ptera at the top level, and each event is refined into a sub-model. The refinements can use Ptera and any other Ptolemy models of computation.

A Ptera model is timed. Although it should work in many domains, the DE (Discrete-Event) domain or Ptera domain itself are recommended. When embedded in those domains, the scheduling of the Ptera model is delegated to the container by calling the fireAt() function of its director.

There are many useful additional features for Ptera, such as canceling edges and parameters. A canceling edge, denoted by a dotted line, cancels a previously scheduled event instead of scheduling a new one. If the pointed to event has multiple instances in the event queue, then the first instance is cancelled. Events may also have parameters, and the actual values for those parameters are specified by the expressions on the edges that schedule them. Those expressions are evaluated at run-time. The events may refer to the values of those parameters in their actions by parameter names.

References

Ptera Domain Demonstrations

Primary Ptera Developer: Thomas Huining Feng

 

Causality Analysis

Ptolemy II 8.0 includes an update to our Causality Analysis framework. We identified performance problems with our current non-conservative causality analysis for modal models within discrete-event (DE) systems. In this scheme, causality analysis is performed on the entire model at run time each time there is a mode change in the model. This mechanism is far too costly. We are investigating techniques for performing the causality analysis in a compositional way for the various modes at compile time. Unfortunately, brute force solutions result in exponentially growing memory requirements for the results of the causality analysis.

We designed, implemented and reviewed an interface that defines a causality interfaces for actor networks as described in the paper "Causality Interfaces for Actor Networks."

Causality interfaces are also described in Ye Zhou Ph.D. Thesis, "Interface Theories for Causality Analysis in Actor Networks."

Causality interfaces represent dependencies between input and output ports of an actor and can be used to perform scheduling or static analysis on actor models.

This substantial new work helps address performance problems in large Discrete Event (DE) models. The new work provides more efficient static analysis for directed cycles and scheduling. This work solved a bug concerning execution time with DE models that had many actors at one level of hierarchy. The table below illustrates the improvement.
# of actors Total execution time before Total execution time after
100 ~0.2 sec. ~0.2 sec.
600 149 sec. 0.7 sec.

One of the challenges in complex, heterogeneous models is that portions of the model have temporal behavior while other portions are purely functional. We have reworked the interfaces that hierarchically heterogeneous models in Ptolemy II present to one another for managing the passage of time. This rework supports much more robust multithreaded and distributed execution without compromising temporal coherence. Concretely, we have defined a formalism whereby a model requests temporal behavior of its container in the hierarchy, and the container responds with an indication of the extent to which it can honor the request. If the extent is sufficient for the application, then the models are compatibly composed. Otherwise, they are not, and the model is marked defective.

Causality Analysis Demonstrations

References

 

Continuous and Modal Domains

Ptolemy II 8.0 includes a substantial rework of modal models and the underlying finite state machine infrastructure to make them work predictably and consistently across domains.

Ptolemy II 8.0 includes a new implementation of continuous-time models based on the semantics given in "Synchronous Language Principles for Heterogeneous Modeling and Design of Embedded Systems." In particular, the Continuous domain cleanly supports continuous-time models (using an ODE solver), discrete-event models, and arbitrary mixtures of the two, including signals that combine continuous-time segments with discrete events. It also interoperates cleanly with most other domains (pretty much all except PN and Rendezvous, for which there does not appear to be reasonable semantic model of such an interaction). Modal models are also cleanly supported with the Continuous domain, enabling hybrid system modeling with a rigorous semantics. The Continuous domain is expected to eventually replace CT.

New Continuous and Modal Demonstrations

Continuous
Modal
The Modal models below are copies of the FSM models with the same name but the Modal models use the continuous domain, whereas the FSM models use the ct domain.

References

Other Key New Capabilities

Additional Features

New demonstrations

Discrete Event (DE)

Process Network (PN)

Synchronous Dataflow (SDF)

Synchronous/Reactive (SR)

PN Code Generation

PN Code Generation was removed after Ptolemy II 8.0 because it never really worked in in 8.0.

SDF Code Generation

Wireless

See also the Complete Demonstrations page.

New and Enhanced Actor Libraries

Other new classes

Works in Progress

Bug fixes

For the current list of bugs, see Ptolemy II Bugs
and
Kepler Bugs