Fact-checked by Grok 2 weeks ago

Specification and Description Language

The Specification and Description Language () 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 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 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 systems in (e.g., flight ), 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 practices.

Introduction

Definition and Purpose

(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 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 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 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, 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, for modular subsystems, for concurrent entities, 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;
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 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 transitions in processes and restrictions on instantiating 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 () form the foundational elements for modeling concurrent, systems through extended finite machines and asynchronous communication. These include processes as the primary active entities, signals for , 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 (first-in, first-out) queue to ensure signals are delivered in the order received, preventing race conditions without requiring 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 relies on 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 for later processing, preventing loss while maintaining queue discipline. Spontaneous transitions enable internal changes without external inputs, triggered by timers or procedure calls, providing a 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 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 is constructed by interconnecting blocks via these , forming a static structure that outlines the topological organization without specifying . specifications for blocks include signal lists that enumerate the signals permissible on incoming and outgoing , channel sets that group related channels for collective management, and points that coordinate signal exchanges, such as through remote calls. In object-oriented variants introduced in SDL-2000 and refined in subsequent standards, abstract 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 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 , 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 , 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 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, 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 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 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 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 , , , Real, , 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 /Time managing temporal aspects essential for 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 , , 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 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 . 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 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 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 is defined across multiple levels to support tool , including graphical and textual notations, environments, and 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 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 () 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 concepts, enhancing the language's ability to define data independently of implementation details and to model 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 enabled the description of 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 . 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 Extensions, is a variant of designed specifically for modeling 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 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 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 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 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 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 /MSC profiles standardized by and 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: provides robust structural and , while offers intuitive traces of interactions, improving and validation in complex systems. In , 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 , a extension of SysML, incorporates SDL and UML mappings to support of systems, allowing SysML block definitions to 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 () has been widely used in the of telecommunications , particularly for Signaling System No. 7 (SS7) and . In SS7, SDL facilitated the modeling of 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 , 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 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, '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 systems in and signaling.

Simulation and Verification

Simulation and 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 for applications. Current active tools include PragmaDev Studio, which supports SDL-RT for modeling, , and to languages like and Ada, and OpenGEODE, an open-source editor providing graphical editing, , and Ada particularly for space and systems. These tools enable validation through graphical and with 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 to target languages such as or , which transforms SDL into deployable executables while preserving semantics for performance-critical systems. For 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. [1]
    Z.100 (06/2021) - ITU-T Recommendation database
    Jun 13, 2021 · Recommendation ITU-T Z. 100 introduces the Specification and Description Language, intended for unambiguous specification and description of ...
  2. [2]
    ITU Specification and Description Language - SDL Forum
    Apr 3, 2024 · It is a general purpose description language for communicating systems. The basis for description of behaviour is communicating Extended State Machines.
  3. [3]
    [PDF] Specification and Description Language (SDL)
    SDL is an object-oriented formal language defined by the ITU−T for specification of complex, real-time applications. The strength of. SDL is its ability to ...
  4. [4]
    [PDF] ITU-T Rec. Z.100 (06/2021) Specification and Description Language
    Jun 13, 2021 · FORMAL DESCRIPTION TECHNIQUES (FDT). Specification and Description Language (SDL). Z.100–Z.109. Application of formal description techniques.
  5. [5]
    Specification and Description Language (SDL) - ETSI Portal
    SDL is based on experience within the telecommunications industry in describing systems as communicating state machines. It is developed and maintained by ITU-T ...
  6. [6]
    Z.100 : Specification and Description Language - Overview of SDL-2010
    ### Summary of Specification and Description Language (SDL) from ITU-T Rec. Z.100
  7. [7]
    History of SDL
    The development of SDL arose out of an ITU study started 1968 of the way to handle stored programme control switching systems. The result of this study was to ...
  8. [8]
    [PDF] ITU-T Rec. Z.100 (11/99) Specification and description language ...
    This Recommendation defines SDL (Specification and Description Language) intended for unambiguous specification and description of telecommunications systems.
  9. [9]
    [PDF] simulation models formalization
    □ 1980 Yellow Book SDL. □ Process semantics defined. □ 1984 Red Book SDL. □ ... User guide. □ 1988 Blue Book SDL (SDL-88). □ Effective tools. □ Syntax ...
  10. [10]
    [DOC] SDL.doc - Andrews University
    SDL (Specification and Description Language) was birthed in such a context – the telecommunications industry. Since its inception in 1972 and initial emergence ...Missing: origins | Show results with:origins
  11. [11]
    [PDF] Specification and Description Language for Discrete ... - GitHub
    ITU-T, 1999) (Doldi L., 2003). Additionally, SDL ... In 1980, the Yellow Book, which contained the semantics for the processes, was ... 1999)ITU-TS (2004) or (SDL ...
  12. [12]
    Z.100 : Specification and Description Language - Overview of SDL-2010
    ### Summary of SDL History and Versions
  13. [13]
    The formal semantics of SDL-2000: Status and perspectives
    In November 1999, a new version of SDL, referred to as SDL-2000, was approved by ITU. SDL-2000 incorporates important new features, including object-oriented ...
  14. [14]
    Specification and Description Language (SDL) - ETSI Portal
    SDL is a standardized language used for the description system architecture, behaviour of system components.
  15. [15]
    [PDF] The ETSI SDL model for the Intelligent Network Application Protocol
    This paper describes the development of the ETSI INAP SDL model, one of the first complete and strictly formal. SDL specifications making use of full object ...Missing: adoption | Show results with:adoption
  16. [16]
    Specification and Description Language Models Automatic ... - MDPI
    Nov 5, 2023 · SDL is a graphical language that has been widely used for designing and verifying complex systems, such as telecommunications, embedded systems, ...
  17. [17]
    [PDF] SDL-RT.pdf - PragmaDev
    Sep 20, 2021 · A block symbol is a solid rectangle with its name in it: A simple ... specific graphical symbols are defined to link with SDL graphical ...
  18. [18]
    [PDF] ITU-T Rec. Z.100 (08/2002) Specification and Description Language ...
    SDL Predefined data. D.1 Introduction. Predefined data in SDL are based on abstract data types, which are defined in terms of their abstract properties rather.
  19. [19]
    Specification and Description Language - Overview of SDL-2010 - ITU
    Jun 13, 2021 · Z.100 : Specification and Description Language - Overview of SDL-2010 ; Recommendation Z.100 (06/21). Approved in 2021-06-13. Status : In force ...Missing: architectural elements blocks gates channels
  20. [20]
    [PDF] Introduction to SDL
    SDL (Specification Description Language):. Define and normalized by ITU(-T) (1988, ... gates define, with channels, the signals sent and/or received.
  21. [21]
    https://www.sdl-forum.org/languages/sdl.php
  22. [22]
    Z.120 (02/2011) - ITU-T Recommendation database
    Feb 13, 2011 · MSC may be employed in connection with other specification languages, in particular SDL. In this context, MSCs also provide a basis for the ...Missing: integration | Show results with:integration
  23. [23]
    Z.106 (06/2021) - ITU-T Recommendation database
    Jun 13, 2021 · Recommendation ITU-T Z.106 defines the common interchange format of Specification and Description Language (SDL-CIF).
  24. [24]
    [PDF] ITU-T Recommendation Z.100 - guminski.net
    The ITU-T is responsible for studying technical, operating and tariff questions and issuing. Recommendations on them with a view to standardizing ...<|control11|><|separator|>
  25. [25]
    https://guminski.net/pg/Z100.pdf
  26. [26]
    https://www.itu.int/rec/T-REC-Z.100-199911-S/en
  27. [27]
    [PDF] SDL 2000 Tutorial
    • is completely based on object-orientation. • has a new formal semantics. • is accompanied by a new standard Z.109. SDL-UML-Profil. Page 2. 2. 3. SAM 2000, ...
  28. [28]
    [PDF] SDL-2010: Background, Rationale, and Survey
    Abstract. This invited paper concerns a revised version of the ITU-T. Specification and Description Language standard, which is scheduled to.Missing: architectural elements
  29. [29]
    Specification and Description Language - Overview of SDL-2010 - ITU
    Mar 17, 2023 · Z.100 Annex F2 (06/21), Specification and Description Language - Overview of SDL-2010 - SDL formal definition: Static semantics, In force ; Z.100 ...
  30. [30]
    SDL-RT
    Jan 25, 2010 - ITU-T SDL roadmap for 2010 is to open the standard to other data types paving the way to SDL-RT standardization. Sep 1, 2006 - SDL-RT V2.2 is ...
  31. [31]
    Real Time Developer Studio user's manual - PragmaDev
    Latest version of ITU-T SDL standard to support C language. Paris - France - October 23rd, 2012 - The International Telecomunication Union has officially ...
  32. [32]
    [PDF] ETSI ES 201 873-1 V4.7.1 (2015-06)
    ETSI ES 201 873-1 V4.7.1 is a standard for Methods for Testing and Specification (MTS), specifically the TTCN-3 Core Language.
  33. [33]
    https://www.researchgate.net/publication/339479895_A_Case_Study_in_Formal_System_Engineering_with_SysML
  34. [34]
    A Case Study in Formal System Engineering with SysML
    AVATAR is a real-time extension of SysML supported by the TTool open-source toolkit. ... SDL and UML by means of structure preserving mappings. The core ...
  35. [35]
    https://www.etsi.org/deliver/etsi_ts/101400_101499/101441/06.07.00_60/ts_101441v060700p.pdf
  36. [36]
    https://www.nics.uma.es/pub/papers/JavierLopez2005b.pdf
  37. [37]
    [PDF] ETSI TS 101 441 V6.7.0 (2000-07)
    Procedures for CAMEL. The SDLs in this specification illustrate how CAMEL modifies the normal call handling. They do not attempt to show all the details of ...
  38. [38]
    [PDF] Security protocols analysis: A SDL-based approach - NICS Lab
    Feb 1, 2005 · formal method benefits. These methods characterize the behavior of a system in a precise way and can verify its formal specification. In ...
  39. [39]
    [PDF] SDL based prototyping of ISDN-DECT-PBX switching software
    SDL has been applied as the main tool for specification and implementation of the software, with an emphasis on code generation and rapid prototyping in ...
  40. [40]
    [PDF] Code Generation from Cinderella-SDL to Embedded Platforms
    ConTraSt is a configurable C++ code generator that provides a mapping of SDL specification in. SDL/PR to an object oriented C++ representation. The ...Missing: stations | Show results with:stations
  41. [41]
    [PDF] Use of SDL in European Telecommunication Standards - ETSI
    Dec 27, 1995 · This ETS specifies how to use the ITU-T Recommendation Z.100 [1] SDL in ETSs. The use of SDL diagrams in an ETS and SDL tools in the development ...
  42. [42]
    SDLPS: Home Page
    SDLPS, Specification and Description Language Parallel Simulator. SDLPS is a distributed simulator that allows the definition of the models using SDL language.
  43. [43]
    Telelogic SDL & TTCN Suite product legacy downloads now ... - IBM
    Jun 16, 2018 · Telelogic SDL & TTCN Suite products released prior to Nov.1st, 2008 can now be found on ibm.com resources.
  44. [44]
    Telelogic Tau SDL Suite Helps InterDigital Speed Technology
    Jul 8, 2002 · Telelogic Tau automates and synchronizes embedded real-time application development and testing processes through early requirement and design ...
  45. [45]
    Applying Automated Model Extraction for Simulation and Verification ...
    Mar 21, 2017 · This paper presents semi-automated system abstraction, automated model extraction, simulation, and formal verification of real-life complex SDL ...
  46. [46]
    Model Checking SDL with Spin - SpringerLink
    We present an attempt to use the model checker Spin as a verification engine for SDL, with special emphasis put on the verification of timing properties of ...
  47. [47]
    Rapid generation of functional tests using MSCs, SDL and TTCN
    Doldi et al. [5] assess the combined use of MSCs, SDL, and TTCN for generation of abstract conformance test suites. Their work focuses on conformance testing.
  48. [48]
    Performance Analysis of SDL Systems - SpringerLink
    Dec 9, 2016 · In this paper we present a model-driven approach for performance analysis based on standardized languages. The functional aspects of the system ...
  49. [49]
    OpenGEODE - a free SDL State Machine editor for space ... - GitHub
    OpenGEODE is an open-source SDL editor that is developed for the purpose of providing an easy to use and free state machine editor and Ada code generator to ...
  50. [50]
    Modeling and Testing tools - PragmaDev
    The Specification and Description Language (SDL) modelling technology allows to describe functional models independently from their implementation. This paper ...