Difference between revisions of "Detailed SDL tutorial"

From TASTE
Jump to: navigation, search
(SDL in the context of TASTE)
 
(16 intermediate revisions by the same user not shown)
Line 1: Line 1:
= OpenGEODE - SDL Tutorial =
+
= OpenGEODE - SDL tutorial =
  
 +
Author: Maxime Perrotin
  
== Introduction ==
+
contact: maxime (dot) perrotin (at) esa.int
 +
 
 +
= Introduction =
  
 
SDL is a rich language and the complete specifications are available on the ITU-T website : https://www.itu.int/rec/T-REC-Z.100
 
SDL is a rich language and the complete specifications are available on the ITU-T website : https://www.itu.int/rec/T-REC-Z.100
Line 16: Line 19:
 
Check https://www.sdl-forum.org for more information.
 
Check https://www.sdl-forum.org for more information.
  
In this page we list the features of SDL supported by OpenGEODE and explain how to use them.
+
OpenGEODE supports a subset of the last version of the standard. In this page we list the features of this subset and explain how to use them.
 +
 
 +
 
 +
= SDL concepts overview =
 +
 
 +
These are the main symbols used in a SDL state machine:
 +
 
 +
:[[File:ClipCapIt-210118-092814.PNG]]
 +
 
 +
State machines in SDL look like flow diagrams and are read vertically. This is a typical SDL transition diagram:
 +
 
 +
:[[File:ClipCapIt-210118-094530.PNG]]
 +
 
 +
 
 +
We will now go in the details of each symbol.
 +
 
 +
 
 +
== Start symbol ==
 +
 
 +
There are three places in a SDL model where a START symbol can be used:
 +
 
 +
1. At the state machine root diagram: It is mandatory here. A state machine has exactly one start transition.
 +
 
 +
:[[File:ClipCapIt-210118-094606.PNG]]
 +
 
 +
 
 +
The start transition is executed at process creation
 +
 
 +
The start transition
 +
 
 +
- Sets the initial state
 +
- May execute initial actions
 +
(initialization of variables)
 +
 
 +
 
 +
2. Inside procedures. The start symbol has a slightly different shape, and is triggered when the procedure is called:
 +
 
 +
:[[File:ClipCapIt-210118-095047.PNG]]
 +
 
 +
 
 +
3. Inside nested states
 +
 
 +
There can be more than one Start transition in a nested state. In that case they must be given a name.
 +
 
 +
:[[File:ClipCapIt-210118-095310.PNG]]
 +
 
 +
 
 +
The selection of the nested state start transition is done one level above, when entering the nested state, using the '''via''' syntax:
 +
 
 +
:[[File:ClipCapIt-210118-095516.PNG]]
 +
 
 +
 
 +
== State / Nextstate ==
 +
 
 +
:[[File:ClipCapIt-210118-095659.PNG]]
 +
 
 +
* Each state has a name
 +
* In a given state, the process is expecting to receive messages
 +
* A state can be composite
 +
 
 +
Note the following shortcut that allow to save diagram space:
 +
 
 +
:[[File:ClipCapIt-210118-095756.PNG]]
 +
 
 +
A new state is usually reached at the end of a transition:
 +
 
 +
:[[File:ClipCapIt-210118-100008.PNG]]
 +
 
 +
A shortcut is the history state, that returns to the most recent state. This is particularly useful when combined with the state shortcuts:
 +
 
 +
:[[File:ClipCapIt-210118-095908.PNG]]
 +
 
 +
It is also possible to enter a nested state via one of its internal startup transition, as seen above using the '''via''' syntax.
 +
 
 +
== Input ==
 +
 
 +
:[[File:ClipCapIt-210118-100242.PNG]]
 +
 
 +
* Fires a transition : the transition is executed when the process consumes the signal
 +
 
 +
* In a given state, the process can expect several signals
 +
 
 +
* May have parameters (use variables to store their values)
 +
 
 +
The following shortcuts are available:
 +
 
 +
:[[File:ClipCapIt-210118-100336.PNG]]
 +
 
 +
* Inputs at level N have priority over inputs at level N-1 (composite states)
 +
* As a consequence, be careful with « asterisk » inputs : if the state is composite, all inner inputs are ignored.
 +
 
 +
== Continuous signals ==
 +
 
 +
Continuous signals are spontaneous transitions that trigger when no input signal is present (standard input always have priority). They are boolean expressions:
 +
 
 +
:[[File:ClipCapIt-210118-110747.PNG]]
 +
 
 +
These can be used to perform background tasks, that will be interrupted as soon as a message is received.
 +
 
 +
 
 +
== Connection ==
 +
 
 +
A connection is a transition that is executed when leaving a nested state. It is named in the nested state itself using the exit symbol, like this:
 +
 
 +
:[[File:ClipCapIt-210118-100713.PNG]]
 +
 
 +
 
 +
The connection symbol, one level above, allows to trigger a corresponding transition when leaving the state:
 +
 
 +
:[[File:ClipCapIt-210118-100951.PNG]]
 +
 
 +
 
 +
''Note''
 +
  Nested states also contain optional '''entry''' and '''exit''' procedures, that are executed in addition to the start transition and to the connection transitions. See below for details.
  
== SDL scope of OpenGEODE ==
+
== Output ==
 +
 
 +
:[[File:ClipCapIt-210118-101539.PNG]]
 +
 
 +
Transmission (sending) of a message, with or without a parameter.
 +
 
 +
NOTE: only one parameter is supported by TASTE.
 +
 
 +
== TASK ==
 +
 
 +
Tasks are elementary actions of a process transition.
 +
They can be either informal:
 +
 
 +
:[[File:ClipCapIt-210118-101729.PNG]]
 +
 
 +
 
 +
(use single quotes and free text)
 +
 
 +
Or formal:
 +
 
 +
:[[File:ClipCapIt-210118-101756.PNG]]
 +
 
 +
 
 +
Formal tasks allow to assign values to variables and to execute '''for loops''' to iterate on arrays.
 +
It is also possible the manipulate data with built-in operators (ternary, math, array concatenation, etc.).
 +
The details are given on this page:
 +
 
 +
[[Technical topic: OpenGEODE - SDL Operators: How to work with data]]
 +
 
 +
== Procedure calls ==
 +
 
 +
Procedures can:
 +
 
 +
* have in and in/out parameters
 +
* return a variable
 +
* be defined locally or externally
 +
 
 +
The procedure call symbol is for calling procedures that do not return variables. Parameters, if any, are separated with commas.
 +
 
 +
:[[File:ClipCapIt-210118-103419.PNG]]
 +
 
 +
 
 +
There are two special built-in procedures that can be called to write strings on screen: '''write''' and '''writeln'''.
 +
They can take multiple parameters separated with commas, for example to display variables of basic types. For exmaple:
 +
 
 +
:[[File:ClipCapIt-210118-103741.PNG]]
 +
 
 +
 
 +
Procedures that return a value must be called within a TASK symbol using this syntax:
 +
 
 +
:[[File:ClipCapIt-210118-104323.PNG]]
 +
 
 +
 
 +
There are also built-in procedures for '''setting and resetting timers''': '''set_timer(time_in_ms, timer_name)''' and '''reset_timer(timer_name)'''.
 +
 
 +
== Decisions ==
 +
 
 +
Like tasks, decisions can be formal or informal. Informal decisions are useful when building the model, and can be made formal when ready.
 +
 
 +
Informal decision and their answers are expressed with single quotes:
 +
 
 +
:[[File:ClipCapIt-210118-104654.PNG]]
 +
 
 +
 
 +
While formal decisions contain expressions:
 +
 
 +
:[[File:ClipCapIt-210118-104736.PNG]]
 +
 
 +
A decision can have more than two answers, and in that case the answers must be mutually exclusive. The last answer can be the special kewword '''else'''.
 +
Decisions can be used to build graphical loops, when used together with join/labels:
 +
 
 +
:[[File:ClipCapIt-210118-105024.PNG]]
 +
 
 +
 
 +
If the expression in the decision is an ENUMERATED variable, the decision answers can be the enumerants:
 +
 
 +
