SIMULATING SDL USING SITE

Transcription

1 SIMULATING SDL USING SITE KEYWORDS Telecommunications, Model evaluation, Interactive simulation, Real-time simulation ABSTRACT This paper presents a tool chain to compile SDL specifications into simulators. Such simulators can be used to analyse and verify the specification. The SITE code generator translates the specification into C++, which allows to flexibly replace the underlying run-time system. INTRODUCTION INTO SDL Nils Fischbeck, Martin von Löwis Humboldt-Universität zu Berlin Axel-Springer-Str. 54a Berlin fischbec loewis@informatik.hu-berlin.de The following description of SDL is a simplification, for a complete reference, the reader is referred to the ITU recommendation Z.100 (ITU-T 1996b). SDL-96 is the ITU Specification and Description Language. It is standardized in the ITU Recommendation Z.100 and it is based on the concept of communicating extended finite state machines. Each state machine works in a stimulus/response fashion. SDL is mostly used for the specification of telecommunication systems, but can be used to describe any discrete system which exhibits an eventdriven control flow. With the 1992 revision of SDL, object-oriented constructs were introduced into the language. SDL now contains a typing concept for structuring the system, and concepts of virtuality and inheritance to allow for hierarchies of types. SDL provides concepts to describe both the structure and the behaviour of a distributed system. On the structural level, a system or system type is subdivided into blocks. The concept of block is usually used to express physical distribution, meaning that the processes inside different blocks are executed at different physical locations. A block consists of sets of processes, which define the behaviour of the block. The behaviour of a process is described using a state-transition-diagram, which is shared by all processes of a set. All processes execute independently from each other, and possibly in parallel. They communicate by exchanging signals. The signals are delivered via signal routes and channels, and end up in the input port of the receiving process. THE PURPOSE OF SDL SIMULATIONS Specifications written in SDL can serve multiple purposes: yield an informal description of an application, yield a description of a standardized interface (e.g. SDL in ITU-T standards), yield a prototype of an application for design evaluation, yield an executable to derive or evaluate a test specification (e.g. Computer Aided Test Generation (CATG)) or yield an executable specification for deployment on the target device. To improve the quality of the SDL specification the following could be done: manual review, running test sequences against an executable version of the specification, transformation of the specification into a calculus and proving properties of the specification and running a simulation of the specification.

2 This paper focuses on the simulation of SDL specifications. The purposes of the simulation is twofold: evaluating the quality of the specification itself (Are there any programming errors?) and evaluating the design of the application (Does the specification provide the functionality it should?). This separation implies that there is a clear specification on what the application should do. By simulation the following groups of error situations can be identified: structuring errors, communication errors, timing errors and behavioural errors. Note that this structuring does not imply a formal, disjunct or exhaustive definition of errors. Structuring errors comprise all errors regarding the static and dynamic structure of the specification. A structuring error occurs for example if there is no initial instance of a process in a specification or if the maximum number of processes of a kind is reached but additional processes should be created. Communication errors prevent communication or enable communication between wrong entities. The first kind of error can happen if there is no channel or signalroute definition when there should be one. Wrong communication can take place for instance if a signal is addressed to the wrong target process. Timing errors occur when an action is executed at a wrong moment in relation to another event or at a wrong absolute time. The first error can happen for instance if two processes should synchronize but do not. Wrong timer values cause the second kind of error. The last group of errors, behavioural errors, comprise all kinds of errors that programming languages like C++ or Pascal cope with. Examples of such errors are the missing of the initialisation of a variable or the missing of a connection branch in a decision (equivalent to a switch in C). To identify such errors it is necessary that the user can influence the simulation. The SDL integrated tool environment SITE developed at Humboldt-University includes an interactive SDL simulator. The following section gives an introduction into SITE. Thereafter details are given how the simulator is structured internally and what capabilities it has to influence the simulation. THE SDL INTEGRATED TOOL ENVIRONMENT SITE The SITE tools comprise programs from the design of a specification to the generation of executable code. Almost all tool components support the 1996 revision of the language (ITU-T 1996b). The tools support the inclusion of ASN.1 data types according to ITU-T standard Z.105 (ITU-T 1996c). Specifications are written by using the textual or graphical SDL editor. Specifications can be analysed using the SDL analyser to identify syntactical and semantical errors. These errors are marked in the used editor. From a valid specification C++ code can be generated. The generated C++ code can be compiled to yield object files. These files must be either linked with a simulation library to generate an executable simulation. Linked with a run time library an executable application is produced. Additional tools like a message sequence chart editor or cross reference tool are under development.

