Andrews University

School of Business
Department of Management, Marketing and Information Systems

SDL

A Paper

Presented in Partial Fulfillment

Requirement for INFS 226

Hardware And Software Systems

By

John Doe

February 27, 2005
Table of Contents

3. History of SDL
4. SDL Components And Features
6. SDL Strengths And Weaknesses
7. SDL Versus Z And VDM
8. SDL’s Place in the Context of Formal Methods

Introduction
	In recent years, a cooing crescendo can be heard that formal methods posses the potential to assist in delivering a high quality software product in a reasonable amount of time to the market place.  This seems to be particularly the case when tackling large, complex systems where the daunting task is to manage a behemoth by multiple developers with as much accuracy and sanity as possible.
Although various formal methods have been created and developed over the past few decades with the goal of enhancing software development, many have typically focused on filling a particular niche given a company’s or academic institution’s goals, needs or interests.  SDL (Specification and Description Language) was birthed in such a context – the telecommunications industry. 
Since its inception in 1972 and initial emergence in 1976, however, it has continued to grow and mature through infancy, toddler-hood, prepubescence, adolescence, and perhaps into a more mature language that is interested in interacting and even marrying with other languages. After all, SDL is 29 years old and still holding.
2. What Is SDL?
SDL is a general-purpose, formal, object-oriented, description language defined by The International Telecommunications Union – Telecommunications Standardization Sector (ITU-T), formerly known as Comite Consultatif International Telegraphique et Telephonique (CCITT) - as recommendation Z.100.
Although primarily developed for the specification and behavior description of complex, real-time, event-driven, distributed, interactive telecommunciation-related applications consisting of many concurrent, parallel processes communicating with each other via discrete signals, its wider appeal was soon realized outside the telecommunications industry.  Presently, SDL is used by other industries such as railway, aircraft, medical, automobile, and packaging systems.  One of SDL’s most recent forays has been embedded systems.
3. History of SDL 
In 1972, SDL’s inception occurred within CCITT with a 15-member multinational study group including representatives from large telecommunications companies such as Bellcore, Ericsson, and Motorola.  Their objective was to develop a standard specification language for the telecommunications industry given the various telecommunications environments.  Although originally an informal drawing technique, SDL evolved into a first version, which emerged in 1976, and was eventually given the accolade “standard” language by CCITT in 1980 as the Z.100 Recommendation.
Since the 1976 and 1980 versions, SDL updates have occurred every U.S. Presidential inauguration year – 1984, 1988, 1992, 1996, and 2000.  Significant changes were introduced in SDL-84, SDL-92, and SDL-2000.  SDL-84 incorporated ADTs (Abstract Data Types).  SDL-92, which is a superset of SDL-88, brought object-oriented features to the language.  
SDL-2000 extended the object-oriented features in several significant ways.  First, programming directly in SDL was further supported largely by revising the data model to accommodate global data and referenced objects.  Second, object modeling was strengthened.  Third, SDL’s structuring components (such as systems, blocks, processes, procedures, etc) were unified via an active and passive agent concept.  Fourth, ASN.1 modules with SDL no longer require any changes of the language’s main body.  Finally, SDL-2000 provides better support for code generation.
SDL’s popularity significantly rose in the early 1990s as the result of telecommunications standards such as GSM, PCS and Intelligent Networks being specified in SDL as well as the concurrent introduction of MSC (Message Sequence Charts) as a standard to complement SDL.  MSC offers the ability to gather requirements, function as a tracing language in simulations, and even assist in the validation and test of a system.
Currently, two SDL formats exist. The first format, which is named SDL-GR, is graphical.  The second format is textual and called SDL-PR (Phrase Representation).  These two formats are equivalent, which permit the automatic translation between both.
4. SDL Components And Features
SDL is a graphical (or textual) formal language designed to specify and describe telecommunication system behavior such as call processing, maintenance, error handling, system control, and data communication protocol design.  To accomplish this goal, SDL incorporates numerous concepts including types, instances, communication and visibility concepts, and dynamic semantics.
SDL also can be applied to non-telecommunication systems such as real-time, distributed, and event-driven – especially if such systems are large and complex.  Its flexibility and general applicability stems largely from its basic theoretical model as well as its key components (structures, communication, behavior, data, and inheritance).
SDL’s basic theoretical model consists of a set of extended finite state machines (FSM) running in parallel.  Each machine is independent of all others but can communicate with another FSM via discrete signals.
An SDL structure can consist of a four-level hierarchy: system, block, process, and procedure.  The division of a system into these four hierarchies is known as “partitioning the system.”  At the top System level, a system can be broken down into various Blocks (i.e., subsystems or modules).  This permits the hiding of details and encourages the creation of intellectually manageable-sized modules. Once a system has been divided into blocks, each block can be further subdivided into Processes.  Each process has its own separate memory space.  In addition, each process type can be viewed as a nested hierarchical state machine that may consist of one or more substate machines (i.e., Procedures).  A procedure can be recursive, local to a process, or even global.  SDL also allows a procedure call that executes within another process’ context.  Blocks and channels comprise an SDL system’s static structure while its dynamic structure consists of the interaction of processes and signals.

