high requirements in terms of fault tolerance, stability, and reliability. But with conventional RAD tools, developers are more concerned with what the program does than they are with how it does it.
Increased time-to-market pressure and reduced product life cycles, especially in the telecommunications industry, make life even tougher for engineers. Additionally, a medium-size telecommunications project contains up to a million lines of C code and involves a higher degree of collaboration than other programming areas.
Applications in the telecommunications field are typically distributed. Think of a telephone exchange that handles hundreds of subscribers simultaneously. The exchange routes the call, checks the time spent on the call, and passes that information to a database for later billing. This happens 24 hours a day with thousands of connections each day and means constant interaction among a multitude of small software components.
The higher levels of regulation tha
t are being imposed on real-time software developers, such as ISO 9001 certification and various governmental or military specifications, recognize these high requirements. Consequently, RAD in such an environment demands a graphical language that lets designers define unequivocally the interaction of components and the signal flow between components. Additionally, to reduce development cycles, a sufficient RAD tool for real-time development has to provide facilities for component reuse.
SDL is a formal language that lets designers model communicating finite-state machines. A system described by a finite-state machine consists of processes, signals, and channels. SDL adds data processing to this model so that a state transition can also perform computations on data stored in variables, thus combining systems design and a visual approach to programming.
SDL has its origin in the telecommunications area and has been especially embraced by this industry. Much of the research work on this formal langu
age has been carried out in the labs of the Danish telecommunications company, TeleDanmark, Swedish Telecom, and Telia Research in Sweden. The international telecommunications standards body accepted SDL in 1976; several major enhancements have been added since then. For example, SDL-84 introduced abstract data types, and the SDL-92 standard added object-oriented features.
The two major vendors of SDL-based tools in Europe are Telelogic (Malmö, Sweden) and Verilog (Bagneux Cedex, France). Both firms sell suites of tools that let users analyze and design systems graphically as a series of charts, verify the correctness of these diagrams, and automatically generate C code. These tools are being used in companies that span the telecommunications, aerospace, defense, and automotive industries to develop products as diverse as factory automation systems, PBXes, and artificial kidneys.
SDL design tools can simulate the functioning of a system. They can detect ambiguities in the design because SDL i
s a formal method that ensures each modeled system is consistent and unambiguous. Any ambiguity is detectable as an error.
Message Sequence Charts
The design tools from Telelogic and Verilog use so-called Message Sequence Charts (MSCs) to describe the interaction of the major components of a system. The term is defined by the International Telecommunications Union in its recommendation Z.120. An MSC shows the sequences of messages sent between the components in an easily readable form, with the components arranged as vertical columns and the messages as horizontal rows joining the columns. The time axis is vertical. In some representations, you may see MSC diagrams with the time axis running horizontally; rotating the chart in this way represents no fundamental difference in notation.
MSC is useful in several phases of the specification of an interactive real-time system. Designers use MSC at the very beginning of a project as a notation to capture the user's requirements. A p
lain-English dialogue of the sort, "I press the button; then the red light comes on; then I swipe my card through the slot; then my ID number appears on the LCD screen," will translate directly into an MSC diagram, and the notation is sufficiently transparent for even nontechnical users to be able to read it back and see that it represents the interaction they were describing. Because external agents appear as just another column, one of the strengths of MSC is its ability to describe interactions with the outside environment as easily as it describes ones that take place between system components.
At a later stage in the specification process, MSC is an equally suitable notation for describing the output of simulation runs of an SDL specification -- what SDL calls a signal maps into a message in an MSC. As with SDL, there is a textual representation for MSC as well as a graphical chart form. The textual representation is a list of events, described in a formal syntax, such as:
i3:out m1,5(p
1,p2) to i2
SDT and Itex
Telelogic's SDL Design Tool (SDT) 3.0 runs on Sun, Hewlett-Packard, Digital Equipment, and IBM workstations, and, since late last year, on Windows PCs. The SDT suite
contains graphical SDL and MSC editors
, which allow you to build diagrams on-screen by dragging and dropping symbols from a toolbox. The editors perform automatic syntax checking to prevent users from creating illegally formed diagrams.
SDT development
proceeds through four stages
: requirement analysis, specification, verification, and validation. In the requirement stage, designers analyze the required interactive behavior of a system and build an MSC that captures the user interaction. Specification involves building an SDL diagram of the blocks and processes that describe the system. In addition to its built-in syntax checking, the SDL editor of SDT supports templates to mechanize the drawing of commonly used subsystems. A signal di
ctionary eliminates mistakes when depicting signals.
The hierarchically organized SDL editor allows users to drill into the structure of a diagram by clicking on blocks to reveal the internal details. A graphical Organizer utility maintains links between objects in the editor and the disk files that store them, while the Type Viewer is a browser for the inheritance tree of SDL objects.
At the verification stage, SDT checks the SDL diagram and detects both syntactic and semantic errors, which can then be corrected interactively. Once the system has passed validation, you can generate C or Chill (a specialized language for real-time development) code and run this on the Simulator, which may reveal run-time logic errors that escaped the validation phase.
The Simulator behaves somewhat like an interactive SDL debugger, including the tracing, breakpoints, and logging. You can visualize the Simulator's output trace as an MSC and then directly compare it with the chart that describes the original s
pecification.
Finally, the Validator automatically looks for deadlocks, race conditions, and data-processing errors, and it checks for consistency between MSCs and SDL diagrams. Completely testing a complex system could involve traversing an exponentially exploding tree of potential transitions, but the Validator uses a clever approximation algorithm to test only the major transitions.
Telelogic also offers an advanced testing tool called Itex, which generates test suites from an SDL description produced in SDT. Itex uses the ISO-standard Tree and Tabular Combined Notation (TTCN) language and works through a similar four-stage process. The result is C-coded test suites that are independent of both the target system and the application. This means that the generated code suits any test equipment supporting C.
ObjectGeode Supports OMT
Verilog's ObjectGeode suite for IBM, HP, and Sun workstations performs functions similar to SDT's. It, too, contains graphical SDL and MSC e
ditors, a simulator for prototyping and validating, and a TTCN test-suite generator. The most significant difference lies in ObjectGeode's support of the Object Modeling Technique (OMT) -- popularized by Rumbaugh -- for analyzing processes in object-oriented terms. Though Telelogic has announced that the next version of SDT (3.1, due for release by the end of the year) will contain an SDL-oriented OMT, that feature is not included in the current version.
The analysis phase of an ObjectGeode project consists of building an OMT model of the system, using the built-in OMT Class Diagram Editor. An OMT Instance Diagram illustrates the relations between diagrams. The user-defined system requirement translates directly into MSC diagrams.
The development phases under ObjectGeode involve building the SDL Hierarchy and Interconnection diagrams and verifying, simulating, and validating them. Finally, ObjectGeode generates C code from the SDL parts of the design and C++ code from the OMT part. As with SDT, th
e code produced from ObjectGeode is independent of the target hardware and must be linked to libraries -- supplied with the software -- to support particular real-time environments like VRTX, VxWorks, pSOS+, and OSE.
Formal methods such as SDL have a bad reputation among programmers, as tools that look good on paper but fail to deliver in the real world. Because SDL is being used with great success in a variety of real-time, commercial applications and especially in the booming telecommunications sector, that attitude may change.
Swedish telephone giant Ericsson, for example, used an SDL tool to develop the software for its cellular GSM Base Station. According to Ericsson's project leader, Ulf Slunga, it proved necessary to write only a few parts of the project, the low-level hardware interfaces, in C directly. This represents 30,000 lines of a 225,000-line project. Slunga says, "We estimate that using SDL improved our code productivity by around 60 percent. The improvement in code quality and tes
tability was probably even greater."
SDL is a visual concept of systems design that works on a high abstraction level. The advantages of SDL-based tools lie in the reusability of logical parts of the design and easier maintenance of an SDL development project.
Another plus is that a project in SDL doesn't need any extra documentation, because systems design in SDL is the documentation itself. This is something programmers will like.
PRODUCT INFORMATION
Itex.......................about US $10,000
(Price includes the complete suite and targeting tools)
SDT........................about US $25,000 per seat
(10-user license)
Telelogic AB
Malmö, Sweden
Phone: +46 40 17 47 00
Fax: +46 40 17 47 47
E-Mail:
info@telelogic.se
Internet:
http://www.telelogic.se/
Circle 976 on Inquiry Card.
RAD for Real-Time Apps
