Basic SDL Specification and Description Language

1
Basic SDLSpecification and Description Language

• Basic SDL

2
SDL for objects defining functionality
While MSC provide overview Object models provide
completeness
3
SDL is designed for systems

• that are
• reactive
• concurrent
• real-time
• distributed
• heterogeneous
• complex

goal a better way to describe behaviour!
Look for SDL info at http//www.sdl-forum.org/
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

goal a readable, formal, abstract and
realistic language!
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

goal a clear and concise way to describe
complex reactive behaviour
6
C example state machine

• void PRC_Validaterun(int signal)
• switch(cur_state)
• case Validateswitch(signal)
• case SIGID_OK / transition
  (Validate,OK) /
• OUTPUT(KEEPSIG(),SELF()-gtGATEGT_PanelControl_D)
  
• // NOTE KEEPSIG() refers to
  the consumed signal directly
• OUTPUT(new SIG_ReleaseCard,
• SELF()-gtGATEGT_PanelControl_CR)
• RETURN()
• return
• case SIGID_ERR / transition (Validate,ERR)
  /
• OUTPUT(KEEPSIG(),SELF()-gtGATEGT_PanelControl_D)
  
• OUTPUT(new SIG_ReleaseCard,
• SELF()-gtGATEGT_PanelControl_CR)
• RETURN()
• return
• ...
• defaultIERROR("Validaterun no such state")
• return

7
Our Example Domain Access Control
8
First sketch of Application system
Access Control System
User panel
User
User server
Authenticator
AccessPoint
Access Control Unit
Door
Door server
Door controller
OperationPoint
Operator terminal
Operator
Authorizer
Operator server
9
System diagram in SDL 1(2)
10
System diagram 2(2)
11
A simple block
12
A block type
13
Pure FSM
logic
input
output
state

• Complete and unambiguous interface behavior
• Purely sequential
• No data, no time

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.

output signal
input signal
input port
FSM
timer op
data op
timeout
timer
save
save queue
data
reveal/view
15
MSC Normal_Accepted
msc Normal_Accepted
16
A process type 1(2)
17
A process type 2(2)
18
A user arrives
19
The user is accepted
20
The user passes
21
A user arrives at the other panel
22
The User Server 1(2)
23
The User Server 2(2)
24
The User ServerInitialisation Procedure
25
The Panel Server
26
OUTPUT destination
27
PID (Process IDentification) operators

• SELF the process itself
• OFFSPRING the most recent process instance
  created by SELF. If no processes have been
  created by SELF, then OFFSPRING is NULL.
• PARENT SELF is the OFFSPRING of PARENT. If SELF
  is not generated dynamically, then PARENT is
  NULL.
• SENDER the process which sent the signal most
  recently consumed by SELF. If no signal has been
  consumed yet, SENDER is NULL.

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

29
Asterisk state and Save
Asterisk state

(exception) state list
(Idle)
Save symbol
Code

• 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

30
What happens here?
process type P1
1(1)
S1
S3
d
e
S4
S5
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
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

33
STRUCT

• 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)/
34
Array

• 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 IntXChar Array(Character,
Integer) ENDNEWTYPE IntXChar

• 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 /

35
SYNTYPES and SYNONYMS

• Use SYNTYPES to make special types from existing
  types
• SYNTYPE Byte Integer
• CONSTANTS 0255
• ENDSYNTYPE Byte
• Use SYNONYMS for symbolic values
• SYNONYM MinInstance Byte 5
• SYNONYM MaxInstance Byte 123

36
SDL and ASN.1

• ASN.1 definitions
• PaymentModule DEFINITIONS
• BEGIN
• CardTypeENUMERATED
• masterVisa, euroExpress, americanCard
• CreditCard SEQUENCE
• ctype CardType,
• nr IA5String (SIZE (0..20))
• END

• SDL use

IMPORTS CardType, CreditCard FROM PaymentModule
CardTypeENUMERATED masterVisa, euroExpress,
americanCard
DCL i INTEGER(0..5)
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

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