Part 3: RSDL Language Definition
3.10 Transitions
3.10.1 Free Action
Abstract grammar
Free-action :: Connector-name
Transition
Connector-name = Name
Concrete grammar
<label> ::= <connector name> :
<free action> ::= connection <transition> [ endconnection [ <connector name> ] <end> ]
"Body" refers to a state machine graph. A body encompasses <agent body>.
All the <connector name>s defined in a body must be distinct.
A label represents the entry point of a transfer of control from the corresponding joins with the same <connector name>s in the same body.
Transfer of control is only allowed to labels within the same body.
If the <transition string> of the <transition> in <free action> is non-empty, the first <action statement> must have a <label> otherwise the <terminator statement> must have a <label>.
If present, the <connector name> ending the <free action> must be the same as the <connector name> in this
<label>.
Semantics
A Free-action defines the target of a Join-node. In the abstract grammar, only free actions have labels; labels inside of a transition are transformed into separate free actions.
Model
If a <label> is not the first label of a <transition string>, the <transition string> is split into two parts. All <action statements> preceding the <label> are preserved in the original transition, which is terminated with a <join> to the <label>. All action statements following <label> are copied to a new <free action>, which starts with the
<label>. A similar transformation is applied if a labelled <terminator statement> is preceded by a <transition string>.
3.10.2 Transition
Abstract grammar
Transition :: Graph-node*
( Terminator | Decision-node )
Graph-node = Task-node
| Output-node
| Create-request-node
| Set-node
| Reset-node
Terminator = Nextstate-node
| Stop-node
| Join-node Concrete grammar
<transition> ::= <transition string> [<terminator statement>] | <terminator statement>
<transition string> ::= {<action statement>}+
<action statement> ::= [<label>] <action 1> <end>
<action 1> ::= <task> | <output> | <create request> | <decision> | <set> | <reset> | <export> | <import>
<terminator statement> ::= [<label>] <terminator 2> <end>
<terminator 2> ::= <nextstate> | <join> | <stop>
If the <terminator> of a <transition> is omitted, then the last action in the <transition> must contain a terminating <decision>, except when a <transition> is contained in a <decision>.
Semantics
A transition performs a sequence of actions. During a transition, the data of an agent may be manipulated and signals may be output. The transition will end with the state machine of the agent entering a state, with a stop or with the transfer of control to another transition.
A transition in one local block of a block can be interpreted at the same time as a transition in another local block of the same block or of another block.
An undefined amount of time may pass while an action is interpreted. It is valid for the time taken to vary each time the action is interpreted. It is also valid for the time taken to be the same at each interpretation or for it to be zero (that is the result of now is not changed).
Model
A transition action may be transformed to a list of actions (possibly containing implicit states) according to the transformation rules for <import>.
3.10.3 Terminators
Abstract grammar
Nextstate-node :: State-name
Join-node :: Connector-name
Stop-node :: ( )
The State-name specified in a nextstate must be the name of a state within the same State-transition-graph.
There must be exactly one Connector-name corresponding to a Join-node within the same body.
Concrete grammar
<nextstate> ::= nextstate <nextstate body>
<nextstate body>::= <state name>
<join> ::= join <connector name>
<stop> ::= stop Semantics
A nextstate represents a terminator of a transition. It specifies the state of the agent when terminating the transition.
When a Join-node is interpreted, interpretation continues with the Free-action named with Connector-name.
The stop causes the agent interpreting it to perform a stop.
This means that the retained signals in the input port are discarded and the agent itself will cease to exist.
3.10.4 Actions
Abstract grammar
Task-node = Assignment
Create-request-node :: Agent-identifier
Output-node :: Signal-identifier
[Expression]*
[Signal-destination]
Signal-destination = Expression
In an Output-node, the length of the list of optional Expressions must be the same as the number of Sort-names in the Signal-definition denoted by the Signal-identifier. Each Expression must be sort compatible to the corresponding (by position) Sort-name in the Signal-definition.
Concrete grammar
<task> ::= task <textual task body>
<textual task body> ::= <assignment>
<create request> ::= create <create body>
<create body> ::= <agent identifier>
<output> ::= output <output body>
<output body> ::= <signal identifier> [<actual parameters>]
{, <signal identifier> [<actual parameters>] }*
<communication constraints>
<communication constraints> ::=
[ to <destination> ]
<destination> ::= <pid expression>
<actual parameters> ::= ( <actual parameter list> )
<actual parameter list> ::= [<expression>] { , [<expression>] }*
Commas after the last <expression> in <actual parameter list> may be omitted.
The <pid expression> in <destination> represents the Signal-destination.
Semantics
The interpretation of a Task-node is the interpretation of the Assignment.
The create action causes the creation of an agent instance either inside the agent that performs the create or in the agent that contains the agent that performs the create. The parent of the created agents (see Section 3.7.3 Model) has the same pid as returned by self of the creating agent. self of the created agents (see Section 3.7.3 Model) and offspring of the creating agent (see Section 3.7.3 Model) both have the same unique, new pid.
When an agent instance is created, it is given an empty input port, and variables are created. If the created agent has contained agent sets, then the initial instances of these sets are created in the same way. Otherwise the agent starts by interpreting the start node in the agent graph before transitions caused by signals are interpreted.
The created agent is then interpreted asynchronously and concurrently with other agents.
If an attempt is made to create more agent instances than specified by the maximum number of instances in the agent definition, then no new instance is created, the offspring of the creating agent (see Section 3.7.3 Model) has the result null and interpretation continues.
If no Signal-destination is specified in an Output-node, any agent for which there exists a communication path may receive the signal.
If an <expression> in <actual parameters> is omitted, no data item is conveyed with the corresponding place of the signal instance, that is, the corresponding place is "undefined".
The pid of the originating agent is also conveyed by the signal instance.
The signal instance is then delivered to a communication path able to convey it.
If destination is present, the signal instance is delivered to the agent instance denoted by Signal-destination. If this instance does not exist or is not reachable from the originating agent, the signal instance is discarded.
If no Signal-destination is specified, the receiver is selected in two steps. First, the signal is sent to an agent instance set, which can be reached by the communication paths able to convey the signal instance. This agent instance set is arbitrarily chosen. Second, when the signal instance arrives at the end of the communication path, it is delivered to an instance of the agent instance set. The instance is arbitrarily selected. If no instance can be selected, the signal instance is discarded.
Model
If several pairs of <signal identifier> and <actual parameters> are specified in an <output body>, this is derived syntax for specifying a sequence of <output>s in the same order as specified in the original <output body>, each containing a single pair of <signal identifier> and <actual parameters>. The to <destination> clause is repeated in each of the <output>s.
3.10.5 Decision
Abstract grammar
Decision-node :: Decision-question
Decision-answer-set
[Else-answer]
Decision-question = Expression
Decision-answer :: Constant-expression-set Transition
Else-answer :: Transition
The Constant-expressions of the Decision-answers must be mutually exclusive. The Constant-expressions of the Decision-answers must be sort compatible to the sort of the Decision-question.
Concrete grammar
<decision> ::= decision <question> <end> <decision body> enddecision
<decision body> ::= <answer part>+ [<else part>]
<answer part> ::= ( <answer> ) <colon> [<transition>]
<answer> ::= <constant expression> { , <constant expression> } *
<else part> ::= else <colon> [<transition>]
<question> ::= <expression>
An <answer part> or <else part> in a decision is a terminating <answer part> or <else part> respectively if it contains a <transition> where a <terminator statement> is specified, or contains a <transition string> whose last
<action statement> contains a terminating decision. A <decision> is a terminating decision, if each <answer part> and <else part> in its <decision body> is a terminating <answer part> or <else part> respectively.
Semantics
A decision transfers the interpretation to the outgoing path whose constant expression equals the result given by the interpretation of the question. A set of possible answers to the question is defined, each of them specifying the set of actions to be interpreted for that path choice.
One of the answers may be the complement of the others. This is achieved by specifying the Else-answer, which indicates the set of activities to be performed when the result of the expression on which the question is posed, is not covered by the results specified in the other answers.
Whenever the Else-answer is not specified, and the result from the evaluation of the question expression does not match one of the answers, then the further system behaviour is undefined.
Model
If a <decision> is not terminating then it is derived syntax for a <decision> wherein all not terminating <answer part>s and the <else part> if not terminating have inserted at the end of their <transition> a <join> to the first
<action statement> following the decision or if the decision is the last <action statement> in a <transition string>
to the following <terminator statement>.
3.10.6 Timer
Abstract grammar
Timer-definition :: Timer-name
Timer-name = Name
Set-node :: Time-expression
Timer-identifier
Reset-node :: Timer-identifier
Timer-identifier = Identifier
Time-expression = Expression
Concrete grammar
<timer definition> ::= timer <timer definition item> { , <timer definition item>}* <end>
<timer definition item> ::= <timer name>
<reset> ::= reset ( <reset clause> { , <reset clause> }* )
<reset clause> ::= <timer identifier>
<set> ::= set <set clause> { , <set clause> }*
<set clause> ::= ( <Time expression> , <timer identifier> ) A <reset clause> represents a Reset-node; a <set clause> represents a Set-node.
Semantics
A timer instance is an object, that can be active or inactive.
When an inactive timer is set, a Time value is associated with the timer. Provided there is no reset or other setting of this timer before the system time reaches this Time value, a signal with the same name as the timer is put in the input port of the agent. The same action is taken if the timer is set to a Time value less than or equal to now. After consumption of a timer signal the sender expression yields the same result as the self expression. A timer is active from the moment of setting up to the moment of consumption of the timer signal.
When an inactive timer is reset, it remains inactive.
When an active timer is reset, the association with the Time value is lost, if there is a corresponding retained timer signal in the input port then it is removed, and the timer becomes inactive.
When an active timer is set, this is equivalent to resetting the timer, immediately followed by setting the timer.
Between this reset and set the timer remains active.
Before the first setting of a timer instance it is inactive.
Model
A <reset> or a <set> may contain several <reset clause>s or <set clause>s respectively. This is derived syntax for specifying a sequence of <reset>s or <set>s, one for each <reset clause> or <set clause> such that the original order in which they were specified in <reset> or <set> is retained.