Tour of Ptolemy II
If you are viewing this from within Vergil, the graphical
editor for Ptolemy II, then
many of the following links will open models that highlight the
key features of Ptolemy II. If you are using an ordinary
web browser, then you will see the XML definition of the models.
To run the models in Vergil,
click on the red triangle in the toolbar. The
diagrams are fully editable, so feel free to explore.
You can also access the complete list of demos
and the summary of
new capabilities
. Contents:
Ptolemy II can be used to build sophisticated application domainspecific modeling capabilities
and frameworks. These frameworks can be packaged as separate executable
applications (e.g. HyVisual or VisualSense)
or accessed from within Ptolemy II. Here, we illustrate some such frameworks.
 Modeling of wireless networks: WirelessSoundDetection
(see also
VisualSense introduction).
The wireless domain in Ptolemy II
provides discreteevent modeling of wireless communication systems.
It is useful for modeling and design of communication protocols,
networking strategies, and applications such as sensor networks.
The VisualSense package
is a subset of Ptolemy II that includes the wireless domain and channel models
plus domains that support the design of nodes in a wireless network.
The WirelessSoundDetection
example models a sound localization problem, where single sound source
moves through a field of sound sensors. In the example, sound sensors detect the sound
and communicate via a radio channel to a sensor fusion component that
localizes the sound by triangulation. Two distinct channel models are used,
one that models sound propagation and one that models radio communication.

Modeling of hybrid systems:
StickyMasses
(see also
BouncingBall,
FurutaPendulum,
NewtonsCradleAnimated,
and
Hybrid Plant).
Hybrid systems are a special case of modal models
where finitestate machines (FSMs) are combined with the continuoustime models
to get mixed continuoustime and discreteevent models.
The StickyMasses
example models a physical system consisting of two point masses
on springs that stick together when they collide.

Stochastic hybrid systems:
Noise
(see also
IncreasingRatePoisson,
HysteresisWithRandomDelay,
Brownian
).
Stochastic hybrid systems add random behavior to continuoustime models mixed
with discrete events. The
Noise
(and Noise
Spectrum
,
Sinusoid
In Noise
) models
show bandlimited Gaussian noise processe.
IncreasingRatePoisson
models spontaneous mode transitions governed by a Poisson process.
The HysteresisWithRandomDelay
example uses similar spontaneous mode transitions to model random delay in mode transitions.
The Brownian example
models a stochastic differential equation describing a random walk process.
 Signal Processing:
MaximumEntropySpectrum
(See also
LMSAdaptive,
SynthesizedVoice,
FourierSeries, and
SoundSpectrum)
Ptolemy II includes an extensive library and models of computation suitable for
digital signal processing, communication systems design, and image and video processing.
The MaximumEntropySpectrum
example shows spectral estimation of sinusoids in noise.
It illustrates models the use of synchronous dataflow (SDF) for signal
processing, and also shows many basic capabilities like
hierarchical models,
the Expression actor, and the signal processing actor library.
A particular capability of Ptolemy II is the ability to mix models of computation.
These examples illustrate some of these capabilities.
 Modal Models:
ModalModel
A modal model is one whose behavior depends on its "mode"
of operation. A modal model in Ptolemy II heterogeneously combines the
finite state machine (FSM) domain
combined hierarchically with other models. A state in the FSM represents
a mode of operation, and can have a refinement that gives the behavior
in that mode.
The refinement can be another FSM or some other model using some other
Ptolemy domain. The ModalModel example combines DE, FSM, and SDF to model a
system where regularly sampled signals are perturbed by irregular
events in time.
 MixedSignal Modeling:
SigmaDelta
This example shows how to combine continuoustime modeling
with discreteevent modeling to get mixedsignal modeling.
The example models a MEMS accelerometer where a digital circuit
implements feedback control and A/D conversion (a design due to
Mark Lemkin).
(see also
Switching Continuous
)
Many common models of computation have been implemented in
Ptolemy II. This section illustrates some of them.
 Synchronous Dataflow:
Spectrum (See also
MaximumEntropySpectrum,
FourierSeries, and
SoundSpectrum)
This example shows simple spectral estimation of the product
of two sinusoids in noise. It illustrates models the use of synchronous dataflow (SDF) for signal
processing, and also shows many basic capabilities like
hierarchical models,
the Expression actor, and the signal processing actor library.
In SDF, the firing of actors is statically scheduled, and at the start of execution,
boundedness and deadlock conditions are checked.
 ContinuousTime Modeling:
Lorenz (see also
Lorenz with DifferentialSystem,
SquareWave,
Sinusoid)
This example shows a continuoustime
nonlinear feedback system that exhibits
chaotic behavior (this system is called a Lorenz attractor).
It illustrates the continuous domain,
which uses an underlying solver for ordinary differential equations
and cleanly supports mixtures of discrete events and continuoustime
signals.
 DiscreteEvent Modeling:
Inspection
(see also
QueueAndServer,
Router,
and TimingParadox
).
This example shows
a famous paradox in probability called the inspection paradox.
It illustrates use of the discreteevent (DE) domain, where
events occur on a time line and are processed chronologically.
In this example, random
data stimulates a model and statistics are collected and reported
in various ways.
 EventOriented Modeling with Ptera:
CarWash with DE, Ptera and FSM
(See also GameOfLife, TrafficLight).
The Ptera (Ptolemy Event Relationship Actor) domain is a discreteevent 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 nonnegative 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.
 Process Networks:
OrderedMerge (see also
NondeterministicMerge,
QR).
The process networks (PN) domain follows the semantics given by Kahn and MacQueen in 1977
to get processes with their own threads of control that send messages to one another
and achieve deterministic computation.
The OrderedMerge example implements an example given by Kahn and MacQueen
that calculates numbers whose prime
factors are 2, 3, and 5, only, and produces
them in an ordered sequence.
As of version 5.0, we have extended this model of computation with a
nondeterministic merge actor, illustrated in
NondeterministicMerge.
 Rendezvous:
Barrier
(see also
ResourcePool,
ResourcePool,
WriteRegulator).
The rendezvous domain implements the classic
communicating sequential processes (CSP)
semantics introduced by Tony Hoare, with some extensions. In the CSP domain,
every actor executes in its own thread, and communication is by rendezvous.
The rendezvous domain supports conditional rendezvous (where an actor communicates
nondeterministically with one of several other actors) and multiway rendezvous
(where an actor communicates simultaneously with all of several other actors).
The
Barrier example shows
the use of multiway rendezvous to achieve a classic concurrency design pattern
called barrier synchronization.
 Dynamic Dataflow:
HanoiTower
(see also
Eratosthenes,
IfThenElse,
Loop,
OrderedMerge,
RandomWalk)
In dynamic dataflow (DDF) models, actors are fired in response to available
input data. The schedule is dynamic and data dependent, and actors can
change their production and consumption rates in each firing.
Unlike synchronous dataflow, the DDF model of computation is Turing
complete, and questions of deadlock and boundedness are undecidable.
The HanoiTower
example exploits this to give an algorithmic solution to the wellknown
towers of Hanoi problem.
 Heterochronous Dataflow:
Fibonacci
(see also
Merge).
Heterochronous dataflow (HDF) is an extension of synchronous dataflow
(SDF) that permits dynamically changing production and consumption
patterns without sacrificing static scheduling. In SDF, the production
and consumption patterns of an actor are constant.
In HDF they are allowed to change between iterations of the HDF schedule.
Modal models can be used to change these patterns.
Although HDF can express many datadependent computations that cannot
be represented by SDF, it is not Turing complete. Consequently, deadlock
and boundedness remain decidable.
The Fibonacci
example uses this mechanism in a clever way to extract a Fibonacci sequence
from a counting sequence.
 Synchronous/Reactive Modeling:
TokenRing (see also
TrafficLight and
GuardedCount).
The synchronous/reactive (SR) domain,
which is inspired by the synchronous languages Esterel, Lustre, and Signal,
realizes a concurrency model where actors react instantaneously and simultaneously
at ticks of a logical clock.
The TokenRing
example uses the fixedpoint semantics of SR to arbitrate access
to a shared medium using a tokenring protocol.
Ptolemy II models are built on an underlying framework that provides a rich
set of generic capabilities that are available in all models.
This section illustrates that infrastructure.
 The Type System:
Router.
This model illustrates the very sophisticated type system
of Ptolemy II, where type constraints propagate transparently,
actors are polymorphic, and composite types such as records and
arrays are supported.
This example illustrates composite types, where records are
constructed out of tokens with various types. Here, a record
models a packet in a packetswitched network, where variable
delays may result in outoforder arrival of packets.
 Expression Language:
Transmission.
To simplify creating new components, Ptolemy II contains a functional
expression language. The expression language is integrated with the
type system, allowing static type checking of polymorphic expressions
with few type annotations. The expression language also allows new,
encapsulated functions, called function closures, to be defined and
passed as data. This model illustrates how function closures can be
used to make models much more compact.
 Model Transformation:
SinewaveOptimization
(see also
AdaptiveCarWash,
ConstOptimization,
DiningPhilosophers,
GameOfLife,
MapReduce,
RegressionTest
).
Model transformation is a technique to manipulate models as firstclass citizens. An atomic transformation
rule is defined in a TransformationRule actor. Inputs to a TransformationRule actor are tokens containing
models to be transformed, and outputs are tokens containing the results. Multiple transformations can be
programmed by a model to transform the input models step by step. Other actors that are commonly used in model
transformation include ModelGenerator to generate initial models, and ModelView to show the contents of input
models in new windows. In the SinewaveOptimization
demo, a transformation is repeatedly applied to the initial model (Sinewave)
to statically evaluate arithmetic operations in it, until no more simplification can be done.
 HigherOrder Components:
HocDE
(see also
Case,
MobileFunction,
MultipleRuns,
IterateOverArray,
DFTSubSet,
ApplyFFT
).
Higherorder components are components that operate on components.
The HocDE
example contains a component that is a composite actor that
replicates itself some specified number of times to operate on
multiple channels of input. This capability was created by
Zoltan Kemenczy and Sean Simmons, Research In Motion, Ltd.
 Interactive Signal Plotter:
Sketch
(see also FourierSeries).
This model illustrates the use of plotter to provide input
as well as rendering output from a model. Right click and drag
on the plot to trace out a new signal. The model runs each time you
do this.
 Matlab Integration:
MatlabExpression
(see also
Matlab in Continuous).
This example uses the Matlab interface created by
Zoltan Kemenczy and Sean Simmons, of Research in Motion Ltd.,
to plot a 3D surface. This works only if Matlab is installed locally.

Classes, subclasses, and inner classes:
ClassesIllustrated (see also
Noisy sinewaves
and
Rijndael Encryption
).
Actororiented classes, subclasses, and
inner classes with inheritance are a special feature of Ptolemy II.
They provide modularity mechanisms analogous to those of objectoriented
design, but adapted to actororiented design. This capability permits, for
example, defining a class of models that can have instances and subclasses.
The instances and subclasses inherit all the features of the class, and
track any changes that are made to the class.
 Model Animations:
Bouncer
(see also
AnimateVergil
WirelessSoundDetection
).
Ptolemy II models can, while executing, control their visual rendition
in Vergil, the visual editor for Ptolemy II.
In this example, a model alters the position in the Vergil diagram
of one of its own actors.
 ThreeDimensional Graphics:
Pendulum (see also
Helen,
Gravitation,
SolarSystem,
Sticky Masses
and Bouncing Ball).
NOTE: These models require that you have
installed Java 3D from Sun
(see https://java3d.dev.java.net/).
The Pendulum example shows a continuoustime physical model of pendulum
animated in the graphics (GR) domain, in which graphical components
can be assembled and dynamically manipulated. Note that clicking
and dragging in the graphics window rotates the model.
For further details, see the
GR domain.
 Statically Checked Units System:
StaticUnits
(see also
Units, the
dynamically checked units system).
This model illustrates the use of the statically
checked units system. A unit system
defines a set of interrelated dimensions and measures. For example, in
the time dimension, we might have seconds, minutes, hours, days, weeks,
and fortnights. Ptolemy II includes two experimental units systems,
one that is statically checked and one that is dynamically checked.
 Network Integration:
Networked.
This example illustrates that models may be defined in a networked,
distributed fashion.
This model contains a component that is defined on the Ptolemy project
website. When you open the model, you will be alerted to the fact
that it requires loading a model definition from a remote source.
If you agree to proceed, then you will have a model with a remotely
defined component. The component itself is at
http://ptolemy.eecs.berkeley.edu/xml/models/Waveform.xml.
You can open that definition by clicking on the hyperlink, or by
using the "Open URL" command in the File menu.
 Audio:
KarplusStrong (see also SoundSpectrum).
Ptolemy II includes actors that interface to the audio system on
the executing machine, assuming it has one.
This example shows the KarplusStrong algorithm, which synthesizes
a musical sound that closely resembles a plucked string instrument.
It illustrates the audio capabilities of Ptolemy II.
 Python Integration:
Ptolemnizer
(see also PythonScale).
Python is a popular interpreted programming language that has
been integrated into Ptolemy II using the jython Java implementation of Python.
This example shows that use of Python to alter a string entered by the user
to modify any word that begins with "t" so that it begins with "pt".
This leverages the excellent string processing capabilities in Python.
Python can also be used to prototype
actors by defining their functionality in Python.
 Image and Video Processing:
AdaptiveMedian
(see also
ImageReconstruction,
VQSequenceDisplay,
VideoCapture).
If you install the optional packages JAI (Java advanced imaging) and
JMF (Java media framework), then you can use a library of actors
that operates on images and video signals, including video captured
from a video camera.
 FixedPoint Arithmetic:
FixFIR
(see also
FixPoint)
Ptolemy II data types include a fixedpoint data type, where
a model can explicitly control the binary representation of numbers
and the mechanisms used to handle overflow and rounding.
Ptolemy II includes several actor libraries that provide sophisticated
functions. A few of those are illustrated by the models here.
 Array:
Actors that operate on matrices and arrays.
 ColtRandom:
Random number generators (based on Colt).
 Signature:
Security actors (encryption and digital signatures).
 TrellisDecoder:
Communication library.
Ptolemy II has a number of less welldeveloped experimental
capabilities that may continue to evolve over time.
These are illustrated in the following examples.
 Push/Pull Component Interaction.
The CI (component interaction) domain models communication between
components that uses a combination of push and pull. This model
illustrates the use of these styles of communication to route packets
through queues using some policy that depends on the queue sizes.
 Cal: an interpreted actor definition language.
Function Closures,
Function Definition,
Primes,
SDFDDI
 DiscreteTime Models.
This example shows a simple pulseamplitude modulation, physical
layer communication system. It illustrates the discretetime (DT)
domain, live parameter editing and
the scopestyle plotter (which shows an eye diagram).
Note that discretetime models can also be represented using the
SDF domain, which is not explicit about the passage of time.
 Code Generation
This release includes a limited prototype of our code generation facility.
This example leads to more information about this capability.
 Timed Multitasking.
This example illustrates the timed multitasking (TM) domain,
which is inspired by the Giotto language, and has features of
prioritydriven realtime operating systems. In this example,
two control systems share a computational resource. Depending
on the scheduling strategy chosen (preemptive or nonpreemptive)
and the priorities, the two control systems may be both stable,
or one may be stable, or the other may be stable.
 Correctness Checking using Formal Methods.
This is an
ongoing project which tries to equip Ptolemy II with abilities to test the correctness
of a system using formal verification. Currently we develop a code generator to
convert Ptolemy II models into files accepted by model checker NuSMV.