:[[File:ClipCapIt-210118-105232.PNG]]
 +
 
 +
 
 +
If the expression is the built-in '''present''' operator for a CHOICE type variable, the answers are the possible elements of the union:
 +
 
 +
 
 +
:[[File:ClipCapIt-210118-105425.PNG]]
 +
 
 +
 
 +
There is a special decision in SDL called '''decision any''' that allows to trigger a branch randomly:
 +
 
 +
:[[File:ClipCapIt-210118-111213.PNG]]
 +
 
 +
 
 +
== Labels and branches ==
 +
 
 +
:[[File:ClipCapIt-210118-105459.PNG]]
 +
 
 +
Labels and branches allow re-routing and basic loops. They can be used to go to a next state from multiple points without repeating common pre-entry actions (as an alternative to a state '''entry''' procedure).
 +
 
 +
== Procedures ==
 +
 
 +
:[[File:ClipCapIt-210118-105708.PNG]]
 +
 
 +
 
 +
Procedure are sequential sub-functions. They can have in and in/out parameters and optionally return a value.
 +
They have visibility on the parent variables. They can contain local variables, but no internal state (yet standard SDL allows it).
 +
 
 +
:[[File:ClipCapIt-210118-105905.PNG]]
 +
 
 +
 
 +
== Composite states ==
 +
 
 +
OpenGEODE supports both nested and parallel states. Double click on a state to create a nesting structure.
 +
 
 +
:[[File:ClipCapIt-210118-105936.PNG]]
 +
 
 +
If the neseting structure only contain states but no start transitions, they are parallel states. Each of them must then be refined and have their start transitions.
 +
 
 +
Parallel states can't consume the same signals (signal lists are disjoint).
 +
 
 +
== SDL Textual grammar ==
 +
 
 +
 
 +
SDL is both a graphical '''and''' a textual language. OpenGEODE's SDL grammar is defined here:
 +
 
 +
https://github.com/esa/opengeode/blob/master/sdl92.g
 +
 
 +
= SDL in the context of TASTE =
  
 
One important features of SDL is the possibility to describe a system made of components that communicate through messages. This description can be nested: a block can contain other blocks that eventually contain actual state machines.
 
One important features of SDL is the possibility to describe a system made of components that communicate through messages. This description can be nested: a block can contain other blocks that eventually contain actual state machines.
  
This is not directly supported by OpenGEODE because it is done in TASTE using the AADL language.
+
This is not directly supported by OpenGEODE because it is done in TASTE (graphically and textually) using the AADL language.
  
The semantics are nearly similar, with the following differences:
+
'''The semantics are nearly similar''', with the following differences:
  
1. SDL does not allow to specify a cyclic message in this view (periodic activation has to be done using timers inside state machines)
+
1. '''SDL does not allow to specify a cyclic message in this view (periodic activation has to be done using timers inside state machines)'''
  
 
However TASTE allows it in the Interface View:
 
However TASTE allows it in the Interface View:
Line 35: Line 275:
 
In this example, the interface named "monitor" is cyclic. A period has to be specified for it.
 
In this example, the interface named "monitor" is cyclic. A period has to be specified for it.
  
2. In SDL all messages are asynchronous. Direct function calls are possible between two state machines (remote procedure calls) but this communication is hidden from the diagram.
+
2. '''In regular SDL all messages are asynchronous'''. Direct function calls are possible between two state machines (remote procedure calls) but this communication is hidden from the diagram.
  
In TASTE, synchronous calls are expressed in the Interface View:
+
In TASTE, synchronous calls are expressed in the Interface View to expose the remote procedure calls from SDL to an external function.
  
 
:[[File:ClipCapIt-210118-084101.PNG]]
 
:[[File:ClipCapIt-210118-084101.PNG]]
  
 
Synchronous calls are immediately executed (blocking calls) and can be either protected (mutual exclusion between messages) or unprotected (executed immediately no matter what).
 
Synchronous calls are immediately executed (blocking calls) and can be either protected (mutual exclusion between messages) or unprotected (executed immediately no matter what).
 +
As we regular SDL there cannot be (at the moment) synchronous provided interfaces to SDL blocks in TASTE.
  
