Hubbry Logo
Specification and Description LanguageSpecification and Description LanguageMain
Open search
Specification and Description Language
Community hub
Specification and Description Language
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Specification and Description Language
Specification and Description Language
Specification and Description Language
View on Wikipedia
from Wikipedia

Specification and Description Language (SDL) is a specification language targeted at the unambiguous specification and description of the behaviour of reactive and distributed systems.

Overview

[edit]

The ITU-T has defined SDL in Recommendations Z.100 to Z.106. SDL originally focused on telecommunication systems; As of 2016 its current areas of application include process control and real-time applications in general. Due to its nature it can be used to represent simulation systems [1] without ambiguity and with a graphical notation.

The Specification and Description Language provides both a graphical Graphic Representation (SDL/GR) as well as a textual Phrase Representation (SDL/PR), which are both equivalent representations of the same underlying semantics. Models are usually shown in the graphical SDL/GR form, and SDL/PR is mainly used for exchanging models between tools. A system is specified as a set of interconnected abstract machines which are extensions of finite-state machines (FSM).[2]

The language is formally complete,[3] so it can be used for code generation for either simulation or final targets.

The Specification and Description Language covers five main aspects: structure, communication, behavior, data, and inheritance. The behavior of components is explained by partitioning the system into a series of hierarchies. Communication between the components takes place through gates connected by channels. The channels are of delayed channel type, so communication is usually asynchronous, but when the delay is set to zero (that is, no delay) the communication becomes synchronous.

The first version of the language was released in 1976 using graphical syntax (SDL-76). This was revised in 1980 with some rudimentary semantics (SDL-80). The semantics were refined in 1984 (SDL-84), the textual form was introduced for machine processing and data was introduced. In 1988, SDL-88 was released with a formal basis for the language: an abstract grammar as well as a concrete grammar and a full formal definition. The version released in 1992 (SDL-92) introduced object-oriented concepts such as inheritance, abstract generic types etc., with the object-oriented features described by transformations into non-object oriented ones. SDL-2010 is the latest version, an updated version of SDL-2000 that was completely based on object-orientation, rather than description by transformations. This version is accompanied by a UML-Profile: ITU-T Recommendation Z.109 (04/12), SDL-2010 combined with UML. SDL-2010 also introduced the support of C data types as initially introduced by SDL-RT.

Organization

[edit]

Hierarchy level

[edit]

The hierarchy level of SDL is structured as follows.

  • Library package
  • System agent
  • Block agent
  • Process agent
  • Procedure type
  • Remote procedure

Architecture

[edit]

An SDL system is made of functional blocks and each block can be further decomposed in sub-blocks. The lowest level block is composed of one process or several processes described as finite-state machines.

Communication

[edit]

Blocks are connected through channels that carry the messages (or signals) exchanged between the blocks. A block agent consists of process agents.

Behavior

[edit]

Each process agent is a state machine that contributes to the action carried out by the system. A message stimulus coming from the environment or from another agent to an agent is called a signal. Signals received by a process agent are first placed in a queue (the input port). When the state machine is waiting in a state, if the first signal in the input port is enabled for that state it starts a transition leading to another state. Transitions can output signals to other agents or to the environment. A process agent is allowed to contain procedure types so that the same actions can be invoked from different places. It is also allowed to call a remote procedure type to invoke a procedure in another agent (or even another system) and wait for a response.

In this example MyVariable is of type INTEGER and is the only variable in the process. The first transition is the start transition that initializes the local variable. A connection request message conReq is sent, a 5 seconds timer conReqTimer is started, and the state machine goes to the connecting state. In the connecting state if the timer goes off -that is equivalent to a message receive- the connection request is sent again up to 10 times. If a connection confirmation is received the state machine goes to connected state. This is a typical telecommunication protocol scenario.

Available symbols are:

Data

[edit]

SDL Abstract Data Types (ADT) support basic data types such as INTEGER, REAL, CHARSTRING as well as structured ones such as structures (STRUCT), enumerated (LITERALS), constants (SYNONYMS). Syntax looks like the one from Pascal, for example an assignment is written ':='.

Variants