3 Figure 1: SITE components SDL/GR Specification SDL/PR Specification ASN.1 Module system upper_layer; block service_entity; messages DEFINITIONS ::= BEGIN SDL/ASN.1 Parser Syntax-oriented Editor Semantical Analysis Proto-Lib Common Representation Pretty Printer Sim-Lib C++ Generator main() {...} Implementation Simulation EXECUTING SDL IN A SIMULATION ENVIRONMENT In order to execute an SDL specification, the SITE C++ generator translates the SDL specification into a set of C++ classes. Those classes are derived from classes defined in the SDL simulation library. When the simulation starts, the runtime system creates an instance of the toplevel SDL system. This, in turn, will create enclosed block and process instances. After the initialisation is finished, the start transitions for all processes are executed. The further execution of the specification is driven by the events generated by the execution of prior transitions. In order to simplify maintenance of the generated code, and to allow for better interpretation of the simulation results on the SDL level, the generated C++ classes have a structure similar to the one of SDL. Type specialization of SDL is translated into class inheritance in C++, virtual types of SDL are translated into virtual functions of C++, and actual context parameters are represented as pointers to C++ instances. The simulation library is based on the ODEM library (Ahrens and Fischer 1996) for discrete systems. An SDL process is implemented as a coroutine, which will execute SDL code until it passes control to another process. The scheduling is based on the progress of simulation time and the arrival of input events. Time consumption occurs for the following reasons: a signal is delayed in a channel, a process sets a timer, and the transition of a process consumes time. Because the details of time consumption are not specified on the SDL level, this information needs to be provided during the simulation. To reduce the number of parameters, several pre-packaged sets are provided:

4 zero-time: actions consume no time, single-step: actions consume a single unit of model time, variable delay: the delays for actions are statistically distributed. For simultaneous events, several scheduling strategies are provided. A process can either execute until it blocks, or yield control after processing a single signal. If more than one process is ready at a time, the next process could be either randomly selected, or in a FIFO manner. For delayed channels and remote procedures, the delay can be either constant, depending on the channel, or depending on the signal. If a process is not ready, it waits for the arrival of several stimuli (signal arrival, continuous signals, spontaneous transitions, enabling transitions, and remote procedure invocations). If a signal enters the process input port, the generated transition function is invoked to select the corresponding transition. If the signal input is guarded with an enabling condition, the signal is saved until the enabling condition becomes true. ANALYSING THE SIMULATION RESULTS In order to interpret the simulation results and to control the experiment, an user interface is necessary. Currently, two analysis tools are being developed: a debugger and a MSC generator. The debugger presents the current state of the simulation in the way traditional debuggers do. The MSC generator non-interactively traces the control flow and displays the resulting message sequence chart. In order to develop analysis tools independently from the simulator, a CORBA based interface is provided between the simulator and the analysis tool. Via this interface, the analysis tool can request notification about the following events: process creation and termination, signal arrival, state change, execution of a task and procedure invocation and termination. The debugger uses these events to allow to set breakpoints on state events or source code lines. In addition, the CORBA interface allows to modify the state of the simulation. In particular, the debugger allows to: introduce new signals into and delete signals from the system, create and terminate processes, inspect and modify variables. The message sequence chart generator uses the same events, but does not modify the state of the simulation. Using statistical analyses on the trace data is for further study. APPLICATION OF SITE SDL has been used at Humboldt-University in many application fields. Among them are the following projects. The Platinum project developed an experimental B-ISDN platform to verify the advantages of the new signalling protocol Q.2931ext. This protocol was an outcome of the RACE MAGIC project on new B- ISDN services. Most components in this project were written in SDL and transformed to executables using the development environment SITE. The OOSPEC project used SDL to define a SDL 92 version of the ISDN basic call service. It was used in the ITU-T standard Q.71 to define an overall view of the basic call. SDL was the implementation language to define a prototype of the B-ISDN NNI protocol according to ITU-T standard Q The prototype was simulated to evaluate the protocol definition. In ETSI project PT87 SDL is used to evaluate test specifications in TTCN for B- ISDN protocol Q Therefore a specification of the protocol was used to simulate test purposes and in a later stage a specification will serve as a sample implementation under test to evaluate test cases. In all these projects it has been shown that the

5 development of a simulation or a prototype of the target system using SITE will improve the specification and yield software with higher quality. However the developement of SITE components is an ongoing process which will lead to even more convenient software development tools. New components are an integrated MSC editor and a cross reference viewer. The usage of SITE in an open distributed processing environment based on CORBA is currently investigated (Fischbeck et al.). specifications In FMOODS 97 (Canterbury, United Kingdom). Chapman & Hall. Löwis, M. v SITE - Eine SDL- Entwicklungsumgebung In Formale Beschreibungstechniken für verteilte Systeme (Berlin, Germany, ). GMD. Schröder, R. SDL Integrated Tool Environment, Themen/SITE/. CONCLUSION The specification and description language SDL has proven to serve as an engineering language for the development of applications in the telecommunication domain. For the evaluation of the quality of SDL specifications it is necessary to simulate the system. The SDL integrated tool environment SITE developed at Humboldt-University comprises an SDL simulator with interactive capabilities. It is based on C++ code generated from the SDL specification. REFERENCES Ahrens, K. and Fischer, J Objektorientierte Prozeßsimulation in C++. Addison- Wesley, Bonn. ITU-T Digital Subscriber Signalling System No. two (DSS2) protocol; B-ISDN user-network interface layer 3 specification for basic call/bearer control; Recommendation Q.2931, Part 1: Protocol specification. ITU-T, Genf. ITU-T SDL - Specification Description Language; Recommendation Z.100, Genf. ITU-T SDL in combination with ASN.1; Recommendation Z.105, Genf. ITU-T Message Sequence Charts; Recommendation Z.120, Genf. Fischbeck, N.; Fischer, J.; Holz E.; Löwis, M. v.; Kath, O.; Schröder, R.; Improving the development and validation of viewpoint