3. In SDL all active functions are state machines
+
3. '''In SDL all active functions are state machines'''
  
 
In TASTE it is possible to implement them in different languages: SDL, but also Simulink, C, C++, Ada, and even VHDL.
 
In TASTE it is possible to implement them in different languages: SDL, but also Simulink, C, C++, Ada, and even VHDL.
 
TASTE generates the glue code between the functions.
 
TASTE generates the glue code between the functions.
  
4. In SDL, communication is done via messages (called signals) that are defined at system level. This means that a signal name is unique across the system.
+
4. '''In SDL, communication is done via messages''' (called signals) that are defined at system level. This means that a signal name is unique across the system.
  
 
When sending a message, it is possible in SDL to specify the recipient in case several can receive the same signal name. Broadcast and multicast are also supported.
 
When sending a message, it is possible in SDL to specify the recipient in case several can receive the same signal name. Broadcast and multicast are also supported.
Line 64: Line 305:
 
:[[File:ClipCapIt-210118-090408.PNG]]
 
:[[File:ClipCapIt-210118-090408.PNG]]
  
5. SDL allows to specify multiple parameters associated to asynchronous signals.
+
5. '''SDL allows to specify multiple parameters associated to asynchronous signals'''.  
 
 
In TASTE however, it is possible to have only one parameter in asynchronous interfaces(one signal = one message).
 
Synchronous interfaces support multiple in or in/out signals.
 
 
 
6. The SDL standard comes with two ways to describe data types: a legacy (yet very powerful) type system, and ASN.1
 
 
 
TASTE only supports a very small subset of the legacy SDL type system, and relies on ASN.1 instead. ASN.1 is an international standard (ISO and ITU-T), supported by multiple tools and used in lots of applications. It is therefore recommended to use it instead of the built-in SDL syntax for data types.
 
 
 
== SDL concepts overview ==
 
 
 
These are the main symbols used in a SDL state machine:
 
 
 
:[[File:ClipCapIt-210118-092814.PNG]]
 
 
 
State machines in SDL look like flow diagrams and are read vertically. This is a typical SDL transition diagram:
 
 
 
:[Clip_Upload:The file is too large: 1024 KB!]
 
 
 
 
 
We will now go in the details of each symbol.
 
  
 +
In TASTE however, it is possible to have only one parameter in asynchronous interfaces (one signal = one message).
 +
Synchronous interfaces support multiple in or in/out signals. SDL cannot have synchronous '''provided''' interfaces, but it can call synchronous '''required''' interfaces (with multiple parameters)
  
== SDL State ==
+
6. '''The SDL standard comes with two ways to describe data types: a legacy (yet very powerful) type system, and ASN.1
 +
'''
 +
TASTE only supports a very small subset of the legacy SDL type system, and relies on ASN.1 instead. ASN.1 is an international standard (ISO and ITU-T), supported by multiple tools and used in lots of applications. It is therefore recommended to use it instead of the built-in SDL syntax for data types.

Latest revision as of 15:20, 24 February 2021

OpenGEODE - SDL tutorial

Author: Maxime Perrotin

contact: maxime (dot) perrotin (at) esa.int

Introduction

SDL is a rich language and the complete specifications are available on the ITU-T website : https://www.itu.int/rec/T-REC-Z.100

There are several major revisions of the language:

  • SDL88 - the first public version
  • SDL92 - major update adding object orientation
  • SDL96 - minor update fixing issues of SDL92
  • SDL2000 - major update introducing new concepts (agents, exceptions, parallel and nested states)
  • SDL2010 - the baseline of the current version (latest version is from 2019)

Check https://www.sdl-forum.org for more information.

OpenGEODE supports a subset of the last version of the standard. In this page we list the features of this subset and explain how to use them.


SDL concepts overview

These are the main symbols used in a SDL state machine:

ClipCapIt-210118-092814.PNG

State machines in SDL look like flow diagrams and are read vertically. This is a typical SDL transition diagram:

ClipCapIt-210118-094530.PNG


We will now go in the details of each symbol.


Start symbol

There are three places in a SDL model where a START symbol can be used:

1. At the state machine root diagram: It is mandatory here. A state machine has exactly one start transition.

ClipCapIt-210118-094606.PNG


The start transition is executed at process creation

The start transition

- Sets the initial state - May execute initial actions (initialization of variables)


2. Inside procedures. The start symbol has a slightly different shape, and is triggered when the procedure is called:

ClipCapIt-210118-095047.PNG


3. Inside nested states

There can be more than one Start transition in a nested state. In that case they must be given a name.

ClipCapIt-210118-095310.PNG


The selection of the nested state start transition is done one level above, when entering the nested state, using the via syntax:

ClipCapIt-210118-095516.PNG


State / Nextstate

ClipCapIt-210118-095659.PNG
  • Each state has a name
  • In a given state, the process is expecting to receive messages
  • A state can be composite

Note the following shortcut that allow to save diagram space:

ClipCapIt-210118-095756.PNG

A new state is usually reached at the end of a transition:

ClipCapIt-210118-100008.PNG

A shortcut is the history state, that returns to the most recent state. This is particularly useful when combined with the state shortcuts:

ClipCapIt-210118-095908.PNG

It is also possible to enter a nested state via one of its internal startup transition, as seen above using the via syntax.

Input

ClipCapIt-210118-100242.PNG
  • Fires a transition : the transition is executed when the process consumes the signal
  • In a given state, the process can expect several signals
  • May have parameters (use variables to store their values)

The following shortcuts are available:

ClipCapIt-210118-100336.PNG
  • Inputs at level N have priority over inputs at level N-1 (composite states)
  • As a consequence, be careful with « asterisk » inputs : if the state is composite, all inner inputs are ignored.

Continuous signals

Continuous signals are spontaneous transitions that trigger when no input signal is present (standard input always have priority). They are boolean expressions:

ClipCapIt-210118-110747.PNG

These can be used to perform background tasks, that will be interrupted as soon as a message is received.


Connection

A connection is a transition that is executed when leaving a nested state. It is named in the nested state itself using the exit symbol, like this:

ClipCapIt-210118-100713.PNG


The connection symbol, one level above, allows to trigger a corresponding transition when leaving the state:

ClipCapIt-210118-100951.PNG


Note

  Nested states also contain optional entry and exit procedures, that are executed in addition to the start transition and to the connection transitions. See below for details.

Output

ClipCapIt-210118-101539.PNG

Transmission (sending) of a message, with or without a parameter.

NOTE: only one parameter is supported by TASTE.

TASK

Tasks are elementary actions of a process transition. They can be either informal:

ClipCapIt-210118-101729.PNG


(use single quotes and free text)

Or formal:

ClipCapIt-210118-101756.PNG


Formal tasks allow to assign values to variables and to execute for loops to iterate on arrays. It is also possible the manipulate data with built-in operators (ternary, math, array concatenation, etc.). The details are given on this page:

Technical topic: OpenGEODE - SDL Operators: How to work with data

Procedure calls

Procedures can:

  • have in and in/out parameters
  • return a variable
  • be defined locally or externally

The procedure call symbol is for calling procedures that do not return variables. Parameters, if any, are separated with commas.

ClipCapIt-210118-103419.PNG


There are two special built-in procedures that can be called to write strings on screen: write and writeln. They can take multiple parameters separated with commas, for example to display variables of basic types. For exmaple:

ClipCapIt-210118-103741.PNG


Procedures that return a value must be called within a TASK symbol using this syntax:

ClipCapIt-210118-104323.PNG


There are also built-in procedures for setting and resetting timers: set_timer(time_in_ms, timer_name) and reset_timer(timer_name).

Decisions

Like tasks, decisions can be formal or informal. Informal decisions are useful when building the model, and can be made formal when ready.

Informal decision and their answers are expressed with single quotes:

ClipCapIt-210118-104654.PNG


While formal decisions contain expressions:

ClipCapIt-210118-104736.PNG

A decision can have more than two answers, and in that case the answers must be mutually exclusive. The last answer can be the special kewword else. Decisions can be used to build graphical loops, when used together with join/labels:

ClipCapIt-210118-105024.PNG


