System

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.

Environment

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.

Block

A block is created as part of the creation of the enclosing block or system. All blocks are created as part of the system creation, that is there is no dynamic creation of blocks.

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.

block set

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" .

channel

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.

delaying channel

A delaying channel is specified by a channel symbol with the arrows at the middle of the channel.

The delay of signals is non-deterministic, but the order of signals is maintained.

non-delaying channel

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 ().

Channels connected to the frame symbol represent the connections to the environment.

package reference clause

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.

The system uses the types defined in the packages SignalLib and the denoted types (AccessPoint, BlockingAccessPoint and LoggingAccessPoint) from the AccessPointLib package.

Package diagram, SignalLib

Figure 17: Package diagram SignalLib

Open figure

This package defines all the signals being used in the access control system.

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.

package

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.

signal definition

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 .

signal list

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.

text symbol

Text symbols are used in order to have textual specifications as part of diagrams, especially for specification of signal types, data types and variables.

There is no limit to the number of text symbols that may occur in a diagram. Text symbols are not connected to other symbols by flow lines.

The text symbol is also used for the graphical representation of a use clause, see Figure 17 .

Package diagram, AccessPointLib

The AccessPointLib package uses the signals defined in the package SignalLib (by the use clause) and defines three block types .

Figure 18: Package diagram AccessPointLib

Open figure

block type reference

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.

Note that the block type reference (as for block references) is merely a graphical shorthand for diagrams. Block type references may be substituted by block type diagrams.

Block type diagram, AccessPoint

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.

Each access point shall handle the interaction with the user via a panel, communicate with the central unit and control the door.

Figure 19: Block type AccessPoint with virtual Controller process type

Open figure

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 type

A block type defines the common properties for a category of blocks. All block of the same type will have the same properties, as specified in the block type diagram.

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.

Block types may contain process types, service types and procedures as well as block types and data types.

block (type) heading

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.

process (reference)

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.

process set

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.

While Panel above is a process reference, and thereby a process set without any associated type, apc is a process set according to the process type Controller and therefore not a process reference.

number of instances

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.

signal route

A signal route represents a communication path between process sets and between process sets and the environment of the enclosing block/block type.

process type

A process type defines the common properties of a category of process instances. A process type is defined by a process type diagram .

virtual process type

A virtual process type is a process type that can be redefined in a subtype of the enclosing block type.

The virtuality is specified in the process type heading or by < virtuality > in the corresponding process type reference symbol, as is done here for the process type Controller.

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).

gate

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.

Gates are defined in block/process/service types and used when connecting sets or instances of these with channels/signal routes.

The signal list associated with the endpoints represents constraints (on incoming/outgoing signals) the gate.

Block type diagram, BlockingAccessPoint

Figure 20: Block type BlockingAccessPoint as a subtype of AccessPoint

Open figure

This block type defines a block type with name BlockingAccessPoint as a subtype of block type AccessPoint. It represents access points that may be blocked by some operator.

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.

A BlockingAccessPoint is a specialised AccessPoint where Controller is extended. This is expressed by the INHERITS clause of the block type heading.

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 .

redefined process type

A redefined process type is a redefinition of the corresponding virtual process type in the super block type, and it is virtual, so that it can be redefined in further subtypes of this block type .

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.

dashed entity

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 block set/block may be connected by channel, and these will then be there in addition to those specified in the super type.

An existing process set/service may be connected by signal routes, and these will then be there in addition to those specified in the super type.

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.

In the textual version of a specification, inherited entities are simply identified by name.

Block type diagram, LoggingAccessPoint

Figure 21: Logging AccessPoint as a subtype of AccessPoint

Open figure

This block type defines a block type with name LoggingAccessPoint as a subtype of block type AccessPoint, adding the process LogDevice.

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.

We notice the keyword FINALIZED in the process type reference. This has a slightly different meaning than REDEFINED.

finalised process type

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.

Process type diagram, Controller

Figure 22: Virtual process type Controller

Open figure

This process type heading defines the process type Controller as a virtual process type. This means that the process type can be redefined in a subtype of the enclosing block type.

Plain AccessPoints have their own (default) definitions of Controller.

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.

Within the process type diagrams, the gates appear as identifiers in the VIA-clause of the output symbols.

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.

process type diagram

A process type diagram defines the properties of a process type. A process type defines the common properties of a category of process instances. A process type is defined by a process type diagram .

process type heading

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 in processes

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" .

Variables of process are created as part of the creation of the process instance.

Variables will get default initial values if nothing else is specified.

The following elements of SDL are used in the definition of Controller behaviour.

procedure reference

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.

start

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.

The start transition in the Controller process is empty, that is there are no actions, so the process just enters the Idle state upon start.

