Part 4: RSDL Formal Definition
4.5 Special Abstract Machine Definition
4.5.1 Signal Flow Model
This section introduces the signal flow model as part of the SAM. The main focus here is on a uniform treatment of signal flow aspects, in particular, on defining how active objects communicate through signals via gates. Also timers, which are modelled as special kinds of signals, are covered here.
4.5.1.1 Signals
PLAINSIGNAL represents the set of signal types as declared by an RSDL specification.
PLAINSIGNAL =def Signal-definition SIGNAL =def DefinitionAS1
In an RSDL specification, also timers behave like signals, so we introduce a common domain SIGNAL for all of them. Dynamically created signal instances (signals for short) are introduced as elements of a dynamic domain SIGNALINST. Each element of SIGNALINST is uniquely related to an element of SIGNAL.
shared domain PLAINSIGNALINST
SIGNALINST =def PLAINSIGNALINST ∪ TIMERINST
For each signal the sender of the signal and the receiver constraint are stored in the functions sigSender and toArg, respectively. For each of the functions introduced in the following, we distinguish the general variant on
SIGNALINSTs from the plain one on PLAINSIGNALINST. The complete definition of the derived version on SIGNALINSTs can be found in Section 4.5.1.5.
signalType: SIGNALINST → SIGNAL sigSender: SIGNALINST → AGENT toArg: SIGNALINST → TOARG TOARG =def RSDLPID
shared plainSignalType: PLAINSIGNALINST → SIGNAL shared plainSigSender: PLAINSIGNALINST → AGENT shared plainToArg: PLAINSIGNALINST → TOARG
With each signal a (possibly empty) list of signal values is associated. Since the type information and concrete value for signal values is immaterial to the dynamic aspects considered here, values are abstractly represented in a uniform way as elements of the domain VALUE as provided by the data interface in Section 4.4.4.
values: SIGNALINST → VALUE*
shared plainValues: PLAINSIGNALINST → VALUE*
4.5.1.2 Gates
Exchange of signals between RSDL block agents and with the environment is modelled by means of gates from a controlled domain GATE.
controlled domain GATE
A gate forms an interface for serial and unidirectional communication between two or more agents.
Accordingly, gates are either classified as input gates or output gates.
DIRECTION =def {inDir, outDir}
controlled direction: GATE → DIRECTION Discrete Delay Model
Signals need not reach their destination instantaneously but may be subject to delays. That means, it must be possible to send signals to arrive in the future. Although those signals are not available at their destination before their arrival time has come, they are to be associated with their destination gates. A gate must be capable of holding signals that are in transit. Hence, to each gate a signal queue is assigned, as detailed below.
To model signal arrivals at specified destination gates, each signal instance s which is currently in transit has an individual arrival time s.arrival, s.arrival > now, determining the time at which s eventually reaches a certain gate.
shared arrival: SIGNALINST → REAL
One can now represent the relation between signals and gates in a given SAM state by means of a dynamic function schedule defined on gates,
shared schedule: GATE → SIGNALINST*
where schedule specifies for every gate g in GATE the corresponding signal arrivals at g.
An integrity constraint on g.schedule is that signals in g.schedule are linearly ordered by their arrival times. That is, if g.schedule contains signals s, s', and s.arrival < s'.arrival, then s < s' in the order as imposed by g.schedule.
This condition is assured by the insert function below.
Waiting Signals
A signal instance s in g.schedule does not arrive “physically” at gate g before now ≥ s.arrival. Intuitively, that means that s remains “invisible” at g as long as it is in transit. Thus, in every given SAM state, the visible part of g.schedule forms a possibly empty signal queue,
queue: GATE → SIGNALINST*
where g.queue represents those signal instances s in g.schedule which have already arrived at g but are still waiting to be removed from g.schedule. The visible part of g is denoted as g.queue and formally defined as follows. See also Figure 10 below for an overview of the functions on schedules.
queue(g: GATE): SIGNALINST* =def < s in g.schedule: (now ≥ s.arrival) >
t4 t3 t2 t1 ti∈ TIME
signals in transit g.queue now
g
j > i implies tj > ti g ∈ GATE
g.schedule
Figure 10: Signal instances at a gate
Operations on Schedules
To ensure that the order on signals is preserved when new signals are added to the schedule of a gate, there is a special insertion function on schedules. The result of inserting some signal s with the intended arrival time t into a finite signal list seq as represented by the schedule of a given gate is defined as follows.
insert(s: SIGNALINST, t: RSDLTIME, seq: SIGNALINST*): SIGNALINST* =def
if seq = empty ∨ t < seq.head.arrival then < s > ∩ seq else < seq.head > ∩ insert(s, t, seq.tail)
Analogously, a function delete is used to remove an item from a given schedule seq.
delete(s: SIGNALINST, seq: SIGNALINST*): SIGNALINST* =def
if seq = empty then empty elseif seq.head = s then seq.tail else < seq.head > ∩ delete(s, seq.tail)
As shorthand notations for operations used to update the schedule of a gate g (by assigning a new signal list to g.schedule) the following two rule macros are defined here. These macros will be used in subsequent rules.
INSERT(s: SIGNALINST, t: REAL, g: GATE) ≡ g.schedule := insert(s,t,g.schedule) s.arrival := t
DELETE(s: SIGNALINST, g: GATE) ≡ g.schedule := delete(s,g.schedule) s.arrival := undefined
4.5.1.3 Channels
Channel paths, as declared in a given RSDL specification, are abstractly represented as elements of a domain CHANNEL. An RSDL channel consists of one or two unidirectional channel paths, each of which is represented as an object of a dynamic domain LINK. Channel paths are associated to LINKs as stated by means of a corresponding function channel.
CHANNEL =def Channel-path LINK =def AGENT
controlled channel: LINK → CHANNEL
Intuitively, elements of LINK are point-to-point connection primitives for the transport of signals. Each l of LINK is able to convey the signal types specified by l.with, from an originating gate l.from to a destination gate l.to.
controlled from: LINK → GATE controlled to: LINK → GATE
with: LINK → SIGNAL-set
with(l: LINK): SIGNAL-set =def { s.refersto1 | s ∈ l.channel.s-Signal-identifier-set } Signal Delays
RSDL channels are reliable and order-preserving communication links. A channel may however delay the transport of a signal for an indeterminate and non-constant time interval. Although the exact delaying behaviour is not further specified, the fact that channels are reliable implies that all delays must be finite.
Signal delays are modelled through a monitored function delayedTime stating the dependency on external conditions and events. In a given SAM state, delayedTime associates finite time intervals from the domain REAL to the elements of LINK, where the duration of a particular signal delay appears to be chosen non-deterministically.
monitored delayedTime: LINK → REAL
There are three integrity constraints on the function delayedTime:
1. For every link agent l, l.delayedTime ≥ now.
2. For every link to the input gate of an agent l, l.delayedTime = now (i.e. they are non-delaying).
3. For every link agent l the values of l.delayedTime increase monotonically (with respect to now).
Notice that the third integrity constraint is needed in order to ensure that channel paths are order-preserving, i.e.
signals which are transported via the same channel path (and therefore are inserted into the same destination schedule) cannot overtake.
Channel Behaviour
A link agent l performs a single operation: signals received at gate l.from are forwarded to gate l.to. That means, l continuously watches l.from waiting for the next deliverable signal in l.from.queue. Whenever l is applicable to a waiting signal s (as identified by the head of l.from.queue), it attempts to remove s from l.from.queue in order to insert s into l.to.schedule. Note that this attempt need not necessarily be successful as, in general, there may be several link agents competing for the same signal s.
To avoid that link agents interfere with each other, i.e. two or more link agents attempt to access the same signal s simultaneously, an auxiliary dynamic function access is introduced (as a kind of control flag), effectively enforcing a synchronisation of link agents as expressed in the rule below.11
controlled access: GATE→ AGENT
A link agent l is a legal choice for the transportation of s only, if the following two conditions hold: (1) s.signalType ∈ l.with and (2) there exists an applicable path connecting l.to to some final destination matching with the address information of s. Abstractly, this second condition can be expressed using a predicate Reachable,
Reachable: GATE × TOARG → BOOLEAN
where TOARG refers to the address information as specified by s.toArg. The function Reachable is specified in full within Section 4.5.1.4 below.
LINK-PROGRAM:
if Self.from.queue ≠ empty then let s = Self.from.queue.head in
if Applicable(s) then DELETE(s,Self.from)
INSERT(s, Self.delayedTime, Self.to) Self.from.access:= Self
where
Applicable(s: SIGNALINST): BOOLEAN =def
s.signalType ∈ Self.with ∧ Reachable(Self.to, s.toArg) endwhere
11 Without an explicit synchronisation mechanism, multiple access to the same signal s would in fact result in illegal behaviour causing a duplication of the original signal s. (Recall that such behaviour is not excluded by the semantics of partially ordered runs because of the fact that there is actually no conflict.)
4.5.1.4 Reachability
For the definition of the reachability it is necessary that every gate knows which agent it belongs to. This is achieved using a controlled function as defined below.
controlled myAgent: GATE → AGENT
In order to define the reachability it suffices to state how the recipients of a signal can be accessed. This is done with the following derived function that effectively enumerates all paths that go to an agent.
reachableAgents(g: GATE): AGENT-set =def
if g.myAgent.inport = g then { g.myAgent }
else
U
{ a.to.reachableAgents | a ∈ AGENT: a.from = g }The definition above states that from the input port of an agent only this agent itself is reachable, and for every other gate the reachable agents are those that are reachable from any outgoing channel. Now it is easy to state when a specific agent is reachable via a specific gate.
Reachable(gate: GATE, ag: AGENT): BOOLEAN =def
( ag = undefined ∧ reachableAgents(gate) ≠ ∅ ) ∨ ag ∈ reachableAgents(gate)
4.5.1.5 Timers
A particular concise way of modelling timers is by identifying timer objects with corresponding timer signals.
More precisely, each active timer is represented by a corresponding timer signal in the schedule associated with the input port of the related block instance.
TIMER =def Timer-definition TIMERINST =def RSDLPID × TIMER
The information associated with timers is accessed using the functions defined on SIGNAL with their usual meaning, except for t.toArg, which has the value undefined.
signalType(s: SIGNALINST): SIGNAL =def
if s ∈ PLAINSIGNALINST then s.plainSignalType else s.s-TIMER endif values(s: SIGNALINST): VALUE* =def
if s ∈ PLAINSIGNALINST then s.plainValues else empty endif sigSender(s: SIGNALINST): AGENT =def
if s ∈ PLAINSIGNALINST then s.plainSigSender else s.s-RSDLPID endif toArg(s: SIGNALINST): TOARG =def
if s ∈ PLAINSIGNALINST then s.plainToArg else undefined endif Active Timers
To indicate whether a timer instance t is active or not, there is a corresponding derived predicate Active. The value of Active(t) is defined as follows.
Active(t: TIMER): BOOLEAN =def t ∈ Self.inport.schedule.toSet Timer Operations
The macros below model the operations set and reset on timers as executed by a corresponding RSDL agent. An RSDL set will be transformed into a reset operation immediately followed by a set operation.
SETTIMER(timer: TIMER, time: RSDLTIME) ≡
INSERT(mk-TIMERINST(Self, timer), time, Self.inport) RESETTIMER(timer: TIMER) ≡
let t = mk-TIMERINST(Self, timer) in if Active(t) then
DELETE(t, Self.inport)