29April 2005

MODEL-BASED DESIGN

Solving problems of SDL and UMLfor real-time software design

� SDL, the “Specification and DescriptionLanguage”, has been defined by the Internation-al Telecommunication Union (ITU) in order todescribe telecommunication protocols. Experi-ence has shown its basic principles could beextended to a lot of other fields mainly becauseof its graphical functional approach allowing todescribe architecture and behaviour of thesystem. But when it comes to implementationand integration on target, the SDL data typesand some of its high level concepts turn into aproblem for the developers because they losecontrol of the final target code. Furthermore,some real-time aspects such as semaphores andpointers, were not covered in the language somost of the SDL developers started to write Cinside the SDL graphical representations. Be-cause there were no tools supporting this com-bination, they had to write their own C codegenerator out of this mix of SDL and C. Allthese problems prevented SDL from beingwidely spread. That is what SDL-RT is solvingwhile it also includes some of the UML trend.

Real-time and embedded software are based onreal-time operating systems or schedulers inwhich the basic structural element is the task.Several tasks execute concurrently in order tofulfil a basic function and these basic functionsare gathered to realize more complex functionsand so on up to the whole application. It ap-peared the SDL architecture gathering tasks in

functional blocks that could themselves begathered in higher level blocks was a good wayto graphically represent the architecture of anyreal-time system. The architecture is then com-pleted with the description of the interfaces be-tween the different functions of the system. Aninterface is defined by an exchange formatbased on structured data, and a scenariodescribing the sequence of exchanges. SDL sig-nals come with typed parameters based on ab-stract data types (ADT) allowing a fulldescription of the static interface. Messagesequence charts (MSC) standardized within thesame ITU series provide a graphicalrepresentation of the dynamic aspect of theinformation exchanged within the system orwith external modules such as drivers.

Real-time systems are based on independenttasks running concurrently, so it is very impor-tant not to waste CPU time whenever the taskhas nothing to do. That led most real-time ap-plications to be based on finite state ma-chines where the basic principle is to wait onan RTOS object such as a message queue assoon as the task has finished its job. Oncemore, the SDL finite state machines werewell-suited to describe that kind of behaviourgraphically. Last but not least, SDL is object-oriented at all graphical levels since its '92 ver-sion so it is possible to build up libraries ofsoftware components that can be specialized.

On paper SDL appears to be an optimized lan-guage for specification and design of real-timesystems, but the technical reality is quite differ-ent. When it comes to design, SDL abstract datatypes (ADT) become a hurdle for several rea-sons. The syntax to manipulate ADTs has beendefined to specify protocols, not to design them.Software designers get into trouble not havingthe precision they used to have with tradition-al programming languages such as C. There areno SDL compilers or cross-compilers on themarket so C or C++ code generation is neces-sary to implement the SDL system on target.ADTs are based on concepts that cannot bedirectly translated in C or C++ so specific op-erators must be generated making the generat-ed code unreadable. Integration of legacy codeis difficult because a bridge needs to be setupbetween the SDL data types and the C or C++data types.

When it comes to integrating the code generat-ed out of an SDL system onto an RTOS, someSDL semantic aspects are not directly support-ed. Let's take two simple examples. The SDLpriority concept applies on messages whileRTOS priority concept applies on tasks. SDL se-mantic considers that an automaton transitioncan-not be interrupted while an RTOS couldactually interrupt execution at any time, espe-cially if system calls occur during the transitioninvolving tasks with different priority levels. In

by Emmanuel Gaudin, PragmaDev

The use of SDL and UMLfor the design of

real-time software isaccompanied by

different problems.SDL-RT benefits from

the maturity of C andSDL but also from the

visibility of UML sothat an SDL-RT-based

tool can solve theseproblems. Figure 1. SDL-RT offers graphical

representation for sending andreceiving messages, as well as takingand freeing semaphores

MODEL-BASED DESIGN

30April 2005

order to guarantee that the generated code be-haves as specified, an SDL virtual machine mustbe generated, making integration on target verytricky and access to some RTOS services almostimpossible. The concept of semaphore does notexist in SDL while it is one of the most classicalsynchronization mechanisms in real-timeapplications. This is due to the fact that SDL hasbeen defined to specify protocols to communi-cate with remote entities so the concept ofsemaphores could not be used.

For all the above reasons and in order to imple-ment systems described in SDL, tools becameextremely complex to manipulate, very expen-sive, and required long training sessions as wellas highly skilled consultants to get the system towork on the target. In the end all the benefits ofusing a graphical language were lost duringintegration on target. The main reason for thatsituation was that tool vendors wanted toabide by the standard whatever the technicalproblems implied.

In the field, SDL users started to write C codeinside their SDL diagrams and broke up theSDL semantic to fit technical reality. But sincethis mix of C and SDL was not supported bythe tools on the market (because not conform-ing to the official standard) these very sameusers developed their own tool chains. The re-sult is that every major telecommunicationmanufacturer has its own internal C codegenerator out of this mix of SDL and C, namelyAlcatel, Nokia, Nortel, EADS and Sagem. Thefirst SDL-RT release aimed at formalizing theindustrial habits of mixing C code within SDLgraphical representations. In order to extendthe usage of such a language to all real-time ap-

