Basic SDL Specification and Description Language

FDTFoil no 1

Basic SDLSpecification and Description Language

Basic SDL

FDTFoil no 2

SDL for objects defining functionality

Realisation sof tware electronics mechanics

Deployment

Functionality (Structure Behaviour)

Descriptions

Performance … Dependability ….

Objects Properties

Tests… Measurements

Services …

While MSC provide overview Object models provide completeness

FDTFoil no 3

that are:

• reactive

• concurrent

• real-time

• distributed

• heterogeneous

• complex

that are:

• reactive

• concurrent

• real-time

• distributed

• heterogeneous

• complex

SDL is designed for systems

goal:

a better way to describe behaviour!

goal:

a better way to describe behaviour!

Look for SDL info at http://www.sdl-forum.org/Look for SDL info at http://www.sdl-forum.org/

FDTFoil no 4

It should be better thanimplementation level languages

to support:

• human communication and understanding

• formal analysis and comparison of behaviours

• alternative implementations and design optimisation

to support:

• human communication and understanding

• formal analysis and comparison of behaviours

• alternative implementations and design optimisation

goal: a readable, formal, abstract and realistic language!

FDTFoil no 5

Behaviour in focus

because:

• behaviour is vital to the purpose and quality

• behaviour is

• complex

• dynamic

• invisible

• often infinite

• hard to understand and analyse

because:

• behaviour is vital to the purpose and quality

• behaviour is

• complex

• dynamic

• invisible

• often infinite

• hard to understand and analyse

goal: a clear and concise way to describe complex reactive behaviour

FDTFoil no 6

C++ example state machine

