Basic SDL Specification and Description Language
Post on 30-Dec-2015
69 Views
Preview:
DESCRIPTION
Transcript
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
UserCode (CardNo, Pin)
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
UserCode (CardNo, Pin)
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
UserCode (CardNo, Pin)
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
UserCode (CardNo, Pin)
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
top related