[edit]
  • SDL-RT is based on the ITU Specification and Description Language replacing the data language with C.[4] Latest version of SDL standard (SDL'2010) now includes the support of C data types and syntax making SDL-RT basic principle part of the official standard.
  • TNSDL is a variant developed by Nokia for their internal use.
[edit]
  • MSC Message Sequence Chart. Another ITU-T related notation to describe the dynamic behavior of a system.
  • ASN.1 (Abstract Syntax Notation One). An ISO standard to describe data types that can be used within SDL.
  • TTCN-3 Testing and Test Control Notation version 3. A testing language standardized by ITU-T and written by ETSI.
  • Unified Modeling Language A generic modeling notation. A profile has been standardized based on SDL.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Specification and Description Language

View on Grokipedia
from Grokipedia
The Specification and Description Language (SDL) is a formal, object-oriented language standardized by the () for the unambiguous specification and description of the behavior of complex, real-time, reactive, and distributed systems, with a primary focus on but applicable to other domains. It employs a graphical notation based on communicating extended finite state machines (EFSMs) to model system structure, data types, communication via signals and channels, and dynamic behavior through processes and procedures. Developed to support the full lifecycle from to and testing, SDL emphasizes precision, reusability, and verifiability in specifying concurrent, event-driven applications. SDL's origins trace back to 1972 within the ITU-T's predecessor, the CCITT, where a began developing formal techniques for telecommunication systems. The first version was outlined in 1976 and formally defined in ITU-T Recommendation Z.100 in 1980, with subsequent revisions in 1984, 1988, 1992 (introducing object-oriented features like and encapsulation), 1996, and 1999 (SDL-2000, which enhanced the and agent concepts). Further updates in 2010 (SDL-2010, removing exceptions and adding input mechanisms like "input via gate"), 2016, 2019, and the latest in June 2021 have refined its semantics, static structure, and integration with other standards. The language is defined across the ITU-T Z.100–Z.109 series of recommendations, ensuring a consistent framework for formal techniques (FDTs). At its core, SDL organizes specifications hierarchically: a system comprises interconnected blocks, each containing processes (active agents modeling behavior) and procedures (reusable subroutines), with data defined using abstract data types (ADTs) or ASN.1. Communication occurs asynchronously through signals sent over channels, supporting distributed architectures without shared memory. Its strengths include formal semantics for simulation, verification, and code generation; graphical and textual representations for clarity; and scalability for large-scale systems, making it highly testable and portable across tools from vendors like Telelogic (now part of IBM) and others. SDL integrates well with complementary ITU-T languages such as Message Sequence Charts (MSC) for scenario description, ASN.1 for data encoding, and TTCN-3 for testing. SDL has been widely adopted in telecommunications for protocol design and system verification, underpinning standards like SS7 and . Beyond telecom, it applies to embedded systems in (e.g., flight control), railway signaling, medical devices, and industrial automation, where reliability and real-time constraints are critical. Its evolution continues through the SDL Forum Society, which promotes research, tool development, and to maintain relevance in modern software engineering practices.

Introduction

Definition and Purpose

Specification and Description Language (SDL) is an object-oriented, standardized by the —Telecommunication Standardization Sector () in Recommendation Z.100, designed for specifying and describing complex, event-driven, real-time, and interactive systems, particularly in . It enables the unambiguous modeling of system behavior, , and through precise constructs that support reactive environments with asynchronous communication via discrete signals. Initially developed in the by a CCITT comprising experts from companies like and , SDL addressed the need for reliable protocol design in increasingly . The primary purposes of SDL include the specification of communication protocols and system architectures, validation of designs through simulation and formal verification, and the automatic generation of executable code from models. By focusing on reactive systems—where components respond to external events rather than executing in a strictly sequential manner—SDL facilitates the description of distributed and concurrent processes, making it suitable for applications requiring high reliability and performance. Key benefits of SDL stem from its formal semantics, which allow for rigorous verification to detect inconsistencies early in the design process, and its graphical notation, which enhances readability and communication among stakeholders without sacrificing precision. Additionally, its inherent support for concurrency and distribution enables efficient modeling of parallel activities and inter-system interactions, reducing errors in large-scale implementations.

Historical Development

The Specification and Description Language (SDL) originated from research efforts initiated by the International Telegraph and Telephone Consultative Committee (CCITT, now known as ) in 1972, specifically aimed at providing a formal method for specifying protocols and systems. This work addressed the need for unambiguous description of complex, event-driven systems in the domain, building on earlier ITU studies from 1968 on switching systems. The first formal version of SDL was published in 1976 as part of the CCITT Recommendations in the Z.100 series, appearing in the so-called Orange Book edition and establishing a basic graphical notation for system behavior. SDL underwent major revisions aligned with CCITT/ITU-T plenary assemblies, reflecting evolving needs in system specification. The 1980 Yellow Book edition introduced formal semantics for processes, enhancing the language's ability to model dynamic behavior. The 1984 Red Book further advanced SDL by incorporating abstract data types, allowing for more structured data handling and algebraic specifications. The 1988 Blue Book (SDL-88) focused on process-oriented enhancements, including improved support for concurrency, system composition, and remote procedures, which facilitated the development of effective simulation and validation tools. The 1992 revision (SDL-92) introduced object-oriented features such as inheritance and encapsulation. The 1996 revision expanded the language and simplified interfacing with other tools. The late marked a pivotal shift in SDL's , with the 1999 edition (SDL-2000) further enhancing the object-oriented features with agents, polymorphism, and a more comprehensive object model, moving toward more modular and reusable designs; this version received minor updates in 2007 for compatibility. SDL-2010, approved in 2010 and last revised in 2021, refined these elements by removing , adding input mechanisms such as "input via gate," improving formal semantics, and enhancing integration with other languages and support for distributed systems, without introducing major new constructs. Key influential events in SDL's development include its widespread adoption in European Telecommunications Standards Institute (ETSI) specifications for protocol design and validation, starting in the 1980s and continuing through standards like the Intelligent Network Application Protocol. In the 1990s, SDL was integrated with Message Sequence Charts (MSC, standardized in ITU-T Z.120 in 1992 and revised in 1996), enabling complementary use for scenario-based and state-based modeling in telecommunications applications. As of 2025, SDL-2010 remains the active standard, with only minor errata issued since its 2021 revision and no major new version announced, sustaining its role in maintaining legacy infrastructure while supporting modeling in modern distributed and reactive systems, such as embedded and environments.

Language Fundamentals

Graphical Notation

The graphical notation of the Specification and Description Language (SDL), also known as SDL/GR, provides a formal, visual representation for specifying the structure and behavior of complex, real-time systems, particularly in . Standardized by the , this notation uses distinct symbols to model system hierarchies, communication pathways, and dynamic processes, enabling unambiguous descriptions that complement the textual form. Core graphical elements include block diagrams for capturing system structure, process graphs for depicting behavior, and symbols for signals and channels to illustrate communication. Block diagrams outline the static organization, showing how the system decomposes into subsystems, while process graphs represent extended finite state machines that define operational dynamics. State transition diagrams, embedded within process graphs, detail how processes respond to inputs and evolve through states. Additionally, data elements in diagrams reference Abstract Syntax Notation One () types to specify message contents precisely. Specific symbols standardize the notation: rectangles denote blocks, representing modular components that encapsulate and channels; rounded rectangles indicate states within a process, marking points where the process awaits stimuli; dashed arrows symbolize signals, depicting asynchronous messages routed between processes; and solid lines represent channels, defining pathways for across blocks. These symbols support hierarchical , where blocks can nest to form larger architectures, and integrate with notations for structured data visualization in signal definitions. The graphical notation offers advantages such as intuitiveness for engineers familiar with diagrammatic modeling, facilitating quick comprehension of system overviews without delving into code. It enables hierarchical decomposition for managing complexity in large-scale designs and integrates seamlessly with computer-aided tools for editing, validation, and simulation, reducing errors in specification. For example, a simple block-process hierarchy might depict a system block named "ControlUnit" as a rectangle containing two subprocess blocks—"InputHandler" and "OutputManager"—connected by a solid-line channel labeled "DataFlow." Within "InputHandler," a process graph shows a rounded rectangle for the initial "Idle" state, from which a dashed arrow labeled "ReceiveSignal" transitions to a "Processing" state upon signal input, illustrating basic structural and behavioral integration.

Textual Notation

The textual notation of SDL provides a linear, programmatic representation of specifications as an alternative to its graphical form, enabling precise, machine-readable descriptions of system structures and behaviors. Defined in ITU-T Recommendation Z.100, this notation follows a formal concrete syntax expressed in extended Backus-Naur Form (EBNF), which outlines the grammar for elements such as agent types and diagrams. Key keywords structure the language, including for top-level system types, BLOCK for modular subsystems, for concurrent entities, STATE for behavioral states, INPUT and OUTPUT for signal handling, and SIGNAL for communication primitives. For instance, a basic process declaration might appear as:

PROCESS example_process; DCL variable INTEGER; STATE initial_state; INPUT signal1; TASK variable := 1; ENDPROCESS;

PROCESS example_process; DCL variable INTEGER; STATE initial_state; INPUT signal1; TASK variable := 1; ENDPROCESS;

This syntax ensures unambiguous parsing while mirroring the hierarchical organization of SDL models. Central to the textual notation are syntactic elements for declarations, transitions, and procedures, all grounded in the formal grammar of Z.100. Data type declarations use keywords like SYNONYM to define aliases (e.g., SYNONYM mytype INTEGER;) and DCL for variables (e.g., DCL counter INTEGER;). Transitions within states employ TASK for actions, such as assignments or informal text (e.g., TASK counter := counter + 1;), and DECISION for conditional branches (e.g., DECISION; IF condition THEN alternative1 ELSE alternative2 ENDIF;). Procedures are specified with the PROCEDURE keyword, supporting parameters and remote calls (e.g., PROCEDURE compute (IN param INTEGER) RETURNS result INTEGER;), and integrate with the abstract syntax notation defined in Annex F of Z.100 for type expressions and specializations. The notation also accommodates integration for advanced data types, using operators like mkstring for bitstrings. Conversion between graphical and textual notations is bidirectional, with rules in Appendix III of Z.100 facilitating transformations—such as replacing graphical references with textual definitions—primarily supported through SDL tools for programmatic generation and editing. While the textual form excels in precision for and automated analysis due to its parseable structure, it can be less intuitive for visualizing complex hierarchies compared to diagrams. Limitations include the absence of direct support for parallel transitions in processes and restrictions on instantiating abstract types, enforcing sequential semantics. As of the latest Recommendation Z.100 (06/2021), the textual notation aligns with SDL-2010 semantics, excluding deprecated features like exceptions.

Basic Constructs

The basic constructs of the Specification and Description Language (SDL) form the foundational elements for modeling concurrent, real-time systems through extended finite state machines and asynchronous communication. These include processes as the primary active entities, signals for exchange, channels for communications, and timers for handling time-dependent behaviors. Together, they enable the specification of system dynamics without relying on shared variables, emphasizing message-passing paradigms suitable for distributed applications. Processes in SDL are defined as independent agents or instances of process types that encapsulate state machines, local variables, and procedures, each identified by a unique process identifier (Pid). They represent the basic units of execution, capable of being created dynamically at runtime via a create expression and terminated explicitly, allowing for flexible system modeling. Each process operates as an extended , transitioning between states in response to inputs or internal events, with no internal parallelism—transitions execute sequentially to completion within the process. Signals serve as the core mechanism for asynchronous communication in SDL, defined as discrete events with optional parameters that carry data between processes. They are declared in signal lists or sets and transmitted from output nodes to trigger state transitions in receiving processes via input nodes. Unlike synchronous calls, signals are non-blocking, enabling decoupled interactions that model real-world message flows in reactive systems. Channels act as abstract communication paths that connect processes or blocks, defining the routes over which signals are transported. Each channel maintains a FIFO (first-in, first-out) queue to ensure signals are delivered in the order received, preventing race conditions without requiring shared memory access. Channels are specified with identifiers and gates, providing a clear interface for signal compatibility and constraining possible interactions. Timers introduce real-time capabilities by allowing processes to set time-based events that generate spontaneous signals upon expiration. Defined as agent-owned objects, can be set with duration expressions and reset as needed, with their status queried via boolean expressions to support timeout handling and response-time guarantees. These signals from timer expiry are treated identically to external signals, integrating temporal aspects seamlessly into the state machine behavior. The semantics of these constructs emphasize implicit parallelism, where multiple processes execute concurrently and independently, interleaved in an implementation-defined manner without shared state. Communication occurs exclusively through via signals over channels, enforcing a no-shared-memory model that avoids issues common in multi-threaded programming. Synchronization in SDL relies on FIFO queues at input ports and channels, ensuring deterministic ordering of signal consumption. The "save" construct allows non-matching signals to be temporarily stored in a secondary queue for later processing, preventing loss while maintaining queue discipline. Spontaneous transitions enable internal state changes without external inputs, triggered by timers or procedure calls, providing a mechanism for autonomous process evolution. As per SDL-2010 and later ( Z.100, 06/2021), is not supported, but new mechanisms like "input via " allow selective reception of signals at specific gates. These elements collectively serve as building blocks for organizing larger system structures, abstracting complex interactions into verifiable, concurrent models.

System Organization

Hierarchical Levels

The Specification and Description Language (SDL) employs a multi-level hierarchical abstraction to decompose complex systems into manageable structural units, enabling modular specification from high-level overviews to detailed behavioral elements. At the top level, the system serves as the outermost container that interfaces with the external environment, encapsulating all subordinate components without internal visibility to outsiders. This level is defined using a system diagram or reference area, representing a single instance that communicates via channels to the environment. Below the system, blocks act as structural units that organize the system's architecture, each featuring defined interfaces through gates and channels for controlled interaction. Blocks can nest sub-blocks or directly contain processes, supporting concurrent execution among their components and facilitating subdivision of large-scale designs. The hierarchy extends to processes, which are the fundamental behavioral units modeled as extended finite state machines, executing actions in response to inputs and maintaining internal state. Processes reside within blocks and can themselves contain subordinate processes, allowing recursive while preserving isolation of internal dynamics. In later versions of SDL, such as SDL-2000 and beyond, finer-grained behavioral subunits like procedures or state aggregations serve roles akin to sub-processes, enabling encapsulation of reusable functionality within processes without altering the core hierarchy. Decomposition follows strict rules: blocks may contain either sub-blocks for further structural partitioning or processes for behavioral implementation, with all internal signals and data scoped to their containing level to prevent external interference. Internal signals within a block or are hidden from higher levels through encapsulation mechanisms, ensuring that only explicitly defined interfaces expose behavior. Interfaces are managed via import and export gates, which define entry and exit points for signals on diagrams, allowing selective routing through channels while concealing implementation details. This hiding is formalized in the valid input signal sets and visibility rules (public, protected, private), promoting without impacting the observable external behavior of parent agents. According to ITU-T Recommendation Z.100, this hierarchical structure supports encapsulation such that modifications at lower levels do not affect the external semantics of higher levels, providing a formal basis for verifiable system modeling. The approach yields significant benefits, including enhanced modularity for dividing large systems among development teams, reusability of components across specifications, and scalability for applications like telecommunications networks where thousands of interacting entities must be managed coherently. For instance, in telecom protocol designs, blocks can represent network subsystems while processes handle protocol state transitions, streamlining verification and maintenance. This vertical decomposition complements the basic constructs of processes, such as states and transitions, by organizing them into a cohesive architectural framework.

Architectural Elements

In SDL, blocks serve as the primary modular units for organizing complex systems into manageable subsystems, each encapsulating one or more processes and potentially nested blocks to promote encapsulation and scalability in large-scale designs. Gates act as defined connection points on the boundaries of blocks, specifying entry and exit locations for signals to ensure clear and controlled interactions between subsystems. Channels function as typed pathways that link gates between blocks, supporting unidirectional or bidirectional asynchronous communication of signals with associated parameters, thereby enforcing type safety and modularity in signal routing. The overall system architecture in SDL is constructed by interconnecting blocks via these channels, forming a static structure that outlines the topological organization without specifying runtime dynamics. Interface specifications for blocks include signal lists that enumerate the discrete signals permissible on incoming and outgoing channels, channel sets that group related channels for collective management, and points that coordinate signal exchanges, such as through remote procedure calls. In object-oriented SDL variants introduced in SDL-2000 and refined in subsequent standards, abstract interfaces enable the definition of polymorphic types and hierarchies for blocks and signals, allowing subsystems to be specified at higher levels of abstraction while supporting implementation-specific refinements. A fundamental design principle of SDL's architecture is the separation of structural elements from behavioral descriptions, where blocks, , and channels define the system's static composition independently of the extended finite state machine (EFSM) behaviors within processes, thereby enabling modular refinement, reuse, and verification of components without altering the overall topology. As an illustrative example, consider a simple architecture: the block connects to the environment via external on incoming and outgoing channels for raw data signals, while internal link it to the block through typed channels carrying framed packets, allowing layered abstraction without exposing lower-level details to upper layers.

Communication Primitives

In SDL, communication between components is modeled through asynchronous using signals as the primary primitive. Signals represent discrete events that carry data parameters and are sent via the OUTPUT construct from a sender and received via the INPUT construct in a receiver , enabling interactions without direct . Channels serve as the routing mechanism, defining paths between agents such as processes or blocks, and support to specific instances or sets of instances, including multi-cast scenarios where a signal is routed to multiple destinations through connected gates. The communication model is inherently asynchronous, with OUTPUT operations being non-blocking—signals are placed in FIFO queues at the receiver without suspending the sender—while INPUT operations consume the highest-priority signal from the queue if priorities are defined, ensuring ordered processing based on arrival time or explicit priority levels. Unlike synchronous languages, SDL prohibits direct procedure calls between processes, relying exclusively on this message-passing paradigm to maintain and avoid implicit coupling. Advanced features introduced in SDL-2000 include remote procedure calls (RPCs), implemented as paired signals (pCALL for and pREPLY for response) that simulate procedural behavior across agents while preserving asynchrony, with timers to mitigate potential deadlocks. Signal sets provide a mechanism for grouping related signals, allowing compact definitions of valid inputs in states and facilitating prioritized or conditional handling without enumerating each signal individually. The formal semantics of these , as defined in Recommendation Z.100 Annex F, ensure consistency through abstract syntax transformations and interpretation rules that model signal flows as queue-based operations, preventing deadlocks via complete transition execution and for unreachable signals. Channels define the static architecture for routing, with signals transmitted dynamically during execution.

Behavioral Descriptions

In SDL, behavioral descriptions model the dynamic aspects of systems using extended finite state machines (EFSMs) defined within processes, which act as the fundamental reactive agents. These EFSMs capture the control flow of individual process instances, where each process represents an independent thread of execution that interacts with its environment through stimuli and responses. The state-transition structure allows for precise specification of how processes evolve over time in response to events, forming the core of SDL's reactive paradigm as standardized by ITU-T. Transitions in SDL processes connect states and are initiated by inputs (such as received signals), tasks (for executing operations), decisions (for conditional logic), or outputs (for emitting signals). Each transition follows a linear sequence of these elements, ensuring a clear path from one state to the next, and states themselves can include entry actions (executed upon arrival) and exit actions (executed upon departure) to handle state-specific initialization or cleanup. This structure supports hierarchical states in composite forms, where entry and exit actions propagate through nested levels for modular behavior definition. Key elements enhancing behavioral expressiveness include spontaneous transitions, which activate without an external stimulus to model internal or timed events; continuous signals, which represent persistent conditions in real-time systems and trigger transitions when their Boolean value evaluates to true; and procedure calls, which encapsulate reusable behavioral units that can be invoked locally within a process or remotely across instances, supporting recursion and parameter passing. Additionally, SDL achieves concurrency by instantiating multiple processes that execute independently and in parallel at the system level, interleaving their actions nondeterministically while each maintains sequential integrity. These features collectively enable the specification of complex, concurrent reactive behaviors without introducing nondeterminism in individual transitions. The of SDL enforce deterministic behavior by executing exactly one transition per instance at a time, completing it atomically before considering the next stimulus. For concurrent inputs, priority resolution follows signal arrival order or explicit priorities assigned to input nodes, ensuring unambiguous selection and preventing race conditions. is provided through constructs like ELSE branches in decisions and inputs, which serve as default cases to manage unforeseen conditions or unhandled signals, thereby enhancing robustness. SDL's formal semantics, as detailed in its ITU-T definition, facilitate verification through model checking techniques that assess properties such as liveness (e.g., guaranteed progress without infinite loops) and (e.g., absence of invalid states or deadlocks). These analyses leverage the language's state-based structure to exhaustively explore execution paths, often applied in tools for protocol validation where communication triggers initiate transitions.

Data Types and Structures

SDL supports a range of data types categorized into basic, structured, and abstract types, enabling precise specification of system data. Basic types include predefined sorts such as , Character, , Real, Duration, Time, and Bit, each with associated literals, operations, and implicit comparison operators like equality and ordering. These types form the foundation for simple value representations, with supporting logical values (true/false), Integer handling whole numbers, and Duration/Time managing temporal aspects essential for real-time systems. Structured types extend basic types through constructions like records, arrays, and other composites, allowing complex organization. Records, defined as Cartesian products of sorts, support optional components and default initializations, while arrays and vectors provide indexed access for ordered collections. Additional structured types include (sequence of characters), Bitstring (sequence of bits aligning with ), Powerset (unordered unique collections), and (multisets). Agent types, such as , block, and , also qualify as structured types, encapsulating behavioral and elements hierarchically. Abstract types facilitate high-level without exposing implementation details, often leveraging external notations like for complex structures such as protocol messages. SDL integrates through dedicated constructs, where modules are treated as packages importable into SDL specifications, enabling shared data definitions across languages. For instance, SEQUENCE maps to SDL records, ENUMERATED to literal-based types, and BIT STRING to Bitstring, ensuring platform-independent . User-defined abstract types use constructors like or syntype (e.g., Octet as Bitstring of fixed size 8), inheriting from a universal Any type while prohibiting direct instantiation. Key features enhance data usability, including type synonyms for renaming existing types to improve (e.g., defining Octetstring as a for String), operators for manipulation (predefined like for or user-defined with axioms), and views for abstracting data access without revealing internals. Data appears in signals as parameter lists carrying values during communication and in variables as storage scoped to processes or blocks, with visibility controlled via public, protected, or private modifiers. The SDL data language, formalized in Recommendation Z.100, incorporates object-oriented extensions in SDL-2000, such as classes via object types that support , specialization, and virtual operations for polymorphic behavior. SDL enforces strong typing to prevent runtime errors, requiring strict compatibility checks during static analysis, including sort matching for assignments and operations. The core language supports bounded dynamic creation of process instances using CREATE and TERMINATE, with predefined maximum counts to ensure predictable resource usage in embedded systems. These data elements integrate seamlessly into behavioral descriptions for state transitions and actions.

Standards and Evolution

ITU-T Recommendations

The primary ITU-T Recommendation defining the Specification and Description Language (SDL) is Z.100, initially approved in 1980 and most recently updated in June 2021 as an overview of SDL-2010. This document establishes the core language definition, including formal semantics based on extended finite state machines for , data types and structures for information representation, and hierarchical decomposition for system organization, along with usage guidelines for specifying reactive telecommunication systems. It includes annexes providing practical examples, a metamodel for the language's abstract syntax, and formal semantic definitions in Annexes F1 (general overview), F2, and F3 to ensure precise interpretation and implementation. The SDL standard is elaborated through the Z.100 series of Recommendations (Z.101 to Z.109), which collectively form the complete reference manual for SDL-2010 and address various extensions and applications. For example, Z.101 specifies basic language constructs, while Z.105 details the integration of SDL with modules to enhance definitions and encoding. Complementing these, Recommendation Z.120 on Message Sequence Charts (MSC) supports SDL by providing a notation for interaction scenarios, enabling combined use for comprehensive system descriptions. Conformance to SDL is defined across multiple levels to support tool , including graphical and textual notations, environments, and code generation processes. Recommendation Z.106 outlines specific conformance requirements for the SDL Conceptual Interface Format (), with Level 1 ensuring compatibility with textual representations for incomplete specifications and Level 2 extending to full graphical elements; these were refined in the edition of the series to address ambiguities and errata for improved clarity. The SDL Recommendations are governed and maintained by Study Group 17 (Security), which oversees periodic reviews to align with evolving telecommunication needs, though the language's foundational structure has remained stable since the SDL-2010 milestone.

Version Milestones

The Specification and Description Language (SDL) was first standardized in 1976 as a process-based language primarily designed for specifying communication protocols in systems. This initial version focused on extended finite state machines to , providing a graphical notation for processes and channels without support for complex data handling. In 1988, SDL-88 introduced abstract data types (ADTs) and service concepts, enhancing the language's ability to define data independently of implementation details and to model service interactions more formally. These additions established a rigorous formal semantics for the language, allowing for abstract specifications of types via sorts, values, and operations, while services enabled the description of protocol layers and interfaces. The 1993 release, known as SDL-92, introduced object-orientation to SDL, including agents as first-class entities for system structuring, for , and dynamic creation of instances at runtime. The 1999 release, known as SDL-2000, enhanced the object-oriented paradigm with a comprehensive rewrite to promote modularity, unifying graphical and textual notations, aligning with UML concepts, and supporting hierarchical system decomposition through blocks and processes. Key innovations included polymorphic operations and improved support for real-time extensions, making SDL suitable for larger, distributed systems. SDL-2010, approved in 2011 with subsequent refinements through 2021, further refined the object model by introducing composite states, supervised timers, and clearer semantics for state hierarchies to enhance expressiveness and UML compatibility. It improved integration with programming languages like C by allowing external data type bindings and direct embedding of C code snippets for implementation efficiency. Obsolete features, such as nested diagrams, object data types, and certain UML associations, were removed to streamline the language and reduce complexity without losing core functionality. As of November 2025, SDL-2010 remains the last major update, reflecting the language's maturity. These evolutions shifted SDL from a procedural, protocol-centric tool to an object-oriented language, enabling greater modularity, reusability through , and for complex systems. The absence of post-2010 major revisions underscores SDL's established stability for in and beyond.

Variants and Extensions

SDL with Real-Time Extensions (SDL-RT)

SDL-RT, or Specification and Description Language with Real-Time Extensions, is a variant of SDL designed specifically for modeling real-time and embedded systems by integrating subsets of into SDL's graphical notation. It replaces SDL's native data language with and syntax to enable more efficient handling of complex data manipulations and actions, while maintaining the core behavioral modeling capabilities of SDL. This approach allows developers to embed C expressions directly within SDL transitions and procedures, facilitating the reuse of existing C libraries and legacy code in performance-sensitive environments. Key features of SDL-RT include type-safe embedding of C code, where C variables, pointers, and functions are used in place of SDL's abstract data types, ensuring compatibility with standard C compilers. The language supports seamless code generation to native C, which optimizes execution speed for real-time constraints by avoiding the overhead of SDL's interpretive runtime. Additionally, SDL-RT incorporates real-time primitives such as semaphores for synchronization, while preserving SDL's object-oriented structure for hierarchical system descriptions. Unlike core SDL data types detailed in the data types and structures section, SDL-RT prioritizes concrete C implementations for direct hardware interaction. Development of SDL-RT began in the early through initiatives by tool vendors like PragmaDev, addressing limitations in standard SDL for embedded applications. It was formally incorporated into the standards as Appendix C of Recommendation Z.104 in 2012, defining as an official action language for SDL-2010. This extension has been applied in performance-critical domains, such as mobile telecommunications networks, where rapid response times are essential. SDL-RT offers advantages in faster execution and reduced development time for embedded systems, as the generated code executes directly on target platforms without additional layers. However, it introduces limitations in portability, since reliance on C dialects can vary across compilers and hardware architectures, potentially complicating deployment on non-C environments. Despite these trade-offs, SDL-RT remains fully compliant with SDL's core semantics for and communication, ensuring with standard SDL models.

Integration with Other Languages

SDL integrates with several complementary standards to enhance its capabilities in system specification, particularly for protocol engineering and testing in telecommunications and beyond. One primary integration is with Message Sequence Charts (MSC), defined in ITU-T Recommendation Z.120, which provides a trace language for visualizing communication behaviors and interaction scenarios that complement SDL's focus on structural and behavioral modeling. This pairing allows SDL to define the internal state machines and processes of entities, while MSC captures high-level message exchanges and sequences, enabling a more complete description of system dynamics. For instance, ITU-T Recommendation Z.121 specifies data binding between SDL and MSC, facilitating the alignment of SDL signals and variables with MSC elements for consistent protocol descriptions. Another key integration involves the Testing and Test Control Notation version 3 (TTCN-3), a standardized language for specifying and executing tests on communicating systems, as outlined in ETSI ES 201 873-1. SDL models serve as a foundation for generating TTCN-3 test cases, where SDL's behavioral descriptions are translated into TTCN-3 templates and behaviors to automate of protocol implementations. This integration supports rapid test generation by leveraging SDL's formal semantics to derive test scenarios, reducing manual effort in validation. Additionally, SDL combines with , per Recommendation X.680, for precise data type definitions and encoding rules that ensure interoperability in message exchanges. Recommendation Z.105 details how SDL incorporates ASN.1 modules to specify data structures, enabling automatic encoding/decoding of signals using rules like BER or PER, which is essential for protocol conformance. Mechanisms for these integrations include SDL/MSC profiles standardized by and ETSI for protocol engineering, where combined notations form a unified framework for specifying systems, as seen in ETSI standards like ES 300 414. These profiles define mapping rules to synchronize SDL processes with MSC instances, supporting iterative refinement from high-level scenarios to detailed implementations. Co-simulation environments further enable integration by coupling SDL simulators with other tools, such as for hardware-software co-design; for example, heterogeneous co-simulation links SDL's event-driven simulation to SystemC's cycle-accurate models via gateways that translate signals and synchronize execution timelines. The benefits of these integrations are evident in their division of labor: SDL provides robust structural and , while MSC offers intuitive traces of interactions, improving and validation in complex systems. In software engineering, UML-SDL mappings extend this utility, with structure-preserving transformations from UML state machines and sequence diagrams to SDL processes, as proposed in methodologies that align UML's object-oriented views with SDL's process-oriented paradigm for seamless model evolution. This has been applied in tools that generate SDL from UML models, enhancing reusability across design phases. In modern applications, SDL's integrations find use in SysML extensions for broader , particularly beyond . The AVATAR profile, a real-time extension of SysML, incorporates SDL and UML mappings to support of embedded systems, allowing SysML block definitions to interface with SDL behaviors for modeling cyber-physical interactions in domains like . This approach leverages SDL's precision in reactive systems to augment SysML's architectural focus, facilitating model-based engineering of safety-critical applications.

Applications and Tools

Telecommunications Protocols

The Specification and Description Language (SDL) has been widely used in the of telecommunications protocols, particularly for Signaling System No. 7 (SS7) and . In SS7, SDL facilitated the modeling of protocol layers, including message transfer and signaling connections, to describe and error recovery in public switched telephone networks. For GSM, it supported the development of real-time protocols, such as those for DECT/GSM interworking, by specifying state transitions and message exchanges in mobile switching centers. These applications highlight SDL's strength in capturing complex interactions like call flows, handover , and fault-tolerant error handling, promoting unambiguous designs that mitigate ambiguities in protocol behavior. A prominent case study is the European Telecommunications Standards Institute (ETSI) adoption of SDL for the Intelligent Network Application Part (INAP) in Core INAP Capability Set 2 (CS-2), initiated in 1995 and finalized in 1997 as a normative annex to ITU-T Recommendation Q.1228. This SDL model, developed by ETSI's SPS3 subcommittee, provides a complete, object-oriented specification of INAP functional entities—such as the Service Switching Function (SSF) and Basic Call State Model (BCSM)—detailing interworking for intelligent network services like call routing and service triggering. Similarly, ETSI incorporated SDL in the Customized Applications for Mobile Network Enhanced Logic (CAMEL) Phase 2 specification (GSM 03.78, documented in TS 101 441, 2000), using SDL diagrams to illustrate modifications to GSM call handling in Mobile Switching Centers (MSCs) and GMSCs. These include processes for mobile-originated calls (e.g., CAMEL_OCH_MSC_INIT) and detection points for actions like Continue or Connect, enabling customized services such as roaming control and charging. The formal nature of these SDL specifications yields significant benefits in reducing implementation errors, as verified through and tools that detect issues like deadlocks, signal races, and inconsistent states prior to deployment. For INAP and , this approach streamlined and feature interaction studies, cutting development costs by enabling semi-automated generation compared to manual methods. In practice, SDL's executability allows early validation of protocol behaviors, ensuring reliability in high-stakes telecom environments where errors could lead to service disruptions. Typical workflows in telecommunications leverage SDL from initial specification through to production: behavioral models are created using SDL-96 or later variants, simulated for validation, and then processed by code generators (e.g., translating to C or C++ via tools like legacy Telelogic Tau or ConTraSt) for embedding in hardware like circuit switches, packet switches, or base stations. This direct refinement path minimizes discrepancies between design and runtime behavior, as seen in implementations for ISDN-DECT PBX systems and GSM base stations, where SDL-derived code handles real-time signaling under constrained resources. SDL remains relevant for maintaining and integrating legacy protocols in modern networks, supported by its alignment with ITU-T standards. As of 2025, it continues to be used in domains requiring high reliability, such as embedded systems in and signaling.

Simulation and Verification

Simulation and verification of SDL models involve executing behavioral specifications to detect errors, validate requirements, and ensure system correctness, often leveraging specialized tools that support graphical editing, execution, and analysis. Model allows developers to step through SDL processes and channels interactively, facilitating early of concurrency and communication issues in distributed systems. For instance, SDLPS provides a distributed parallel simulator that executes SDL models across multiple processors, enabling efficient handling of large-scale specifications by partitioning the system into concurrent entities. Historically, commercial tools like (acquired by in 2008 and now legacy, with support archived) offered integrated editing, , and automatic code generation for real-time embedded applications. Current active tools include PragmaDev Studio, which supports SDL-RT for modeling, , and code generation to languages like and Ada, and OpenGEODE, an open-source editor providing graphical editing, , and Ada code generation particularly for space and embedded systems. These tools enable validation through graphical and integration with real-time operating systems (RTOS). Formal verification methods extend simulation by exhaustively checking SDL models for properties like deadlock freedom or timing constraints, often via translation to other formalisms. Model checking with SPIN, for example, involves mapping SDL processes to Promela models, enabling verification of temporal logic properties, particularly in real-time extensions where urgent channels and timers must be preserved. This approach has been applied to reduce state spaces in complex protocols, confirming liveness and safety without exhaustive enumeration. Conformance testing complements these by generating executable test suites in TTCN from SDL specifications, automating the validation of implementation compliance against abstract behaviors derived from MSCs and SDL hierarchies. Tools like Autolink facilitate this by producing TTCN tables that cover transition paths and data constraints, ensuring protocol interoperability in standards like those from ETSI. Advanced techniques include automatic code generation to target languages such as or , which transforms SDL into deployable executables while preserving semantics for performance-critical systems. For real-time applications, performance analysis tools derive quantitative metrics like response times and resource utilization directly from SDL descriptions, using queueing models or traces to predict bottlenecks before . In protocols, such as those for mobile networks, these methods verify timing guarantees under load, often integrating with RTOS for on-target profiling. As of November 2025, open-source and commercial tools like OpenGEODE and PragmaDev's SDL-RT simulators support real-time execution models compatible with RTOS, while integrations with (HPC) frameworks allow parallel simulation of large SDL models on clusters, scaling verification for systems with thousands of processes.

References

  1. https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=z.100
  2. https://sdl-forum.org/languages/sdl.php
  3. https://www.sdl-forum.org/SDL/Overview_of_SDL.pdf
  4. https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Z.100-202106-I%21%21PDF-E&type=items
  5. https://portal.etsi.org/CTI/ApproachToTesting/SpecLanguages/SDL.htm
  6. https://www.itu.int/rec/t-rec-z.100/en
  7. http://sdl-forum.org/sdl2000present/sld002.htm
  8. https://www.itu.int/ITU-T/studygroups/com10/languages/z.100_1199.pdf
  9. https://www.bsc.es/sites/default/files/public/u2416/bsc_-_formal_modelling_with_sdl.pdf
  10. https://www.andrews.edu/~mjody/SDL.doc
  11. https://raw.githubusercontent.com/pixavier/sdl4snap/master/docs/SpecificationAndDescriptionLanguageForDiscreteSimulation.pdf
  12. https://www.itu.int/rec/T-REC-Z.100/en
  13. https://www.sciencedirect.com/science/article/abs/pii/S1389128603002470
  14. https://portal.etsi.org/Services/Centre-for-Testing-Interoperability/ETSI-Approach/Specification-Languages/SDL
  15. http://sdl-forum.org/Events/SAM1998/hogrefe.pdf
  16. https://www.mdpi.com/2073-431X/12/12/244
  17. https://www.pragmadev.com/downloads/Manuals/SDL-RT.pdf
  18. https://www.itu.int/ITU-T/studygroups/com17/languages/Z100.pdf
  19. https://www.itu.int/rec/T-REC-Z.100-202106-I/en
  20. http://www-public.imtbs-tsp.eu/~maag/P7/docs/IntroSDL.pdf
  21. https://www.sdl-forum.org/languages/sdl.php
  22. https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=z.105
  23. https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=z.120
  24. https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=Z.106
  25. https://guminski.net/pg/Z100.pdf
  26. https://www.itu.int/rec/T-REC-Z.100-199911-S/en
  27. http://www.sdl-forum.org/ftp/pub/SDL-2010/SDL2010Background.pdf
  28. https://www.itu.int/rec/t-rec-z.100
  29. https://www.sdl-rt.org/
  30. https://pragmadev.com/news/Z104_EN.pdf
  31. https://www.etsi.org/deliver/etsi_es/201800_201899/20187301/04.07.01_60/es_20187301v040701p.pdf
  32. https://ieeexplore.ieee.org/document/1615229
  33. https://www.researchgate.net/publication/339479895_A_Case_Study_in_Formal_System_Engineering_with_SysML
  34. http://www.itu.int/rec/T-REC-Q.1228
  35. https://www.etsi.org/deliver/etsi_ts/101400_101499/101441/06.07.00_60/ts_101441v060700p.pdf
  36. https://www.nics.uma.es/pub/papers/JavierLopez2005b.pdf
  37. https://www.sdl-forum.org/Events/SAM1998/voegel.pdf
  38. https://core.ac.uk/download/30928563.pdf
  39. https://sdl-forum.org/tools/commercial-tools.php
  40. https://sdlps.com/
  41. https://www.pragmadev.com/
  42. https://github.com/esa/opengeode
  43. https://link.springer.com/chapter/10.1007/3-540-46419-0_25
  44. https://www.sciencedirect.com/science/article/abs/pii/S0140366400002292
  45. https://link.springer.com/chapter/10.1007/978-3-319-49103-5_19
  46. https://www.pragmadev.com/papers.html
Add your contribution
Related Hubs
User Avatar
No comments yet.