void PRC_Validate::run(int signal){switch(cur_state) {case Validate:switch(signal)

{case SIGID_OK: /* transition (Validate,OK) */ OUTPUT(KEEPSIG(),SELF()->GATE[GT_PanelControl_D]); // NOTE: KEEPSIG() refers to the consumed signal directly OUTPUT(new SIG_ReleaseCard, SELF()->GATE[GT_PanelControl_CR]); RETURN(); return;case SIGID_ERR: /* transition (Validate,ERR) */ OUTPUT(KEEPSIG(),SELF()->GATE[GT_PanelControl_D]); OUTPUT(new SIG_ReleaseCard, SELF()->GATE[GT_PanelControl_CR]); RETURN(); return;

... default:IERROR("Validate::run no such state"); return; }}

FDTFoil no 7

Our Example Domain: Access Control

zone door

Passive objects

group

legal user

member of

has access to consist of

1..*1

1..* 1..* 1..*

Authenticator

Authorizer

User

Card

Operator

Door

Active objects

FDTFoil no 8

First sketch of Application system

User

server

Door

server

Operator

server

Authorizer

AuthenticatorUser

panel

Operator

terminal

User

Operator

DoorDoor

controller

Access Control System

Access

Control

Unit

AccessPoint

OperationPoint

FDTFoil no 9

SYSTEM AccessControl 1(2)

Access

Validation

[(Pin)][(Pout)]

[(Resp)] [(Req)]ap(100):p

vAccessPanel

Doord

Operation

[(Tin)][(Tout)] [(Ack)] [(Modify)]op:

t oOperationTerminal Point

Point [(Dout)]

UnitControl

[(Din)]

System diagram in SDL 1(2)

FDTFoil no 10

System diagram 2(2)

SYSTEM AccessControl 2(2)

AccessPoint OperationPoint

SIGNALDigit(Integer), Card(Integer), Pass, AccessDenied, EnterPIN, EnterCard,DoorPassed, Open, Close, Validate(Integer, Integer), ConfigReq, Accepted,Rejected, Configure(Integer);

SIGNALLIST Pout = Pass, AccessDenied, EnterPIN, EnterCard;SIGNALLIST Pin = Digit, Card;SIGNALLIST Dout = Open, Close;SIGNALLIST Din = DoorPassed; SIGNALLIST Req = Validate, ConfigReq;SIGNALLIST Resp = Accepted, Rejected, Configure;SIGNALLIST Tout =... /*continue until all signallists are defined*/;

NEWTYPE.../* Define global, system specific datatypes, if necessary*/

FDTFoil no 11

A simple block

BLOCK AccessControlUnit 1(1)

Validation[(Resp)] [(Req)]

Operation[(Ack)] [(Modify)]

AccessControl

V

O

Access

ap(100):Access

op:OperationPoint

Point

UnitControl

FDTFoil no 12

Access

ap(100):Access

op:OperationPoint

Point

UnitControl

A block type

BLOCK TYPE AccessPoint 1(2)

[(Pin)][(Pout)]

p

v

d

[(Dout)] [(Din)]

[(Req)][(Resp)]

ps(1,2):PanelServer

ds:DoorServer

UserServer

Val

[(Req)][(Resp)]

[(Pin)][(Pout)]

[(Dout)] [(Din)]

panel

door

[Accept, Reject, Ready]

[UserCode]

[Admit]

[Admitted]

user

access

DoorServer PanelServer

SIGNAL Admit, Admitted, Accept, Reject, Ready, UserCode (Integer, Integer);

p u

d a

FDTFoil no 13

Pure FSM

• Complete and unambiguous interface behavior

• Purely sequential

• No data, no time

• Complete and unambiguous interface behavior

• Purely sequential

• No data, no time

logic

state

input output

Idle Validation Passing

Card/UserCode

Reject /EnterCard

Accept/Pass

Ready/EnterCard

FDTFoil no 14

The SDL “machine”

A process is an agent executing his own actions and having his own local (data) attributes. Processes have discrete behavior. Processes interact by means of "signals". Signals are discrete stimuli which are actively screened and processed by the receiver.

A process is an agent executing his own actions and having his own local (data) attributes. Processes have discrete behavior. Processes interact by means of "signals". Signals are discrete stimuli which are actively screened and processed by the receiver.

input port FSM

timer

data

output signalinput signal

reveal/view

save queue save

timeout timer op data op

FDTFoil no 15

MSC Normal_Accepted

ps_1 UserServerds_1

CardUserCode Validate

AcceptedAccept

PassAdmit

Open

DoorPassedAdmitted

ReadyEnterCard

msc Normal_Accepted

FDTFoil no 16

A process type 1(2)

DCL DoorTimeout Timer;

Initialise

PROCESS TYPE DoorServer 1(2)

Open VIA d

SET(NOW+ 5, DoorTimeout)

Closed

from UserServer

Admit

Open

Initialise

a

[Admit] [Admitted][Open, Close]

d

[Door Passed]

ps(1,2):PanelServer

ds:DoorServer

UserServer

FDTFoil no 17

A process type 2(2)

Closed

DoorTimeout

Close VIA d

Admitted VIA a

RESET (DoorTimeout)

DoorPassedfrom door

Open

PROCESS TYPE DoorServer 2(2)

ps(1,2):PanelServer

ds:DoorServer

UserServer

FDTFoil no 18

A user arrives

Ready

Validate

GetPIN

Card(CardNo)from Card Reader

UserCode (CardNo, Pin)

TO User Server

Idle

Validation

Validate (CardNo, Pin) VIA Val

CurrentPS:= SENDER

from Panel Server


UserServer

ps_1:PanelServer

DCL Pin Integer ; DCL CardNo Integer;

DCL Pin Integer ; DCL CardNo Integer; DCL CurrentPS Pid;

GetPIN

ps_2:PanelServer

FDTFoil no 19

The user is accepted

Validate

User passing

from User Server

Accept

Pass VIA p

Validation

UserPassing

TO ds Admit

Accept TO CurrentPS

Acceptedfrom Access Control

ps_1: PanelServer

UserServer

panel

ds: DoorServer

ps_2: PanelServer

p

FDTFoil no 20

The user passes

Open

DoorTimeout

Close VIA d

Admitted VIA a

RESET (DoorTimeout)

DoorPassed

UserPassing

ReadyTO CurrentPS

Idle

from ds Admitted

Ready

User passing

Readyfrom User Server

EnterCardVIA p

ps_1: PanelServer

ds: DoorServer

UserServerpanel

door

door

FDTFoil no 21

A user arrives at the other panel

Validation

UserPassing

Admit

Accept TO CurrentPS

UserCodeAccepted

Error

*

Validate

from User Server

Accept

ps_1: PanelServer

ps_2: PanelServer

Validate


TO UserServer

Validation

UserServer

FDTFoil no 22

The User Server 1(2)1(2)PROCESS UserServer

UInitialise

UInitialise

Idle

Validation

Error

Validate (CardNo, Pin) VIA Val

DCL Pin Integer ; /* the personal identification*/ DCL CardNo Integer; /* the card identification*/ DCL CurrentPS Pid; /* the current panel server instance*/

CurrentPS:= SENDER

from PanelServer


FDTFoil no 23

The User Server 2(2)

Validation

UserPassing

Idle

TO ds Admit

Accept TO CurrentPS

UserCode

ReadyTO CurrentPS

Idle

*

Error

*

Acceptedfrom Access Control

Rejectedfrom Access Control

RejectTO CurrentPS

UserCodefrom ds

Admitted

2(2)PROCESS UserServer

FDTFoil no 24

The User ServerInitialisation Procedure

WaitConfig

ConfigReq VIA Val

Configure(P)from Access Control

P

Error

(2) (1) ELSE

ps

DCL P Integer; /*the number of panels*/

PROCEDURE UInitialise

ps_2:PanelServer

FDTFoil no 25

The Panel Server

1(1)PROCESS TYPE PanelServer

PInitialise

PInitialise

SET(NOW+ 5, DisplayTime)

Ready

Validate

Ready

GetPIN

GetPIN


TO UserServer

Ready

Display Message

DisplayTime

DCL Pin Integer ; /* the personal identification*/ DCL CardNo Integer; /* the card identification */ DCL DisplayTime Timer;

User passing

Card(CardNo)from CardReader

from User Server

Acceptfrom User Server

Reject

Readyfrom User Server

EnterCard

Pass VIA p AccessDenied

EnterCard

p u

VIA p

VIA p

VIA p

FDTFoil no 26

OUTPUT destination

OUTPUT

no destination TO VIA

process name

PId- expression

Channel or Signalroute

ALL

one possible target is chosen

the process name must be visible

the PId must be known

the connection specifies target

multicast

FDTFoil no 27

PID (Process IDentification) operators

SELFthe process itself

OFFSPRINGthe most recent process instance created by SELF. If no processes have been created by SELF, then OFFSPRING is NULL.

PARENTSELF is the OFFSPRING of PARENT. If SELF is not generated dynamically, then PARENT is NULL.

SENDERthe process which sent the signal most recently consumed by SELF. If no signal has been consumed yet, SENDER is NULL.

SELFthe process itself

OFFSPRINGthe most recent process instance created by SELF. If no processes have been created by SELF, then OFFSPRING is NULL.

PARENTSELF is the OFFSPRING of PARENT. If SELF is not generated dynamically, then PARENT is NULL.

SENDERthe process which sent the signal most recently consumed by SELF. If no signal has been consumed yet, SENDER is NULL.

FDTFoil no 28

SDL signals

• Input Signalname(var1, var2,...)

means:

var1 := parameter no 1, var2 := parameter no 2

• Output Signalname(e1, e2, ...)TO pe

means:

parameter no 1 := e1, parameter no 2 := e2,

Destination := pe,

Origin := SELF

• Input Signalname(var1, var2,...)

means:

var1 := parameter no 1, var2 := parameter no 2

• Output Signalname(e1, e2, ...)TO pe

means:

parameter no 1 := e1, parameter no 2 := e2,

Destination := pe,

Origin := SELF

FDTFoil no 29

Asterisk state and Save

*(Idle)

Code

Asterisk state

(exception) state list

Save symbol

• Asterisk state means all the states in the FSM

• The exception state list in the state symbol modifies the asterisk, such that those state names in the exception state list are not included.

• Saved signals are put in a separate queue for each process.

• Saved signals are brought into the input port when the FSM changes state. The saved signals are inserted first in the input port

• Asterisk state means all the states in the FSM

• The exception state list in the state symbol modifies the asterisk, such that those state names in the exception state list are not included.

• Saved signals are put in a separate queue for each process.

• Saved signals are brought into the input port when the FSM changes state. The saved signals are inserted first in the input port

FDTFoil no 30

What happens here?process type P1 1(1)

a c,d

S1

b d

S2

d

S3

e

S4 S5

P1

S1

e

c

d

a

b

e

FDTFoil no 31

SDL assignments

variable := expression

Variables on the left of the assignment operator receive the right hand side expression value

Expression is an operation or a variable:

operator(e1, e2,...) or Var

“+”(a,b) “-”(3) or a + b - 3 (infix operators + and -)

Variable occurrences in an expression, means extracting the value from the variable

Multiple assignments in one task symbol are separated by comma

variable := expression

Variables on the left of the assignment operator receive the right hand side expression value

Expression is an operation or a variable:

operator(e1, e2,...) or Var

“+”(a,b) “-”(3) or a + b - 3 (infix operators + and -)

Variable occurrences in an expression, means extracting the value from the variable

Multiple assignments in one task symbol are separated by comma

FDTFoil no 32

Data types

The usual:

• Boolean, Character, String, Charstring, Integer, Natural, Real, Array, Powerset, Struct

The special:

• PId - Process Identifier.

Time, Duration

operation: Now

The user defined:

• Newtype, Syntype, Generator

The usual:

• Boolean, Character, String, Charstring, Integer, Natural, Real, Array, Powerset, Struct

The special:

• PId - Process Identifier.

Time, Duration

operation: Now

The user defined:

• Newtype, Syntype, Generator

FDTFoil no 33

STRUCT

NEWTYPE AccessCode STRUCT

cardid, pin Integer;

ENDNEWTYPE AccessCode;

NEWTYPE AccessCode STRUCT

cardid, pin Integer;

ENDNEWTYPE AccessCode;

DCL AC AccessCode ;

AC!cardid := 1234 ;

/* longform: AC := cardidModify!(AC, 1234);*/

temp_pin := AC!pin ;

/* longform: temp_pin := pinExtract!(AC);*/

DCL AC AccessCode ;

AC!cardid := 1234 ;

/* longform: AC := cardidModify!(AC, 1234);*/

temp_pin := AC!pin ;

/* longform: temp_pin := pinExtract!(AC);*/

FDTFoil no 34

Array

Here is how you actually declare an array (in a text symbol):

DCL chrval IntXChar ;

/* declaring array variable for the conversion of characters to integers */

Here is how you actually declare an array (in a text symbol):

DCL chrval IntXChar ;

/* declaring array variable for the conversion of characters to integers */

Here is how you use the array (in a task symbol)

chrval('X') := chrval('Y')-1 ;

/* which uses the shortform of the operators Extract! and Modify! */

The long form would look like:

chrval := Modify!(chrval, 'X', Extract!(chrval,'Y') - 1 ) ;

The long form shall be used in axioms, while in TASKs the short form must be used.

Strings use the same short form as arrays.

Here is how you use the array (in a task symbol)

chrval('X') := chrval('Y')-1 ;

/* which uses the shortform of the operators Extract! and Modify! */

The long form would look like:

chrval := Modify!(chrval, 'X', Extract!(chrval,'Y') - 1 ) ;

The long form shall be used in axioms, while in TASKs the short form must be used.

Strings use the same short form as arrays.

NEWTYPE IntXCharArray(Character, Integer)ENDNEWTYPE IntXChar ;

NEWTYPE IntXCharArray(Character, Integer)ENDNEWTYPE IntXChar ;

FDTFoil no 35

SYNTYPES and SYNONYMS

Use SYNTYPES to make special types from existing types:

SYNTYPE Byte = Integer

CONSTANTS 0:255

ENDSYNTYPE Byte;

Use SYNONYMS for symbolic values:

SYNONYM MinInstance Byte = 5;

SYNONYM MaxInstance Byte = 123;

Use SYNTYPES to make special types from existing types:

SYNTYPE Byte = Integer

CONSTANTS 0:255

ENDSYNTYPE Byte;

Use SYNONYMS for symbolic values:

SYNONYM MinInstance Byte = 5;

SYNONYM MaxInstance Byte = 123;

FDTFoil no 36

SDL and ASN.1

ASN.1 definitions

PaymentModule DEFINITIONS ::=

BEGIN

CardType::=ENUMERATED{

masterVisa, euroExpress, americanCard

};

CreditCard::= SEQUENCE{

ctype CardType,

nr IA5String (SIZE (0..20))

};

…

END

ASN.1 definitions

PaymentModule DEFINITIONS ::=

BEGIN

CardType::=ENUMERATED{

masterVisa, euroExpress, americanCard

};

CreditCard::= SEQUENCE{

ctype CardType,

nr IA5String (SIZE (0..20))

};

…

END

SDL use:SDL use:

IMPORTS CardType, CreditCard

FROM PaymentModule

CardType::=ENUMERATED{masterVisa, euroExpress, americanCard};

DCL i INTEGER(0..5);

FDTFoil no 37

Language features

Two syntaxes:

• SDL/GR - a graphic representation

• SDL/PR - a textual representation

Object orientation:

• objects with behaviour

• object structure described separately from object behaviour

• types defined by composition and by inheritance of structure and behaviour

Two syntaxes:

• SDL/GR - a graphic representation

• SDL/PR - a textual representation

Object orientation:

• objects with behaviour

• object structure described separately from object behaviour

• types defined by composition and by inheritance of structure and behaviour

FDTFoil no 38

Intended application areas

Standards:

• to define unambiguous and consistent protocols;

Tendering:

• to specify requirements

• to compare solutions

Development:

• 1. to specify the required system behaviour

• 2. to design the optimal implementation

• 3. to describe the provided behaviour

• 4. to verifiy and validate the behaviour

Standards:

• to define unambiguous and consistent protocols;

Tendering:

• to specify requirements

• to compare solutions

Development:

• 1. to specify the required system behaviour

• 2. to design the optimal implementation

• 3. to describe the provided behaviour

• 4. to verifiy and validate the behaviour

Realisation sof tware electronics mechanics

Deployment

Functionality (Structure Behaviour)

Descriptions

Performance … Dependability ….

Objects Properties

Tests… Measurements

Services …

14

23

Documents

Basic SDL Specification and Description Language