Specification of Reactive Hardware/Software Systems - Electronic ...

170 Modelling of Concurrent Reactive Behaviour
sensor A temperature process B
Figure 6.6: A Continuous Flow
Mapping on Synchronous Message Passing
Message based communication does not model time-continuous flows straightforwardly.
A message is a typically time discrete way of communication. When we
observe a time discrete flow (on a channel) we see no activity on the flow in the time
intervals between the messages. The moments of activity are the instants that a rendezvous
(message passing) occurs. However, as stated before we decided to try to
express the various sorts of communication with the one way synchronous message
passing primitive. There is a specific behaviour at the side of the producer that we need
to model the continuous flow with message passing. A normal rendezvous expresses
the synchronisation of two independent partners that must both be willing to communicate.
In the continuous flow case the producer of the flow is specified to be ready
continuously to do a rendezvous. An initiative of a consumer (e.g. process B in Figure
6.6) to do a rendezvous must be granted instantly by the producer (e.g. sensor A in
Figure 6.6), during the time interval that the flow is produced.
We specified a continuous flow with the restriction of a time interval where the flow is
actively produced. Consequently this offers the possibility to model that a continuous
source is not available outside the interval. It must be possible to switch off a continuous
source (sending process). In general, we do not want the process, receiving the
continuous flow, to get blocked because the rendezvous with a disabled continuous source
cannot be finished. An elegant solution for this problem is to let the sender produce unk
messages. (Unk is derived from the word unknown.) This solution makes that a receiver
can always finish the rendezvous. The reception of an unk message enables detection
that the source is not available. According behaviour can be specified.
Examples of send statements that can be used to model continuous communication are:
1. channel!temperature(real)
2. channel!temperature(runk)
The most simple POOSL description that produces messages continuously is a loop with
statement 1 inside. Alternatively statement 2 can be used to send unknown values. In
practice however a process must be able to handle operations other than the continuously
sending of a message. The following construct enables to perform other operations while
continuous communication is modelled as well: