Contents:
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.
Primary Model Transformation Developer: Thomas Huining Feng
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.
Primary Ptera Developer: Thomas Huining Feng
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.
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.
For certain actors there is a relation between the widths of the input ports and the widths of the output ports. To resolve this problem, width constraints on ports have been introduced. There exists two types of width constraints. The first one imposes an equality constraints between two different ports. With the second type of constraints you can set the width of a port equal to a certain parameter.
The last step of the algorithm is a consistency check in which it is checked that the solution obtained by the width inference algorithm is a unique one. A non unique solution is treated as a error.
In this release the default width has also been changed from 1 to Auto.
(Bert Rodiers)
This release contains capabilities to generate, from Ptolemy models, other types of models, suitable for formal verification. In particular, the Formal Model Converter component (developed by Chihhong Patrick Cheng) allows to generate models compatible with the SMV or NuSMV model-checkers, from Ptolemy models in the SR domain. Also, the RTMaudeCodeGenerator component (developed by Kyungmin Bae) allows to generate models compatible with the Real Time Maude tool, from Ptolemy models in the DE domain.
Please see the Verification README file for details.
Please see the ptolemy.actor.gui.properties documentation for details.
(Thomas Huining Feng)
ThreadedComposite demonstrations
(Edward A. Lee)Lazy Composite classes
-printPDF
command line argument. This option finds the first printer with the
string PDF
in the name and then prints to that printer.
Thus, -printPDF
requires that the full (non-free) version of
Adobe Acrobat be installed, or some other method of printing to PDF.
Unfortunately, the location of the resulting PDF file is not easily
controlled, on the Mac look in ~/Documents/Java Printing.pdf
.
Old Class | New Class |
---|---|
ptolemy.actor.gui.DependencyHighlighter | ptolemy.vergil.basic.DependencyHighlighter |
ptolemy.actor.lib.CodegenActor | ptolemy.actor.lib.jni.CodegenActor |
ptolemy.vergil.actor.lib.LEDMatrix | |
ptolemy.actor.lib.gui.ModelDisplay | ptolemy.vergil.actor.lib.ModelDisplay |
ptolemy.codegen.c.actor.lib.CodegenActor was moved to | ptolemy.actor.lib.jni.CodegenActor |
ptolemy.codegen.c.actor.lib.gui.LEDMatrix | ptolemy.codegen.c.vergil.actor.lib.LEDMatrix |
ptolemy.codegen.kernel.Director | ptolemy.codegen.actor.Director |
ptolemy.domains.curriculum.DependencyHighlighter was moved to | vergil.actor.basic.DependencyHighlighter |
ptolemy.domains.sr.lib.AbsentToken | ptolemy.data.AbsentToken |
ptolemy.domains.sr.lib.ButtonTime | ptolemy.domains.sr.lib.gui.ButtonTime |
ptolemy.domains.sr.lib.NonStrictDisplay | ptolemy.domains.sr.lib.gui.NonStrictDisplay |
ptolemy.moml.SharedParameter | ptolemy.actor.parameters.SharedParameter |
ptolemy.vergil.kernel.ConfigureUnitsAction | ptolemy.vergil.kernel.unit.ConfigureUnitsAction |