Although SDL does not utilize global data, it does possess two main communication mechanisms: asynchronous signals and synchronous remote procedure calls.  Block and process interfaces are defined via combined channel and signal route architecture.  
SDL defines time and timers in an ingenious and conceptual manner, which is especially useful in both real-time and distributed systems.  For instance, a process can set timers to expire within a given time interval to implement “time-outs” in the event of exceptions as well as to measure and control other processes’ and systems’ response times.  The timer-initiated process is notified by means of a signal when an SDL timer expires, much like an interrupt.  The ability to map SDL time to the time of the target system provides SDL with a temporal abstraction as well as the capability to simulate time in SDL models before the target system becomes available.
It is interesting to note that signal and process priorities lie outside the scope of SDL and are left for the user in the implementation phase.  In addition, an SDL signal can be sent only to one process instance at a time.  Broadcasting is also left for the user in the implementation phase, if desired.
As stated above, a system’s dynamic behavior is described in its processes.  A process can be created either at system start or run time.  A process can be instantiated more than once and even during the same time interval.  Confusion as to which instance of a process should receive a particular signal is eliminated since each process is uniquely identified by a PId.  Consequently, processes and process instances can work both independently and concurrently, making SDL a real-time language.
Two methods of data description are permitted in SDL: ADT and ASN.1.  The latter allows data sharing between languages and the reuse of existing data structures.  In SDL, an ADT possesses no particular data structure.  Rather, it simply specifies (1) a set of values, (2) a set of allowed operations, and (3) a set of equations that the operations must satisfy.  Thus, it is relatively non-complicated to map an SDL data type to those of other high-level languages.  An example of the Boolean ADT operators Not and Equals is given below:

Included in SDL are predefined sorts for variables of the following types: integer, real, natural, Boolean, character, duration, time, charstring, and PId.  ADTs in SDL are also useful to hide data manipulation (via operators) and algorithmic components of a specification as well as creating external routine interfaces.
Inheritance is a property of object-oriented languages and since SDL is an object-oriented language, it possesses this characteristic as well.  In SDL, however, inheritance has been given the nomenclature “specialization.”  Specialization occurs one of two ways in SDL – either a subtype might add properties not in the supertype or a subtype may redefine virtual types and transitions already defined in the supertype.
Other methodical components of SDL include Block Interaction Diagrams (BID), Validity Rules (GS), Mapping (MAP), Time Sequence Diagrams, and Message Sequence Charts (MSC).
5. SDL Advocates, Applicational Areas, And Industrial Use
Two European companies provide the main commercial products for SDL – SDT (SDL Development Tool) from Telelogic S.A. in Sweden and ObjectGeode from Verilog S.A. in France.  Both companies provide tool suites for SDL specification, simulation, verification, and C/C++ code generation.  
Telelogic, formerly the Swedish Telecom’s research and development arm, became commercially independent in 1991 and then united with the Saab-Combitech Group in 1995.  Since then, Telelogic has promoted its SDT globally to major telecommunication organizations and researchers as well as into the embedded arena.
Telelogic has also invaded England where it has assisted Britain’s BT (British Telecom) as it composed specifications in SDL rather than on traditional paper for new equipment.  The result would provide for automatic code generation as well as code and equipment testing based on the resultant specification. This is especially valuable since BT would be able to simulate the result of adding new equipment into its existing and complex telecommunications network. 
SDL, however, is not the sole possession of European technology.  Rather, major telecommunication companies worldwide have adopted SDL to develop internal frameworks that assist in developing system-level specifications for large telecommunication services.  Such companies include Lucent, IBM, NTT, Hewlett-Packard, Nortel, Siemens, Alcatel, Ericcson and France Telecom.  Even U.S. companies have employed the commercial suites for a higher-level software specification.
Although SDL was created and developed with the telecommunications industry in mind, it has increasingly been applied in other industries.  Some examples include satellite communications, aeronautical standardization, medical equipment, and railway control systems as well as real-time embedded systems for automobile radios, GSM cellular phones, modems and backup tape drives.  
A particular success in the embedded arena involved the cooperation of Telelogic with the German software company S&P Media, which resulted in the development of an automatic code generator for embedded systems.
One of SDL’s main advocates is the SDL Forum Society.  This non-profit organization seeks to (1) promote SDL as well as MSC (Message Sequence Chart), (2) provide and disseminate information concerning the use and development of both SDL and MSC, (3) to support SDL and MSC education, and (4) to plan and organize various SDL and MSC events such as the SDL Forum.  The SDL Forum Society’s Web site is very informative and contains a broad introduction to SDL.
6. SDL Strengths And Weaknesses
From the limited literature perused for this survey article, it is quite evident that SDL possesses a plethora of strengths and positive qualities.  As stated above, one of SDL’s greatest strength is its ability to describe large, complex, real-time systems.  Some other salubrious qualities are enumerated next. First, SDL is a nonprietary internationally standardized language. Second, SDL is a formal language.  As such, the semantics underlying every symbol and concept are clearly, unambiguously, and precisely defined with mathematical rigor.  This is extremely important for most technical systems – especially mission-critical ones. Third, SDL is graphical and symbol-based.  Consequently, it is very intuitive and easy to learn.  Even non-users can quickly discern a system’s structure and behavior with little formal training in using SDL. Fourth, SDL is object-oriented (OO), which means that it supports encapsulation, polymorphism, and dynamic binding.  Furthermore, SDL customizes the usual OO class data objects (i.e., passive objects) by introducing active object concepts such as systems, blocks, and state machines. Fifth, SDL is highly testable.  In fact, when compared with traditional nonformal design techniques, SDL is far superior due largely to its formalism for parallelism, interfaces, communication, and time. Sixth, SDL facilitates maintenance and reuse for large projects as well as permitting information sharing between multiple systems.  This is accomplished by SDL Packages, which are graphical SDL libraries that define data structures, signals, block, process and system types. Seventh, SDL possesses abstraction mechanisms that result in seamless portability between cross-compilers and operating systems.  Also permitted is the mapping of SDL processes to physical processes, interprocess communication (IPC) schemes, and time – and of all this is determined by the user.  Furthermore, these same abstraction mechanisms also allow an SDL system to be independent of distribution architecture and method, which makes SDL ideal for modeling and implementing distributed systems. Finally, Code can be directly generated from SDL.  This feature coupled with the high-level nature of SDL effects an extremely cost-efficient means for developing software.  In fact, it has been claimed that SDL can reduce the size of source code by fourfold.
Perhaps the most impressive feature of SDL is its ability to interface with other languages.  For instance, SDL is used with MSC (Mobile Switching Center), ASN.1 and TTCN (Tree and Tabular Combined Notation) for systems engineering.  Also included in this illustrious wedding of languages is UML (Unified Modeling Language), OMT (Object Modeling Technique), CORBA (Common Object Request Broker Architecture), and IDL (Interface Description Language).
Interestingly, no significant SDL limitations were gleaned from the sources consulted for this survey article.  One could surmise, of course, that further research would uncover at least a few SDL blemishes.

