PTOLEMY II - CiteSeerX

Introduction
SR models are excellent for applications with concurrent and complex control logic. Because of
the tight synchronization, safety-critical real-time applications are a good match. However, also
because of the tight synchronization, some applications are overspecified in the SR model, limiting the
implementation alternatives. Moreover, in most realizations, modularity is compromised by the need
to seek a global fixed point at each clock tick. The SR domain implementation in Ptolemy II is similar
to the SR implementation in Ptolemy Classic by Stephen Edwards[33].
1.3.14 Timed Multitasking - TM
The timed multitasking (TM) domain, created by Jie Liu [92], supports the design of concurrent
real-time software. It assumes an underlying priority-driven preemptive scheduler, such as that typically
found in a real-time operating systems (RTOS). But the behavior of models is more deterministic
than that obtained by more ad hoc uses of an RTOS.
In TM, each actor executes (conceptually) as a concurrent task. It is a timed domain, meaning that
there is a notion of “model time” that advances monotonically and uniformly. Each actor has a specified
execution time T, and it delays the production of the outputs until it has had access to the CPU for
that specified amount of time (in model time, which may or may not match real time). Actors execute
when they receive new inputs, so the execution is event driven. Conceptually, the actor begins execution
at some time t, and its output is produced at time t + T + P, where T is the declared execution time,
and P is the amount of time where the actor is suspended due to being preempted by a higher priority
actor. At any given model time t, the task with the highest priority that has received inputs but not yet
produced its outputs has the CPU. All other tasks are suspended.
TM offers a way to design real-time systems that is more deterministic than ad hoc uses of an
RTOS. In particular, typically, a task produces outputs at a time that depends on the actual execution
time of the task, rather than on some declared parameter. This means that consumers of that data may
or may not see updates to the data, depending on when their execution occurs relative to the actual execution
time. Thus, the computational results that are produced depend on the actual execution time.
TM avoids this by declaring the time that elapses before production of the outputs. By maintaining
model time correctly, TM ensures that the data computation is deterministic, irrespective of actual execution
time.
1.3.15 Wireless
The wireless domain, described in [10], is an extension of the discrete-event domain that supports
modeling and simulation of wireless and sensor network systems. An example model is shown in figure
1.11. Notice that the syntax is very different from that in figure 1.2.
This example models a SoundSource (whose icon is large, transparent concentric circles) moving
through a field of sensors (SoundSensor actors, which have translucent blue circle icons) that detect
the sound and communicate with a Triangulator actor (whose icon consists of overlapping ellipses).
The Triangulator is a composite, shown at the bottom of the figure, that uses the DE domain to perform
sensor fusion to triangulate the location of the sound source. It generates a plot with estimated locations.
When this model is executed, the sensors’ icons turn red when they detect a sound. Upon detecting
a sound, they transmit the time at which they detect the sound and their current location. If a
location can be found, then the model plots that location.
The wireless domain generally uses channel models to mediate communication. A library of channel
models is provided, but it is expected that users will create their own channel models. The domain
can model such effects as propagation delay, packet losses, directional gain (such as antenna gain),
22 Ptolemy II