This part of the SDL tutorial leads you through SDL by means of an example. You will learn about the various elements of SDL by clicking on the desired elements in the diagrams. In case parts of a diagram reference other diagrams, e.g. process references, clicking the name (in underlined blue or red ) will follow the reference and bring you to the referenced diagram.
If you want to be lead through the example top down, start with "System diagram, Access Control System" and follow the diagram references from there.You may alternatively choose to look at the kind of diagram you want to learn about.
"Introduction to the example" gives a short, informal introduction to the example being used throughout.
The purpose of access control systems is in general to control the access to some service to people with known identity, represented by cards and personal codes. In this specific example the system shall control access to access zones by controlling the opening of doors.
Each card holds a unique Card-code that identifies the card. To grant access the system will read the Card-code and then check the corresponding access right. For additional authentication, the user will be asked to enter the secret personal number (PIN).
The card is a plastic card with a magnetic strip holding a card code and possibly an encrypted PIN code. The physical appearance of the panel and the card is shown in Figure "Panel and card of an access control system" . Each panel represents an Access Point.
The main service demanded by the user is to gain access when the card and code is presented to the system, and to deny access if an attempt is made to enter at an access point where the user is not authorised to pass.
A typical access control system will consist of a number of access points and a central unit where validation is performed. Some access points are so-called blocking access points, that is access points that may be blocked by an operator, so that access is denied even with a valid card and code, until the access point is enabled again. Other access point may have the property that they log what is going on at the point.
In order to illustrate as many mechanism of SDL as possible, the example system will consist of three sets of access points, each of a different type. In a real access control system one may choose to give all access points the possibility of being blocked and of logging.
In SDL a system is defined by means of a system diagram. By making a system diagram it has been decided what is part of the system and what is part of the environment of the system.We choose to design the access control system such that the access terminals (called AccessPoints) are within the system, while the users actually getting access are outside the system. The CentralUnit containing the access rights is within the system, while for our current purpose, how the access rights information got into the CentralUnit is not described.
Before drawing this border between the system and the environment and thereby deciding what should be part of the system, a domain analysis will normally have taken place, different solutions will have been considered and different sketches of the system will have been tried out.
This Access Control system consists of one single block (CentralUnit) and three block sets , that is sets of blocks according to block types, connected by channels . It communicates with the environment that is supposed to behave like processes representing the users of the system, the operators and the controlled physical panels and doors at the access points.
A system is in general a set of blocks , block sets and channels. Blocks and block sets are connected with each other or with the environment of the system by means of channels . This means e.g that there may not be processes directly as part of the system and systems will not have global variables.
For the system the environment consists of a set of SDL processes that may send signals to the system and which may receive signals from the system. The signals for this purpose are defined in the system or, as here, in a package ( Package diagram, SignalLib ) used by the system. The users of the system are thus regarded as processes in the environment.
The CentralUnit block is specified directly (singular block), while the other blocks of the system are parts of block sets according to block types. The symbol with CentralUnit is also a reference to a block diagram that describes the properties of the block.
Note that the block reference is merely a graphical shorthand for diagrams. Block references may be substituted by block diagrams, but the surrounding diagrams would be very crowded and illegible if diagrams could not be remotely referenced by block references. The reference defines the scope of the name.
Type-defined blocks are contained in block sets. A block set is a fixed number of blocks with properties according to a block type. The set of AccessPoints is called ap and the number (100) designates the cardinality of the set. A channel connected to a block set (via the gates e or C) will actually represent a set of channel instances.
A block set is not a reference (as CentralUnit). It defines a set of block instances, but it relies on the definition of the block type AccessPoint. This block type definition is not part of the system, but part of the Package diagram, AccessPointLib and defined in "Block type diagram, AccessPoint" .
Blocks and block sets are connected with each other and with the environment by means of channels. A channel is a one-way or two-way directed connection. It is characterised by the signals that it may carry. A channel has a signal list for each direction.
If there is no channel between two blocks, then processes in these two blocks cannot communicate by signal exchange. Processes may, however, communicate by means of remote procedure calls without channels connecting the enclosing blocks.
A non-delaying channel is specified as folows, that is with the arrows at the endpoints. Associated with each direction of a channel are the types of signals that may be conveyed by the channel. The list enclosed by the signal list symbol can be signals (as e.g. Code) or signal lists (as e.g. validity) enclosed in ().
A package reference clause specifies that a system diagram or package diagram use the definitions of other packages. The names following the "/" after the package name denotes the subset of the definitions that are used.
Defining a package SignalLib makes all the signal type definitions become globally defined, and they may be used by more than one system (without "copy-paste"). It is of course possible to let additional signals be defined locally in order to restrict the contexts in which they will be used.
A package is a collection of types, defined by a package diagram. A package may in general contain definitions of types, data generators, signal lists, remote specifications and synonyms. Definitions within a package are made visible to a system definition or other package definitions by a package-reference-clause (use clause).
The package in Figure 17 only contains definitions of signals.
A signal definition defines a set of types of signals. A signal instance is a flow of information between processes, and is an instantiation of a signal type defined by a signal definition. A signal instance can be sent by either the environment or a process.
Signals may carry data values. The types of the values are specified as parameters of the signal definition. The signal Code defined in Figure 17 is defined to carry two integer values.
Signals may be defined in system and block diagrams, and these may then be used for communication between the blocks of the system or the processes of the block. Signals may also be defined in process (type) diagrams, but then they can only be used for communication between processes of the same set. Often signal definitions are collected in packages .
Often the lists of signals associated with channels and signal routes are quite comprehensive and diagrams become crowded. The notion of signallist helps on this. A signallist is a list of signals which has been given a name. Validity, inp and outp are signallists defined in the package and used in the system diagram.
The text symbol is also used for the graphical representation of a use clause, see Figure 17 .
The AccessPointLib package uses the signals defined in the package SignalLib (by the use clause) and defines three block types .
Block types are referenced by means of block type references. Block types are defined in block type diagrams, and they are referenced by means of block type references . The block type reference indicates in which block or system scope unit the block type is defined. The three block type references in Package diagram AccessPointLib indicates that the scope of these are the package and not a specific system.
The block type AccessPoint defines the properties of a general type of access point in the system. The other types of access points (blocking and logging access points) are defined a subtypes of this.
This block type diagram defines the block type with name AccessPoint in the AccessPointLib package. Each block instance of this type will consist of three process sets (Panel, Door, apc). The first two are defined in corresponding process diagrams (they are really just process references ), while apc is a set instances of process type Controller. The process type Controller is defined as a virtual process type , with the keyword VIRTUAL, so that specialisations of AccessPoint may replace that definition with their own definition.
The Panel takes of the physical panel, the Door process takes care of controlling the physical door, while the Controller process handles the communication with the CentralUnit in order to validate users of the access point.
Note the identifiers e and C which in the system diagram occurs inside the block set ap. These identifiers designate gates . Gates are used to indicate which channels of the block type are supposed to connect to which channel connecting an instance of the type. The gate names are defined by the type and visible wherever the type name is visible. Note also that the gate symbols have arrows at the ends and that signal lists are associated with the arrows. The signallists are constraints on the gates and will ensure that the instances of the block type are connected properly to their surroundings.
Block types may contain a connectivity graph of block instances connected by channels. This makes up a structure of nested blocks. At the leaves of this structure there are blocks which contain processes. Blocks cannot contain both blocks and processes at the same level.
In addition to containing structures of blocks or structures of processes, block types may contain other type definitions. This makes up the scoping hierarchy of SDL. Names in enclosing type definitions are the only names visible.
Block types may contain data type definitions, but no variable declarations. This follows from the fact that processes in SDL do .fmnot share data other than signal queues. They share a signal queue in the way that one process appends (output) signals to the queue (the input port), while the other process consumes (input) signals from the same queue. Appending and consuming signals are atomic, non-interruptible operations. The input port is the basic synchronisation mechanism of SDL.
The heading of block type diagrams defines the name of the block type, possible formal context parameters, whether the block type is virtual or not and if it inherits from another block type. The block type in Figure 19 does not have any context parameters and it is not virtual.
A process reference specifies that there is a process set in the enclosing block and that the properties of this process are defined in a separate (referenced) process diagram outside this diagram. A process reference is a shorthand for having the referenced process diagram at this place in the surrounding diagram.
A process set defines a set of processes according to a process type .
Just like we have the distinction between block reference, block type and block set according to type, we have the distinction between process reference, process type and process set according to a type. Our recommendation is that process sets should be described with reference to a process type.
In general process sets may have specified the number of instances in the set.
The numbers in parentheses after the process set name specifies the number of instances in the process set. As defined in above, there are initially no processes, and there is no limit on the number of instances that may be created.
A signal route represents a communication path between process sets and between process sets and the environment of the enclosing block/block type.
A virtual process type is a process type that can be redefined in a subtype of the enclosing block type.
A redefinition of the process type must be a subtype of the type identified in the virtuality constraint. As specified here the process type reference symbol has no explicit virtuality constraint , which means that any redefinition will extend the given definition of Controller (the Controller is its own constraint).
A gate is a potential connection point for channels/signal routes when connecting sets of blocks/processes/services. The same symbol is used in all cases.
BlockingAccessPoints are quite similar to the plain AccessPoints.The only difference is that the BlockingAccessPoints shall be able to react to signals from the CentralUnit that plain AccessPoints will not recognise. BlockingAccessPoint will have a Door (which should not have a new definition), a Panel (which could have a new definition, but need not have a new definition) and a control process Controller which should be able to do the extended controlling.
The block type diagram specifies that BlockingAccessPoint inherits everything from AccessPoint, but it adds a redefinition of Controller and it adds two signal types on the inherited gate C: Enable and Disable. The fact the the gate is inherited is indicated by it being dashed.
In general, entities defined in supertype, inherited in subtypes and for which some additional properties have to be specified in the subtype, are called existing entities , and in the graphical syntax they are dashed entities .
A redefinition of the process type must be a subtype of the type identified in the virtuality constraint. In this case the constraint is not explicitly specified; this implies that the definition of the virtual process type is its own constraint: the redefinition thereby defines an extension (a subtype) of the virtual process type.
A dashed entity is the graphical way of representing an entity that is inherited from a supertype and which needs to be used in the definition of the subtype. There are dashed block sets, process sets, services and gates.
The Z.100 terminology is existing entity .
An existing gate can have constraints in terms of signals on the endpoints of the gate specified, and these are then added to the inherited gate and will then apply in addition to those of the inherited gate.
With LoggingAccessPoint it is not sufficient to only modify the Controller, since there is an addition to the block, namely the LogDevice. The LogDevice must be connected to the Controller along a signalroute (which is added compared with the supertype AccessPoint). lsc has been defined in the AccessPoint definition and is dashed here.
A finalised process type is a redefinition of the corresponding virtual process type in the super block type, and it is not virtual, so that it can not be redefined in further subtypes of this block type.
A final redefinition of the process type must be a subtype of the type identified in the virtuality constraint .
A redefined type can be redefined again in yet another specialisation. A finalised type cannot be redefined. There is a subtle point to making this distinction. Virtual and redefined types are very flexible, but analysis becomes more uncertain since some components may not be entirely known. Finalised types are not flexible any more, they are completely known and, therefore, analysis can be certain.
The new signalroute LD indicates that it is not be possible to derive the finalised Controller by only adding a number of new transitions to the basic Controller. In order to get new transitions, we need either new input signals or new states. The Controller of LoggingAccessPoint has neither new signals, which can be seen from the channels to the lap set of logging access points, nor new states. In fact the LogDevice should be invoked for most transitions since the requirement was to trace the transactions. Then our need is to modify (redefine) some of the existing transitions.
A Controller process will start executing the start transition. In this case the start transition is empty and simply leads to the Idle state. The process will remain in the Idle state until it receives an input signal. It expects to receive a Code signal containing information about the card id and personal identity number from the Panel. It may, however, be prepared to receive other signals as well. The Idle state is followed by one input symbol which describes the consumption of the signal Code. If the process is in the Idle state and signals other than Code are received, they will be discarded.
We have defined three process gates P, D and U with associated process gate constraints. We note that the enclosing AccessPoint definition uses these gates in connection with the instance lsc of Controller.
When we want to analyse the type enclosing the virtual type (here, block type AccessPoint) we wish to know something about the instances of the virtual types even though we know they may be redefined in subtypes. At least we must know the static interface, i.e. the gates. Very often we would like to know more about the type and, therefore, the header of a virtual type may include a virtuality constraint . The virtuality constraint is of the form "atleast type-identifier". All "matches" (redefinitions and finalisations) of the virtual must be specialisations of the type referred to by the type-identifier of the constraint.
The heading of process type diagrams defines the name of the process type, its virtuality (and constraint), its formal context parameters and if it inherits from another process type. The heading in Figure 22 defines a virtual process types without any context parameters and without any parameters.
Variables can be defined in processes, services and procedures. They are defined in text symbols.
SDL supports predefined types including Character, Boolean, Integer, Natural, Real and PId (Process Instance Identifier). The variables cid and PIN in Figure 22 are defined to be of type Integer, while the variable cur_panel is of type PId, which means that it denotes a process instance.
For a short introduction to the definition of user-defined types see "Specifying properties of variables: data types" .
A procedure reference specifies that there is a procedure in the enclosing entity and that the properties of this procedure are defined in a separate (referenced) procedure diagram outside this diagram.
In the example here, unlockDoor is a procedure defined locally to Controller, and it is referenced by the symbol containing "unlockDoor" - that is there is a procedure diagram defining the properties of unlockDoor.
There is only one start symbol for a process. The transition from the start takes place when the process is generated. A process may be generated either at system start-up or as a result of a create request from another process.
A transition performs a sequence of actions. During a transition, the data of a process may be manipulated and signals may be output.
The controller process has three transitions : one starting in the state Idle and two in the state Validation. They are all input transitions, that is they are triggered by the consumption of a signal from the input queue of the process.
A state represents a particular condition in which a process may consume a signal resulting in a transition. If the state has neither spontaneous transitions nor continuous signals, and there are no signal instances in the input port, otherwise than those mentioned in a save, then the process waits in the state until a signal instance is received.
An input allows the consumption of the specified input signal instance (here of type Code).The variables associated with the input (here cid and PIN) are assigned the values conveyed by the consumed signal.
The values will be assigned to the variables from left to right. If there is no variable associated with the input for a sort specified in the signal, the value of this sort is discarded. If there is no value associated with a sort specified in the signal, the corresponding variable becomes "undefined".
A virtual input transition specifies that subtypes of type with this transition may redefine it, that is it must input the signal in the state, but the following transition may be redefined
A task may contain a sequence of assignment statements or behaviour specified in informal text.
In addition to assignments, task may specify the setting and resetting of timers . Timers are just like alarm clocks. The process waiting for a timer is passively waiting since the process needs not sample them. Timers will issue time-out signals when their time is reached.
A timer is set with a time value. time is a special data type and is mainly used in connection with timers. The expression "now+10" is a time value and it adds the time expression now and the duration 10 (here:seconds). now is an operator of the time data type and it returns the current real time. Duration is another special data type and it is also mainly used in connection with timers. You may add or subtract duration to time and get time. You may divide or multiply duration by a real and get duration. You may subtract a time value from another time value and get duration.
The semantics of timers is this: a time value is set in a timer and it becomes active. When the time is reached, a signal with the same name as the timer itself will be sent to the process itself. Then the timer becomes inactive.
A timer may be reset and it then becomes inactive and no signal will be issued. (If an inactive timer is reset, then it remains inactive.) A reset will also remove a timer signal instance already in the input port. This happens when the timer has expired, but the time-out signal has not been consumed.
If an active Timer is set, the time value associated with the timer receives a new value. The timer is still active. If a timer is set to a time which is already passed, the timer will immediately issue the time-out signal.
Timer signals may contain data as other signals may contain data. Different parameter values in set means generation of several timer instances. reset must match these parameter values to eliminate the correct timer instance.
For more details, see timers .
An output generates a signal of the specified signal type (here Code), containing the specified actual parameters (here cid and PIN), and send this signal instance to the specified destination.
When the to- and via-clauses are omitted, there should be a unique destination for the signal based on the signal identifier. If there is a set of possible destinations, one of the destinations will be chosen non-deterministically. In our case the path and destination follow implicitly from the signalroutes and channels in the block diagrams.
When the to-clause is explicit, it specifies a process uniquely either by its (visible) name or by a "pointer" value. This "pointer" value in SDL is known as "PId" (Process Identifier). When a process is identified by its name in the to-clause, this means that it has to be within the same block since process names outside the block cannot be visible.
In order to specify the path the signal should follow, it is possible to append to the output statement a via-clause which lists the path of signalroutes and channels which the signal will be sent through. The VIA-clause may also specify a gate. Furthermore, the via-clause may be extended to "via all" and then if there is more than one channel instance in the path a signal instance will be generated for each channel instance. This happens for example when we have block sets. This is how we can describe a multicast message.
It is also specified that it inherits the same process type. This is, however, not necessary, as by default a redefinition of a virtual type without an explicit constraint will inherit the properties of the virtual type.
Inheritance of a process type implies inheritance of all states and transitions of the supertype. The asterisk state implies all states, also the inherited. The state Idle indicated as nextstate is the state Idle defined in the supertype.
A save specifies that the signals in the save symbol are retained in the input port in the order of their arrival.
As specified in Figure 23 (an asterisk save) all signals except Enable are saved. For a given state there may be only one asterisk save,
An asterisk state is a shorthand for all states except those listed in an accompanying asterisk state list.
The state names in an asterisk state list must be distinct and must be contained in other state list in the enclosing body or in the body of a supertype. As specified here, the asterisk state implies a state (with the corresponding transition) for each of the states except s1 and s2.
This process type defines the process type Controller (in block type LoggingAccessPoint) as a finalised redefinition of the corresponding virtual process type in block type AccessPoint. This means that it is not virtual, so it can not be redefined in subtypes of the enclosing block type.
It is also specified that it inherits the same process type. This is, however, not necessary, as by default a redefinition of a virtual type without an explicit constraint will inherit the properties of the virtual type.
The behaviour of processes may be defined either by means of a procedure graph (states and transitions) or by means of a substructure of services connected by signal routes. The behaviour of each of the services is defined by means of states and transitions. The process defined in Figure 25 is defined by means of services .
The heading of process diagrams (defining a process set directly without any process type) defines the name of the process set and the initial/maximum number of instances in the set.
If the process shall have formal parameters they are also specified as part of the process heading. Formal parameters are (local) variables of the process instances. They get values as part of the creation of the process instance.
If the initial number is omitted (as in Figure 25 ), then the (default) value is 1. If the maximum number is omitted, then there is no limit on the number of instances.
As defined in Figure 25 the processes of this process set are defined by means of a composition of services . Service instances are components of the process instance, and cannot be addressed as separate objects. They share the input port and the expressions self, parent, offspring and sender of the process instance.
A service instance is a state machine, and it is described as in Figure 26 .
When the process instance is created, the service starts are executed in arbitrary order. No state of any service is interpreted, before all service starts have been completed. A service start is considered completed when the service instance for the first time enters a state (possibly inside a called procedure) or interprets a stop.
Only one service at a time is executing a transition. When the executing service reaches a state, the next signal in the input port (which is not saved by the service, otherwise capable of consuming it) is given to the service that is capable of consuming it.
A procedure may have formal parameters, and in the call the actual parameters are provided.
The pin parameter is in/out which means that the actual parameter corresponding to formal pin will be updated whenever the formal pin is updated within GetPIN. This is just like var parameters in Pascal or reference parameters in C++. The no_dig parameter is an in parameter which means that the procedure will have a local variable with the name of the parameter. This variable will assume the value of its corresponding actual argument at entry. Changes in the value of in parameters will not be transmitted to the actual argument. This is just like traditional value parameters.
Procedures define patterns of behaviour that processes/services may execute at several places or several times during their life-time. The behaviour of a procedure is defined in the same way as for processes (that is by means of states and transitions), a procedure may have (local) variables, and in addition it may have in, out, in/out parameters.
The procedure in Figure 27 accepts a number of Digits as input signals in the state WaitDigit. The local variable i is increased by one for each digit, and when i equals the required number of digits, the procedure returns.
A procedure variable is a local variable within the procedure instance. It is created when the procedure start is interpreted, and it ceases to exist when the return of the procedure graph is interpreted. Variables will get default initial values if nothing else is specified.
Procedure calls may be actions or part of expressions (value returning procedures only). A value returning procedure is a procedure where an expression is associated with the return, and the value of this expression is returned.
1. A local variable is created for each in parameter, having the name and sort of the in parameter. The variable gets the value of the expression given by the corresponding actual parameter if present. Otherwise the variable gets no value, i.e. it becomes "undefined".
4. Each in/out parameter denotes a variable which is given in the actual parameter expression. The contained Variable-name is used throughout the interpretation of the procedure graph when referring to the value of the variable or when assigning a new value to the variable.
5. The transition contained in the < procedure start area > is interpreted.
The nodes of the procedure graph are interpreted in the same manner as the equivalent nodes of a process or service graph, i.e. the procedure has the same complete valid input signal set as the enclosing process, and the same input port as the instance of the enclosing process that has called it, either directly or indirectly.
The remote procedure mechanism consists of four interdependent language constructs:
1. The exporting of a procedure . A procedure which is made visible by other processes is marked with the keyword exported preceding the procedure heading, e.g. "exported procedure Validate ..." from a process within the CentralUnit. The exporting process can control in which states it will accept the remote request. It may also specify to save the request to other states. The controlling of the acceptance is done by using input and save symbols with the remote procedure name preceded by the keyword procedure.
2. The importing of a procedure . When a process, service or procedure wants to import a remote procedure, it must specify the signature of this procedure in an "imported procedure specification" in a text area. The specification in our case would read: "imported procedure Validate; returns integer;" where the integer returned would give the result of the validation.
3. The specification of remote procedure . In SDL all names must be defined in a specific scope. Thus, the names of remote procedures must be defined in the context in which the actual definition of the procedure and the calls will be contained. In our case the definition of the procedure Validate is within the CentralUnit and the call is in Controller of the AccessPoint. The scope unit enclosing all these is the system itself. There we will find a text area with the following text: "remote procedure Validate; returns integer;".
4. The calling of a remote procedure . The calling of the remote procedure is indistinguishable from local procedure calls unless the caller explicitly states which process it will request the procedure executed by. This can be done by a to-clause with a PId following the procedure name of the call.
As specified in Figure 28 the process CUControl creates Validation processes. In the process graph of CUControl, the creation will be specified by a create action.