transition

A transition performs a sequence of actions. During a transition, the data of a process may be manipulated and signals may be output.

Actions may be

• task ,
• output ,
• set ,
• reset ,
• export
• create request ,
• procedure call , or
• remote procedure call .

The transition will end with the process entering a

next state,

with a stop,

with a return or

with the transfer of control to another transition.

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.

state

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.

input

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".

The sender expression of the consuming process is given the PId value of the originating process, carried by the signal instance.

virtual (input) transition

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 virtual input transition is a special case of a general notion of virtual transition:

• virtual priority input,
• virtual start,
• virtual spontaneous transition.

In addition a save may be specified as a virtual save.

Redefinition of virtual transitions/saves corresponds closely to redefinition of virtual types:

• A virtual start transition can be redefined to a new start transition.
• A virtual priority input or input transition can be redefined to a new priority input or input transition or to a save.
• A virtual save can be redefined to a priority input, an input transition or a save.
• A virtual spontaneous transition can be redefined to a new spontaneous transition.

task

A task may contain a sequence of assignment statements or behaviour specified in informal text.

The example here is an assignment of (the predefined) SENDER, that is the sender of the signal triggering the transition of which this task is a part, to a PId variable cur_panel.

timer

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 declared similarly to a variable.

set timer

Timers are set and reset in tasks. When a timer has not been set, it is inactive. When it is set, it becomes active.

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 timer signal can be input in the same way as ordinary signals:

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 .

output

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.

The destination of a signal can be specified in various ways. The output symbol may in addition to the signal name (and actual parameters) contain a to-clause and/or a via-clause.

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.

procedure call

A procedure call transfers the interpretation to the procedure definition referenced in the call, and that procedure graph is interpreted.

The interpretation of the transition containing the procedure call continues when the interpretation of the called procedure is finished.

Note that a procedure call symbol has one and only one entrance and one and only one exit. As specified here, the procedure has no parameters.

Process type diagram, redefined Controller in BlockingAccessPoint

Figure 23: Redefined process type with added states and transitions

Open figure

This process type defines the process type Controller (in block type BlockingAccessPoint) as a redefinition of the corresponding virtual process type in block type AccessPoint.

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.

For more details on this mechanisms, see virtual types and specialisation .

save

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,

The effect of the save is valid only for the state to which the save is attached. In the following state, signal instances that have been "saved" are treated as normal signal instances.

asterisk state

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.

Process type diagram, finalised Controller in LoggingAccessPoint

Figure 24: Finalised process type

Open figure

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.

All transitions are inherited from the supertype, except the transitions starting with the state Validation and the signals OK and NOK. The are redefined in this process type.

For more details on this mechanisms, see virtual types and specialisation .

Process diagram, Panel in terms of services

Figure 25: Process in terms of services

Open figure

process diagram

A process diagram defines the properties of a process set , where each of the process instances in the set have the specified properties.

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 .

process heading

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.

formal parameters

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.

When a system is created, the initial processes are created in arbitrary order. The formal parameters of these initial processes have no associated values; i.e. they are undefined.

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.

service composition

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 .

Service diagram, PanelControl

Figure 26: Service diagram, PanelControl

Open figure

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.

When a service ceases to exist, the input signals for that service are discarded. When all services have ceased to exist, the process instance ceases to exist.

variables in services

Variables can be defined in processes, services and procedures. They are defined in text symbols.

Variables of services are created when the service is created as part of the creation of the containing process instance.

Variables will get default initial values if nothing else is specified.

procedure call with parameters

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.

Procedure diagram, GetPIN

Figure 27: Procedure diagram, GetPIN

Open figure

The PanelControl service referenced in Figure "Service diagram, PanelControl" is defined by the service diagram in Figure "Procedure diagram, GetPIN" .

procedure

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.

State names are not visible outside the procedure. The process states are not visible within the procedure.

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.

local variable

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 start

The start transition of a procedure is slightly different from the the start of process/service.

return

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.

The interpretation of a procedure call causes the creation of a procedure instance and the interpretation to commence in the following way:

formal parameter

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".

2. A formal parameter with no explicit attribute has an implicit in attribute.

3. A local variable is created for each variable definition in the procedure-definition.

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.

remote procedures

A procedure may be exported by a (server) process, so that other (clients) processes (clients) can request these procedures executed by the server.

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.

Remote procedures may be value returning (as in our example above), and they may be virtual.

Block diagram, CentralUnit

Figure 28: Block diagram defining the CentralUnit

Open figure

create

A process may create processes in other process sets in the same block, possibly providing actual parameters to the new instance.

The create line (dashed line with arrowhead) indicates possible creations.

Create lines are optional.

create action

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.