If the expression in the decision is an ENUMERATED variable, the decision answers can be the enumerants:

ClipCapIt-210118-105232.PNG


If the expression is the built-in present operator for a CHOICE type variable, the answers are the possible elements of the union:


ClipCapIt-210118-105425.PNG


There is a special decision in SDL called decision any that allows to trigger a branch randomly:

ClipCapIt-210118-111213.PNG


Labels and branches

ClipCapIt-210118-105459.PNG

Labels and branches allow re-routing and basic loops. They can be used to go to a next state from multiple points without repeating common pre-entry actions (as an alternative to a state entry procedure).

Procedures

ClipCapIt-210118-105708.PNG


Procedure are sequential sub-functions. They can have in and in/out parameters and optionally return a value. They have visibility on the parent variables. They can contain local variables, but no internal state (yet standard SDL allows it).

ClipCapIt-210118-105905.PNG


Composite states

OpenGEODE supports both nested and parallel states. Double click on a state to create a nesting structure.

ClipCapIt-210118-105936.PNG

If the neseting structure only contain states but no start transitions, they are parallel states. Each of them must then be refined and have their start transitions.

Parallel states can't consume the same signals (signal lists are disjoint).

SDL Textual grammar

SDL is both a graphical and a textual language. OpenGEODE's SDL grammar is defined here:

https://github.com/esa/opengeode/blob/master/sdl92.g

SDL in the context of TASTE

One important features of SDL is the possibility to describe a system made of components that communicate through messages. This description can be nested: a block can contain other blocks that eventually contain actual state machines.

This is not directly supported by OpenGEODE because it is done in TASTE (graphically and textually) using the AADL language.

The semantics are nearly similar, with the following differences:

1. SDL does not allow to specify a cyclic message in this view (periodic activation has to be done using timers inside state machines)

However TASTE allows it in the Interface View:

ClipCapIt-210118-083557.PNG


In this example, the interface named "monitor" is cyclic. A period has to be specified for it.

2. In regular SDL all messages are asynchronous. Direct function calls are possible between two state machines (remote procedure calls) but this communication is hidden from the diagram.

In TASTE, synchronous calls are expressed in the Interface View to expose the remote procedure calls from SDL to an external function.

ClipCapIt-210118-084101.PNG

Synchronous calls are immediately executed (blocking calls) and can be either protected (mutual exclusion between messages) or unprotected (executed immediately no matter what). As we regular SDL there cannot be (at the moment) synchronous provided interfaces to SDL blocks in TASTE.

3. In SDL all active functions are state machines

In TASTE it is possible to implement them in different languages: SDL, but also Simulink, C, C++, Ada, and even VHDL. TASTE generates the glue code between the functions.

4. In SDL, communication is done via messages (called signals) that are defined at system level. This means that a signal name is unique across the system.

When sending a message, it is possible in SDL to specify the recipient in case several can receive the same signal name. Broadcast and multicast are also supported.

In TASTE, the interfaces are defined at function level. Two functions can therefore have the same interface name but with different semantics (different parameters). It is possible to rename the interface at the sender side to avoid ambiguities.

While SDL offers the possibility to specify the recipient when sending a message (OUTPUT message TO sender) there are two things to consider:

a. the state machine's code has to be aware of the system it is connected to, making reuse more difficult in some cases

b. other languages such as C or Ada do not offer such construct

This is how the problem is addressed in TASTE:

ClipCapIt-210118-090408.PNG

5. SDL allows to specify multiple parameters associated to asynchronous signals.

In TASTE however, it is possible to have only one parameter in asynchronous interfaces (one signal = one message). Synchronous interfaces support multiple in or in/out signals. SDL cannot have synchronous provided interfaces, but it can call synchronous required interfaces (with multiple parameters)

6. The SDL standard comes with two ways to describe data types: a legacy (yet very powerful) type system, and ASN.1 TASTE only supports a very small subset of the legacy SDL type system, and relies on ASN.1 instead. ASN.1 is an international standard (ISO and ITU-T), supported by multiple tools and used in lots of applications. It is therefore recommended to use it instead of the built-in SDL syntax for data types.