Part 3: RSDL Language Definition
3.1 RSDL Short Description
In order to provide a quick overview of RSDL for SDL experts and to give a first impression of RSDL, this section summarises the features of RSDL. Moreover, an example shows how RSDL is used.
• The language RSDL describes a system using communicating state machines, called blocks (agents).
• The blocks communicate with each other using signals that are transferred over channels.
• Blocks may be defined using block types.
• For block types, connection points for the channels must be given,. They are called gates.
• Blocks may be created dynamically.
• The behaviour of a block (type) is given with a finite state machine.
• A state change is triggered by the reception of a signal (input) or by a condition (continuous signal).
• Timing conditions can be expressed using timers.
• A block may have local variables.
• A block may access local variables of another block using the concept of remote variable.
• RSDL provides no means to define data types. Predefined data types can be used, namely Boolean, Integer, Time, Duration and PId (block identities).
3.1.1 Daemon Game Example - Informal Description
The daemon game is often used as introductory example for SDL. We will use it here to show the expressiveness of RSDL. The following informal description of the game is taken from [14].
The Daemon Game is a simple game having several players. The game is the system that is to be defined in RSDL. The players belong to the environment of the system.
In the system there is a daemon that generates Bump signals randomly. A player has to guess whether the number of generated Bump signals is odd or even. The guess is made by sending a Probe signal to the system. The system replies by sending the signal Win if the number of generated Bump signals is odd, otherwise by the signal Lose.
10 ITU is an abbreviation for International Telecommunication Union, which is the international telecommunication standardisation organisation.
The system keeps track of the score of each player. The score is initially 0. It is increased by 1 for each successful guess (signal Win is sent), and reduced by 1 for each unsuccessful guess (signal Lose is sent).
A player can ask for the current value of the score by the signal Result, which is answered by the system with the signal Score.
Before a player can start playing, the player must log in. This is accomplished by the signal Newgame. A player logs out by the signal Endgame. The system allocates a player a unique identifier on logging in, and de-allocates it on logging out. The system cannot tell whether different identifiers are being used by the same player.
3.1.2 Daemon Game Example - Formal RSDL Description
In the RSDL formal description of the daemon game example the signals mentioned in the informal description are declared. The game is decomposed into two units: a monitor process and a game controller process. For each Newgame request, a game controller instance is created by the monitor. After reception of an Endgame, the corresponding game controller ceases to exists. The global structure is depicted below using the SDL graphical syntax. This figure is informal in the context of RSDL.
[Bump]
[Gameid, Win, Lose, Score]
[Probe, Result, Endgame]
G(0,):Game Game
SIGNAL Newgame, Endgame, Gameid(PId);
SIGNAL Startgame(PId), Bump;
SIGNAL Probe, Result, Win, Lose, Score(Integer) BLOCK Daemongame
G_Daemon Monitor
M(1,1):Monitor
G_Player
C1 C2
C3 C4
[Startgame]
[Newgame]
Figure 9: Overview of the RSDL Daemon Game Formalisation
The daemon game is connected to the environment via two gates, one for the communication with the players and one for the input from the daemon. All Newgame signals are routed to the Monitor using the channel C1. The channel C2 is used to transport all the user signals to and from the game controller instances. The internal signal Startgame is sent from the monitor to the game controllers using the channel C3. Finally, the daemon Bump signals are transported on channel C4.
The daemon game contains exactly one monitor instance and as many game controller instances as there are active games. Initially, there are no active games. This structure is represented with the following RSDL block.
BLOCK Daemongame;
SIGNAL Newgame, Endgame, Gameid(PId);
SIGNAL Startgame(PId), Bump;
SIGNAL Probe, Result, Win, Lose, Score(Integer);
GATE G_Player IN WITH Newgame, Endgame, Probe, Result;
OUT WITH Gameid, Win, Lose, Score;
GATE G_Daemon IN WITH Bump;
BLOCK TYPE Game REFERENCED;
BLOCK TYPE Monitor REFERENCED;
BLOCK M(1,1): Monitor;
BLOCK G(0,): Game;
CHANNEL C1
FROM ENV VIA G_Player TO M VIA G_Newgame WITH Newgame;
ENDCHANNEL;
CHANNEL C2
FROM ENV VIA G_Player TO G VIA G_Playing WITH Probe, Result, Endgame;
FROM G VIA G_Playing TO ENV VIA G_Player WITH Win, Lose, Score, Gameid;
ENDCHANNEL;
CHANNEL C3
FROM M VIA G_Game TO G VIA G_Monitor WITH Startgame;
ENDCHANNEL;
CHANNEL C4
FROM ENV VIA G_Daemon TO G VIA G_Bump WITH Bump;
ENDCHANNEL;
ENDBLOCK Daemongame;
Now the block type monitor is specified in more detail. It has two gates, one for receiving Newgame indications and one for sending Startgame signals. Whenever the Monitor receives a Newgame signal, it creates a new game controller and sends a signal Startgame with the identity of the Newgame sender to the newly created instance. This behaviour has the following RSDL representation.
BLOCK TYPE Monitor;
GATE G_Newgame IN WITH Newgame;
GATE G_Game OUT WITH Startgame;
START;
NEXTSTATE Idle;
STATE Idle;
INPUT Newgame;
CREATE G;
OUTPUT StartGame(SENDER) TO OFFSPRING;
NEXTSTATE Idle;
ENDBLOCK TYPE Monitor;
The game controller has three interfaces (gates), one for receiving Startgame signals from the monitor, one for receiving Bump signals from the daemon and one for the communication with the player. Two local variables are declared, namely score to hold the current score and MyPlayer to hold the identity of the player.
BLOCK TYPE Game;
GATE G_Monitor IN WITH Startgame;
GATE G_Playing OUT WITH Gameid, Win, Lose, Score;
IN WITH Probe, Result, Endgame;
GATE G_Bump IN WITH Bump;
DCL score Integer := 0;
DCL MyPlayer PId;
After creation the game controller waits in an initial state for the Startgame signal. This signal contains the PId of the player. An acknowledge signal Gameid with the own PId is sent back to the player. Afterwards, the game starts in the losing state.
START;
NEXTSTATE Initstate;
STATE Initstate;
INPUT Startgame(MyPlayer);
OUTPUT Gameid(SELF) TO MyPlayer;
NEXTSTATE LoseState;
If the signal Probe is received in the losing state, the score is reduced by 1 and the player is informed with the signal Lose. If the player asks for the current score, a Score signal is sent. A similar action is taken in the winning state.
STATE LoseState;
INPUT Probe;
TASK score:= score-1;
OUTPUT Lose TO MyPlayer;
NEXTSTATE LoseState;
INPUT Result;
OUTPUT Score(score) TO MyPlayer;
NEXTSTATE WinState;
STATE WinState;
INPUT Probe;
TASK score:= score+1;
OUTPUT Win TO MyPlayer;
NEXTSTATE WinState;
INPUT Result;
OUTPUT Score(score) TO MyPlayer;
NEXTSTATE LoseState;
Switching between winning and losing is triggered by the Bump signal.
STATE LoseState;
INPUT Bump;
NEXTSTATE WinState;
STATE WinState;
INPUT Bump;
NEXTSTATE LoseState;
The Endgame signal causes the game to be finished.
STATE WinState, LoseState;
INPUT Endgame;
STOP;
ENDBLOCK TYPE Game;
This concludes the daemon game specification in RSDL. The exact meaning of the RSDL constructs is given in the language description below.