plications, SDL-RT also introduced graphicalsymbols to handle semaphores.

The Unified Modelling Language (UML) – asits name states – is a merger of several represen-tations. Its main objective was to document ap-plication and to ease communication among allthe people involved in a software development.Since its first release in 1997, with the help ofstrong marketing, UML has spread quite quick-ly in a large number of areas. This language ischaracterized by its full object-orientedapproach where any element of any system isbasically described as a class. This generic ap-proach provides a very high level of abstractionso that it can be applied to any concept. On theother hand UML is not dedicated to any appli-cation domain and is not precise enough todescribe applications in detail. As a matter offact, it is mostly used during the early analysisor specification phase. The weak link betweenthe UML diagrams and the design raises two re-curring problems: synchronization betweenthe UML documentation and the final code,and a lack of a structuring framework to drivethe development process. These problemscould actually explain the success of UML bythe fact that development teams could actual-ly still work as they used to, and document in-dependently with this language. The benefits ofsuch a usage are very limited and that is whysome large companies have decided to stopmaking UML mandatory.

In the real-time domain only the class diagram,the sequence diagram, and the state chart areused among the nine diagrams available in theversion 1.x of the standard. Since UML tools arebasically drawing tools with very limited codegeneration possibilities, they are much moreaffordable than the ones based on SDL. Thatalso helped the technology to spread.

Several experiences of intensive usage of thelanguage within large development teams even-tually ended in to disaster. From the fact thatthe tools were generating an oversized codewith low performance and no debug on targetfacilities, tools and methods managers raised amajor question: is a full object-oriented ap-proach applicable in the real-time and embed-ded domains where the traditional way isfunctional? Difficult to give a straight answer tosuch a question, but it appears that successfulobject-oriented developments have initiallystarted with a functional approach and thenfactored in components organized in librariesin order to be re-used later. The UML market-ing strength was so strong that SDL had to re-position itself as a graphical modelling lan-guage. The last SDL version, SDL'2000, inte-grated the UML class diagram and paved theway to merge with the next major version ofUML under discussion at the time: UML 2.0.

The main objective of this new version of UMLis to support the MDA (model driven architec-ture) approach in order to define specific pro-files for each application domain. It is alreadypossible to evaluate the status of these lan-guages.

On the SDL side, despite the initial commit-ment of the different tool vendors, the latestversion of the language has not been imple-mented in any tool. Generally speaking, themove towards UML – meaning less precision –did not seduce SDL users because of its com-plexity. The SDL Forum has actually initiated atask force to define a sub-set of SDL to simpli-fy the language, and is – on the other hand –working at defining a UML profile based onSDL. In the field, SDL users are still workingwith the '96 version of the language.

Version 2.0 of SDL-RT has integrated the classdiagram and the deployment diagram fromUML that complement the SDL representationswhile keeping consistency between the differentviews. The (still under validation) version 2 ofUML has integrated existing features fromSDL such as the block diagram into the struc-tural diagram and the MSC into the sequencediagram. It is also possible to define domain-specific profiles but unfortunately there is nostandard real-time profile defined. Major indus-trial companies actually doubt such a profilewill ever be standardized because of the conflictof interests among the different editors who arevoting at the OMG.

Nevertheless the first UML 2 tools are alreadyavailable on the market but the initial objectiveof the new standard to ease portability andreadability is missed since each editor has de-fined its own proprietary profile. These profilesare not public and tools rarely offer a profile ed-

Figure 2. MSC specification example

Interested in more information about SDL-RT, the combination of UML, SDL,and C/C++?

Visit our specific website with links to:

�Technical documentation about SDL-RT �Details about Real Time Developer Studio�Details about MSC Tracer� Information about PragmaDev and its

partners

Simply type-in Reader Service #: 587 at

Embedded-Control-Europe.com/know-how

itor, so in the end there are as many versions ofUML 2 as there are tool vendors on the market.Users will definitely lose from that situationmaking readability and portability moredifficult than before.

Whether the tools are based on SDL or UML,editors had a prophetic attitude regarding theirlanguage and spent a lot of energy to demon-strate through seminars and advertisementsthey were right. It worked out so well that it cre-ated technical fanatics in the industry, so dazzledby the prophecy that they would not hearabout any other technology. Technical realitybrought them back to reason, but at what cost?More thoughtful, such as SDL-RT, are propos-ing pragmatic solutions inspired by the usage in

the industry and wishes from the final userswithout ignoring the current trends. That iswhy they gather some UML diagrams, most ofthe SDL diagrams, and the classical program-ming languages such as C and C++ within aconsistent framework. The objective is to offerall the benefits of the different languages for thereal-time and embedded domain without theirdrawbacks. The diagrams are stored in a pub-lic XML format in order to be able to re-use theinformation without any specialised tool. Apartfrom the language it is, of course, the quality ofthe tool that will convince the end users sincethe objective of a development team is not toconform to a standard but to efficiently pro-duce software with the best level of quality andperformance. �

Figure 3. Version 2.0 of SDL-RT gathers UML diagrams and ensures consistence