7. SDL Versus Z And VDM
SDL has several similarities with Z and/or VDM.  Some of these include: (a) All three languages can be used for software specification: (b) All three are formal languages, which means that each has clear, precise, unambiguous interpretation for its syntax and symbols; (c) All three are able to specify large systems by breaking such systems down into manageable, modular components - Z uses schemas; VDM employs “operational decomposition”; and SDL uses “specialization”: (d) SDL and Z are easily accessible to a wide audience as is VDM if the user has programming familiarity; and (e) SDL and VDM possess features that encourage the conversion of a specification into a target programming language.
SDL also differs from Z and/or VDM in several ways: (a) SDL is more easy and intuitive to learn largely due to its graphical notations whereas Z and VDM have a greater learning curve  - especially for the uninitiated; (b) a Z specification is much more difficult to implement in a target programming language than an SDL or even VDM one since, for instance, it lacks some imperative programming and higher-level specification features: (c) SDL was designed with tool support in mind:  This was not the case with Z and VDM; and (d) VDM and Z cannot specify concurrent processes, but SDL can. 
8. SDL’s Place in the Context of Formal Methods
In the general context of formal methods, SDL appears to do it all.  Whereas formal languages such as Z specialize in specification and VDM’s umbrella further shadows into design, SDL can equally boast of this and more.  Whether the user’s interest is in specification, design, code-generation, testing, validation, verification, or even maintenance, SDL can most likely assist in some way.  Furthermore, whether the system is real-time, distributed, event-driven, complex, very large, or even object-oriented, SDL is probably up to the task.  
At the ripe old age of 29, SDL has grown from a parochial telecommunications specification and description language to a more-involved polyglot-centered maturer language possessing capabilities applicable to just about every phase of the traditional software development life cycle.  SDL appears comfortably ensconced for the long haul, and it is worth considering SDL for a system that meets any of the SDL criteria mentioned above.  Although cliché, SDL just might be the best thing since sliced bread!

Bibliography

Bjorkander, Morgan and Anders Ek. “UML, SDL-2000 Team In Real-Time Modeling Bid” in Electronic Engineering Times. Issue 1080. September 27, 1999: pp. 108-110.
Blysa, Per. “Language Specifies And Describes Design” in Electronic Engineering Times. Issue 965. August 4, 1997: pp. 92-3.
Jerraya, Ahmed A. “Specification And Description Language Has Its Say” in Electronic Engineering Times. Issue 957.  June 9, 1997: pp.72-3.
www.iec.org/tutorials/sdl/glossary.html
www.iec.org/tutorials/sdl/index.html
www.iec.org/tutorials/sdl/topic01.html
www.iec.org/tutorials/sdl/topic02.html
www.iec.org/tutorials/sdl/topic03.html
www.iec.org/tutorials/sdl/topic04.html
www.iec.org/tutorials/sdl/topic05.html
www.iec.org/tutorials/sdl/topic06.html
www.iec.org/tutorials/sdl/topic07.html
www.informatik.uni-bremen.de/uniform/gdpa/methods/m-csdl.htm
www.sdl-forum.org/SDL/index.htm
www.sdl-forum-org/