n techniques (FDTs), and specifically SDL, has emerged as an interesting way ofdesigning embedded real time distributed systems (ERTDSs) taking into account the increasing complexity ofthis kind of system. The communication platform for these ERTDSs should be included at the design stage inorder to consider the behaviour of the communications. RT-CORBA is an interesting alternative as amiddleware for real-time distributed applications because, unlike standard CORBA, it guarantees predictabletemporal response to invocations to remote objects. We propose a set of design patterns in SDL for the RT-CORBA middleware so that users can integrate the communication behavior into their designs. This approachprovides three important results: firstly, it is possible to carry out the simulation and validation of the wholesystem including communications; secondly, the implementation stage is simplified because the integrationof RT-CORBA allows code to be generated from the design. Finally, different analysis techniques at designlevel for ERTDS including the temporal behavior of RT-CORBA middleware can be carried out. To apply ourproposals we have integrated the design of RT-CORBA with the SDL specification of a distributed controlapplication called Siroco.
Distributed systems are increasingly being applied in critical real-time applications and their complexity forces programmers to usedesign methods which guarantee correctness and increase themaintainability of the products. Object-oriented methodologies arewidely used to cope with complexity in any kind of system [44], butmost of them lack a formal foundation to allow the analysis andverification of designs, which is one of the main requirements fordealing with concurrent and reactive systems. One of the mostimportant advantages of having a formal foundation is the improvedconsistency between the models of the different phases. In this sense,Formal Description Techniques provide the basis for an automateddesign process, allowing simulation, validation and automatic codegeneration from the specifications. One of the most widely used FDTsis SDL (Specification and Description Language).
SDL is an International Telecommunication Union (ITU) standard[16,11] which can be used as a wide spectrum language fromrequirements to implementation. It is suitable for real-time, stimulus–response systems with some semantic limitations. SDL uses a graphicalform with models based on communicating processes defined asextended finite state machines where components can have an objectoriented description. SDL is used as the design language for industrial
applications and it is currently well supported by commercial tools[40,10,28,35,42].
Real-time CORBA (RT-CORBA) middleware [24] has simplified thedevelopment of distributed applications with timing requirements.This specification defines standard middleware characteristics thatallow applications to allocate, schedule and control the CPU, memoryand networking resources necessary to ensure end-to-end quality ofservice support. RT-CORBA greatly influences the temporal behaviourof the systems but it is not included at the design stage.
This paper deals with the integration of the communicationbehaviour at the design stage of the application development whencommunication is carried out by the RT-CORBA middleware. SDL isused for the design of the applications and the communicationmiddleware and allows different analysis to be performed. In addition,we present several design patterns in SDL which can be easily reusedwhen another communication platform or RT-CORBA implementationis applied or when another application is developed.
In order to integrate RT-CORBA into the application design wepropose a framework in SDL of RT-CORBA 1.2. Specifically, we proposea set of SDL design patterns for the different elements of RT-CORBA. Inthis way, developers can join the model of the designed applicationstogether with models of the communication middleware and cancarry out a simulation of the whole system together with differentanalysis of for example the schedulability, deadlock and livenessproperties. These analyses however are not considered in this paper.Instead, we focus only on the design of the models.
Some semantic aspects have to be addressed and integrated intoSDL, such as for example, a priority model or a shared resource
1074 M. Díaz et al. / Computer Standards & Interfaces 31 (2009) 1073–1091
predictable access model. For this reason, we show how to include theRT-CORBA framework taking into account the extensions proposed forSDL in previous works [1] which assured predictability at design level.
Including an RT-CORBA model in SDL allows us to specify thewhole distributed system at the design level and therefore:
• Users can integrate the communication behavior in their designstogether with their applications.
• Different communication platforms can be integrated into the design.• The integration between the RT-CORBA implementation and the SDLgenerated code is simplified thereby reducing the time necessary atthe implementation stage. A correspondence between the designelements and code in the implementation is presented.
• Different analysis can be carried out at the design stage.
In this paper we focus on a set of RT-CORBA characteristics in SDLthat are particularly significant in the context of the real-timedistributed systems:
• The definition of the different RT-CORBA priority models (clientpropagated and server declared).
• Athreadpre-creationmechanism(threadpools) toavoidunpredictability.• Mutexes: synchronization mechanism.• The connection management can be isolated in our approach. Thisway, it is possible to easily change one communication platform foranother at the design phase.
The paper is organized as follows: In the rest of this section somecomments about related work and a summary of the maincharacteristics of RT-CORBA and SDL are described. Additionally wepresent a review of the SDL extensions proposed in previous work.Section 2 presents RT-CORBA in the SDL context to design real-timedistributed applications. Finally, in Section 3we apply our proposals ina real example based on a distributed control application called Siroco[39] developed by Tecnatom S.A. The paper finishes with someconclusions and future lines of work are outlined.
1.1. Related work
Much work has been done on the integration of non-functionaltiming aspects in SDL and the suitability of SDL for the design of real-time systems. In [5] a technique that describes timing constraints isproposed together with a semantic interpretation. In [43] SDL isextended and integratedwith task allocation and schedulability analysisalgorithms. In [7,8] an overview of the main weaknesses of SDL fordeveloping real-time systems is given. Also, in [37,2] limitations of SDLfor modelling aspects of real-time and a set of extensions are presented,and in [15] we can see proposals for the inclusion of timing informationin SDL. As regards supplementing SDL with load and machine modelssuch as those described in [21], a queuing theory is used to calculate jobandmessage queuing times and processor peak and averageworkloads.A further extension of SDL is presented in [38] to describe non-functional requirements. In [12] a new approach for early performancepredictionbasedonMessage SequenceChart (MSC) specified systems inthe context of SDL is presented.
Other lines of research deal with design pattern proposals. A designpattern is an SDL module, which can be used in different contexts fordifferent applications with only minor modifications [22]. SDLpatterns and examples exist for well known protocols [13]. The timingbehaviour of the communication medium for the protocols in SDL isaddressed in [22]. Here, a design pattern is proposed to allow thespecification of a time critical functionality such as multiplexers orQuality-of-Service (QoS) schedulers.
Other works deal with the integration of CORBA and SDL. Forexample, in [27] the use of SDL for efficient service creation isaddressed. In order to provide a generic platform for the implementa-tion of future mobile services, supporting standardized interfaces andplatform independent objects, [20] proposes the mapping of SDL and
CORBA mechanisms. Finally, the Z-130 recommendation of ITU [17]specifies the ITU Extended Object Definition Language (ITU-eODL),which is used for a component-oriented development of distributedsystems. This recommendation includes an IDL-SDL mapping, but RT-CORBA is not considered.
Only a few proposals integrate schedulability analysis and theformal foundation [43]. For example, HRT-HOOD [9] and Octopus [6]support schedulability analysis but lack a formal foundation thatallows the analysis and validation of the systems modelled. In [32,34]we can see how a real-time scheduling theory may be applied to Real-time Object-Oriented Modelling (ROOM). Also, [33] shows howschedulability analysis can be integrated with object-oriented design.
Currently, there are several RT-CORBA implementations available fordifferent languages such as C++ and Java. One of themost popular RT-CORBA implementations for C++ is TAO (The ACE ORB) [19]. TAO isbuilt on top of ACE (the Adaptive Communication Environment) [36], afreely available object-oriented framework that implements many corepatterns for concurrent communication software. TAO is especiallyfocused on the implementation of distributed real-time systems withhard real-time constraints. TAO is robust and widely used in differentkinds of systems. ROFES (Real-Time CORBA for embedded Systems) [18]is another C++ implementation of RT-CORBA especially designed forembedded systems. ROFES not only implements RT-CORBA, it alsoadheres to the minimum CORBA specification [25]. This is a subset ofCORBA designed for systems with limited resources. ROFES is dividedinto several components, which can be dynamically loaded, obtaining avery low memory footprint. Our approach can be applied to bothimplementations. However, due to the simplicity of ROFES, we havefocused our efforts on this implementation.
There are also Java implementations of RT-CORBA. RTZen [31] isimplemented using the Real-Time Specification for Java (RTSJ) [41],because of the unpredictability issues of the standard Java language.RTZen ensures predictability and ease of use by shielding RTSJcomplexities from the middleware user. In [14], the authors presentseveral customization strategies for RTZen in order to reduce thememory footprint and improve overall performance. They introducecomponents and aspects as tools to modularize and present aconditional compilation strategy to customize RTZen for differentapplications. Our work is focused on C++ implementations of RT-CORBA, however it could be easily adapted to this implementation.
Other RT-CORBA implementations are ORBExpress [26] and theOpenFusion approach [29] which includes e⁎ORB, both implementa-tions can be used for C++. The OpenFusion approach also provides aJava version implemented on top of RTSJ. These are commercialimplementations oriented to embedded systems, fast response,predictability, portability, etc., but the source code is not availablefor our analysis purposes and some features included in ORBExpressare not standard.
1.2. Real-time CORBA
CORBA (Common Object Request Broker Architecture) [23] is acommunication middleware that allows the transparent communica-tion of objects developed in different programming languages andrunning on different hosts or operating systems. These objects(servers) define interfaces using the Interface Declaration Language(IDL) of CORBAwith operations provided to the clients, and there is nodifference between invocations to local objects and invocations toremote objects because all the communication details aremanaged byCORBA.
Temporal predictability is one of the main aspects in thedevelopment of real-time applications. However, standard CORBAimplementations are not suitable for real-time because they onlysupport best-effort capacities in the communications and there are noguarantees about the temporal response to particular invocations toremote objects. The solution, then, is to use Object Request Brokers
(ORBs) supporting the Real-time CORBA specification. Real-timeCORBA is an extension of standard CORBA which provides mechan-isms that allow configuration and control of processor, communica-tion and memory resources.
The following points show the main RT-CORBA features:
1.2.1. Native and CORBA prioritiesReal-time CORBA applications can use CORBA priorities that allow
hiding the heterogeneity of native priorities in the different OperatingSystems of a distributed application. RT-CORBA priorities can bespecified with values ranging from 0 to 32,767. These priorities areused in a platform-independent way.
1.2.2. Server declared and client propagated prioritiesTwo different policies are used to transmit priorities. In the server
declared model, the server declares the priorities with which aninvocation on an object will be executed. The client propagated modelallows propagation of the client priorities that must be honored byservers.
1.2.3. Thread poolsThese pools allow the pre-creation of threads in such a way that a
thread manages each invocation on a particular object. In this way,rising costs and the unpredictability of the dynamic creation ofthreads are avoided. Thread pools can contain a set of pre-createdready to use dynamic threads which can be created on demand. Inaddition, thread pools can be created with lanes with differentpriorities, allowing the redistribution of invocations depending onclient priorities.
1.2.4. MutexesRT-CORBA mutexes are the standard RT-CORBA synchronization
mechanism that permits priority inheritance and priority ceilingprotocols if theunderlyingoperating systemsupports them(e.g. POSIX).
1.2.5. Protocol propertiesThe underlying transport protocol used by a particular Object
Request Broker (e.g.: Internet InterORB Protocol (IIOP)–TCP/IP [23])can be configured by RT-CORBA to benefit from special features, suchas ATM virtual circuits, etc.
1.2.6. Managing connectionsExplicit binding and private connections can be used to avoid the
unpredictability related to the implicit activation of objects andmultiplexed connections of standard CORBA ORBs. These mechanismspermit pre-establishing non-multiplexed connections and controllinghow client requests are propagated over these connections.
1.3. SDL
SDL is an object-oriented, graphical specification languageintended to describe the structure, behaviour and data of distributedcommunicating systems. As SDL is a language with a formalfoundation, every symbol has precise semantics; any ambiguity istherefore eliminated and system integrity guaranteed.
SDL semantics is based on Abstract State Machines (ASMs). Finiteversions of ASMs can be seen asfinitemachines extendedwith variablesand timers which run in parallel. Going from one state to another iscalled transition, and this transition takes place only after a stimulus hasbeen received. These machines are independent in the sense that everyprocess has its own data space and there are no shared data. The maincommunicationmechanism is asynchronousmessage passing bymeansof signals. An event is a stimulus (signal sending or time expiration) thatactivates a sequence of transitions to respond to it.
In SDL, systems are described hierarchically at different levels:system, blocks, processes and procedures. The system description is
refined progressively in the subsequent levels. A system is decom-posed into blocks that communicate with each other by means ofchannels. Fig. 1a shows an example of a system. It is composed ofa block called Blck, which receives signal response and sends signalext_ev by means of channel EnvBlck. Fig. 1b shows block Blck. It iscomposed of two processes Proc1 and Proc2. Proc2 receives signalext_ev from the environment and communicates with Proc2 by meansof signal sg1. Finally, proc2 sends signal response to the environment.In SDL-2000, these structuring features (blocks and processes) wereharmonized into an agent concept. This is the static view of thesystem. The dynamic view is described using processes (Fig. 1c),which can run in parallel, and procedures. All data must be local toprocesses, i.e., there is no shared data, a fact which increases therobustness of the system and reduces deficiencies. For example,process proc1 waits for the reception of ext_ev. When it is received aset of tasks can be carried out and the signal sg1 sent. The transitionfinishes blocking in state waiting2.
Timers are the SDL instruments used to deal with a global, abstractnotion of time. They can be set and reset and can expire. When a timerexpires, a signal is sent to the process that set it. This timeout signal isreceived and managed by the process like any other signal. Timersallow developers to simulate time passing before implementation andcan be mapped to operating system timers or hardware timers.
1.4. Extensions for SDL
In order to model real-time aspects of RT-CORBA in SDL wesummarise the proposals from a previous work [4]. The main issue isthe inclusion of the priority concept for transitions. Although someenvironments [40] provide extensions to incorporate priorities intothe processes, this proposal assigns priorities to the transitions of theprocesses. In this case, the process priority depends on the transitionbeing executed at each time instant. Fig. 2 shows how to specify thisextension, by adding a comment symbol with priority x, where x is thepriority level.
This extension is useful to apply real-time analysis at the designstage but it is also necessary to define a new execution model toeliminate the non-determinism from the SDL semantics.
The execution model is based on fixed priority pre-emptivescheduling. As commented previously, it does not assign fixedpriorities directly to processes but to process transitions (using theextension proposed in the previous paragraph). Process priorities canvary from one state to another depending on the transitions that theseprocesses can carry out in the current state (taking into account thequeued signals). Processes are scheduled according to these dynamicpriorities, although the schedulability analysis is based on thetransition priorities, which are fixed. Transitions can be pre-emptedby higher priority ready transitions of other processes, but never by atransition of the same process, i.e., if a process transitionwith a higherpriority becomes ready while another transition of the same process isbeing executed, that transition is delayed until the current one hasfinished. This may cause an increase in the response time of events,but this constraint is necessary in order to maintain SDL processexecution semantics. Processes are therefore pre-emptively scheduledaccording to their dynamic priorities. The model formalization can bestudied in [3].
2. An SDL model for RT-CORBA
In this section we present the SDL design of the main elements ofRT-CORBA, addressing important real-time characteristics such as thepriority models, mutexes and thread pools mentioned in theIntroduction. Firstly, we define the framework applying it to aCORBA model and then we extend it with the RT-CORBA aspects.
It is important to point out that our objective is not to model thefull RT-CORBAmiddleware at low-level detail. This is a difficult job and
Fig. 2. The priority specification.
Fig. 1. SDL basic elements.
1076 M. Díaz et al. / Computer Standards & Interfaces 31 (2009) 1073–1091
one which is not very useful because minor differences betweendifferent RT-CORBA implementations or between versions of the sameimplementation could produce useless models. Instead, we are goingto abstract at a suitable level for our purposes, where the models cancorrespond to the RT-CORBA implementation used and the imple-mentation is correctly represented by the models. If this is not thecase, the simulation results will not be useful. Here, we present a set ofSDL design patterns which can be reused in different RT-CORBA basedapplications and they can be adapted to the specific characteristics ofthese applications.
We have focused our modelling on ROFES, an RT-CORBAimplementation which is suitable for our purposes due to the clarityof the source code related to the ORB itself and the code generated bythis implementation.
2.1. Basic CORBA execution flow
In CORBA applications, communicating objects are located indifferent hosts. Any application can play the role of server or clientdepending on the application requests. In this sectionwe describe thebasic execution flow of a simple client–server application.
In Fig. 3 we can see the basic execution flow between a clientand a CORBA object in a general request of type: result =object-Noperation(args).
The first step for a client invocation is to obtain a reference of thetarget object. This reference can be obtained in different ways (e.g.Naming Service, factories, etc.) and can be performed in the firststages of the application without any penalty for real-time applica-tions. With this reference the client can invoke the target object. To doso, the ORB uses a stub class instance (automatically generateddepending on the IDL interface of the remote object) representing thetarget object in the client address space. This stub has the sameinterface as the remote object. The client application has no knowl-edge of communications and uses the methods provided by the stub,which have the same signature as the remote object. The stub isresponsible for data packaging/unpacking and uses ORB operations totransmit the invocation to the ORB server using an instantiation of theGeneral Inter-ORB Protocol (GIOP) (e.g. IIOP) [23]. This is an abstractprotocol defined by CORBA, which describes the messages to beexchanged between client and server.
In the server address space, the invocation is received by the ORB,which uses information contained in the request to locate the objectadapter (e.g. Portable Object Adapter) associated with the targetobject. Then the object adapter performs the invocation on the targetobject using a skeleton class equivalent to the stub class. If theoperation has output arguments or a return value, the results aretransmitted to the client using the same connection (GIOP connec-tions are bidirectional).
The previously described process used in standard CORBA ORBshas several problems in real-time systems related to temporalunpredictability [30]. The main drawback is related to the responsetime of the request. Standard CORBA ORBs cannot guarantee an upperlimit in the invocation response time. In particular, CORBA does notdefine any connection policy between the server and the client andconnections can be shared with lower priority clients. As a result,higher priority clients may be delayed by lower priority clients,resulting in priority inversions. Additionally, the connection establish-ment time is not bounded and on the server side there may not beavailable resources for the request or it may be delayed by anotherlower priority request.
2.2. Combining RT-CORBA and SDL
Most of the problems of standard CORBA for real-time systems canbe solved by using RT-CORBA, although it lacks real-time analysismethodology and tools. In previous work we have defined extensions,which enable us to perform real-time analysis in SDL systems. Oursolution is based on providing a set of design patterns in SDL ofthe main RT-CORBA elements, which can be used by the user and
combined with the SDL model of the user applications and commu-nication platform. In this way, the whole application can be analyzedat the initial stages of the design and code can even be generated usingthe corresponding tools.
We start modelling a basic RT-CORBA based application composedof a server with a client. This phase is very important because laterdifferent applications can be adapted to this model. In the followingsections, we will present new elements of RT-CORBA and how theseelements are modelled with SDL.
To model a basic CORBA application the following elements shouldbe considered:
• Client application source code: this element corresponds to the logicof the client application without taking communications intoaccount.
• Client ORB source code: this code refers to the stub code generatedby the IDL compiler of the implementation. It depends on the RT-CORBA implementation used and the IDL interface of the remoteobject to be invoked.
• GIOP: different implementations of the GIOP protocol could be used.This element refers to the implementation used to interconnectclient and server.
• Communication platform: this element handles the communicationmethod used to transmit the data (e.g. LAN, wireless, …etc.).
• Server ORB source code: this is the equivalent to the client ORBsource code but on the server side. It contains the code needed toreceive invocations by the remote object, including elements such asthe Portable Object Adapter (POA) which is responsible for catchingthe invocation and retransmitting it to the remote object.
• Server application source code: the remote objects are executed inthe context of a server application. It may contain one or severalremote objects and/or additional execution threads which need tobe modelled.
In view of these elements, we have defined different SDL blocks,interconnected by channels representing the information exchangebetween them. In Fig. 4 we can see the SDL model for a generic CORBAapplication. This model represents a basic CORBA system with oneCORBA object (contained in Apl2) and one client (Apl1). AdditionalSDL blocks represent the elements described such as the client stub(ClientORB) and the server code (ServerORB) including the objectadapter and skeleton.
Generic signals called method1, method2, …, methodn are used inthe figure to represent the methods provided by the interface of theremote object and signals AnswerMethod1, AnswerMethod2, …, Answer-Methodn are used for the responses. In specific applications, thesesignals may be replaced by the name of the interface methods.
The communication platform and GIOP are other SDL blocks. In orderto model the messages of the GIOP protocol, we have used the signals
Fig. 4. RT-CORBA modelled with SDL.
1078 M. Díaz et al. / Computer Standards & Interfaces 31 (2009) 1073–1091
SendMessage/NewMessage to send messages from one object to another,and the signals SendReply/ReceiveMessage to receive the response toprevious messages. Thus, signals such as for example method1 orAnswerMethod1 are “transformed” into these new signals.
The message exchange between the different blocks can bedescribed in the following way:
• Starting an invocation: When an invocation from Apl1 is initiated(e.g. method1), the application sends a method1 signal, which iscaught in the ClientORB block. This block is responsible for datapackaging, sending a signal SendMessage, which represents anequivalent GIOP message for the invocation of method1.
• Invocation transmission: The GIOP block is now responsible for datatransmission between the nodes of the application. In particular, it isresponsible for the interaction with the communication platform(CommunicationPlatform block).
• Receiving an invocation: The invocation is subsequently trans-mitted to the target ServerORB with the SDL signal NewMessage,where the unpacking of the parameters is performed and trans-mitted to Apl2.
• Receiving a response: If the invocation has a response, an inversepath is followed from Apl2 to ServerORB, and from ServerORB
to GIOP with the SendReply signal. This signal is received byClientORB and the response is transmitted to Apl1 through signalAnswerMethod1.
For a specific application we only have to modify some of thegeneric blocks provided using some simple rules, which can befollowed by the user or an automatic tool, thereby obtaining an SDLrepresentation of the system. The modification includes the GIOP
block, which has to be modified according to the RT-CORBA im-plementation used (e.g. ROFES). It also includes the communicationplatform, which will be substituted later by the real ones (e.g. CANIOP[18] or ATM), and blocks ClientORB and ServerORB, which have to beadapted to the real blocks whose code is automatically generated bythe IDL compiler depending on the CORBA interfaces.
We should point out that the user or tool only has to performminor modifications to the proposed basic model, to the stub code orthe name of the methods, while other aspects such as interconnectionbetween blocks, signals, etc. are left unchanged.
In the following subsections we detail the CORBA-SDL mappingprocess and how themain RT-CORBA features (prioritymodels, threadpools, mutexes, etc.) are modelled.
2.3. Modelling an invocation
In this section, a description of the invocation process and thedifferent elements related to it (stub, skeleton, object adapters,etc.) are described. This process is comprised of two sides: theclient and the server side which will be described in the followingsubsections.
Different models could be used to represent the RT-CORBA ap-plications in SDL. However, our purpose is to obtain an abstractionwhich is valid for the code of the applications and which can be usedfor analysis. In this way, we can obtain results at the design phase. Afully-detailed SDL model of the application is out of the scope of thispaper.
2.3.1. Client sideThe process of carrying out an invocation starts with the use of the
stub class. When an invocation of type result = object-Noperation(args) is performed, the developer is in fact using an instance of thestub class which provides the illusion of using the remote object as alocal object.
Let us consider the following CORBA IDL interface:
interface IExample {
void method1();
void method2(in short arg1);
void methodn(in short arg1,out short arg2);
};
Method method1 has no arguments, method method2 has an inputargument and method methodn has an input and an output argument.In the following paragraphs we will use this example to explain thedesign patterns we have presented.
In order to use a remote object implementing this interface, aCORBA clientmust perform several initialization steps. It then declaresan instance of a class representing the remote object, and the client
In this code, the first step initializes the ORB object. Then, theapplication obtains a reference for the remote object implementingthe IExample interface, and finally, a method of this interface(method2) is invoked. It is important to point out that the clientapplication is really using a class named IExample_varwhich is the so-called stub class and which is automatically generated by the IDLcompiler of the RT-CORBA implementation used.
These initial steps are carried out in the client application (e.g. Apl1in the example) and they can be modelled inside the Apl1 blockalthough we are not especially interested (in this paper) in how theyaremodelled, because at our abstraction level we canmodel them likea sequential code block.
In the rest of this section, wewill focus on themodelling of the stubclass where the invocation process is carried out.
The following steps can be identified in the stub class:
• Connection establishment: in this step, a connection with theremote object must be established. The method connection maydiffer depending on the CORBA implementation used.
• Packaging of the parameters: depending on the signature of themethods, different parameters must be packaged in order to betransmitted to the remote object.
• Transmission: the stub class will use additional classes which allowthe transmission of the invocation to the host where the remoteobject is contained.
• Reception of the response: the stub class is blocked until the responseis received.
• Unpacking of the response: depending on the signature of themethods, the output parameters or the return value of the methodmust be unpacked to be transmitted to the application.
The first step towards building a model must be to decide theabstractionmethod used to represent themethods of the interfaces. Inour SDL design model, the interaction between the application andRT-CORBA is performed in the ClientORB block. In this block, we use
an SDL process for each CORBA method of the interface. In this way,when the application performs a request for a remote method, thisrequest is caught by the corresponding SDL process by a signal withthe name of the method.
In the example (Fig. 5) we have processes representing the meth-ods method1, method2 and methodn.
Obviously, it is notmandatory that a stub class be implementedusingprocesses for the different methods of an interface and it could even beargued that it is unrealistic. Nevertheless, we should remember that weare using SDL process, whichmay not necessarily represent processes ofthe operating system. These processes may represent, for instance,threads or simple method calls. Therefore, at this point we useabstraction: CORBA implementations can use single-thread or multi-thread clients. If we consider multi-thread clients, the use of multipleSDL processes for the reception of multiple invocations allows multi-threading to be considered by our model. On the other hand, the use ofsingle-thread clients is a particular case ofmultithreading clients, so thispossibility is also included. The conclusion here is that it does notmatterif processes are really used or not. We are interested in the stepssequence of the stub class in order to carry out a later analysis and wewant our model to cover all the steps followed by the stub class.
The result of the process representing the service is the creation ofa new SDL signal named SendMessage, which is sent outside theClientORB block. The SendMessage signal represents a generic CORBAmessage used by the CORBAGIOP protocol to start new requests and itcontains information about the invocation performed. Finally, it isvery possible that the requests have an associated response. Therefore,the services have to process the ReceiveMessage signal which containsthe response to the request. The response is processed and transferredto the application via another signal (e.g. AnswerMethod1). Now, wehave to model the behaviour of these processes representing theservices. Inside these processes (Service1,…,Servicen) wemodel thedifferent steps described at the beginning of this subsection:connection establishment, parameters packaging, etc., and we haveto delegate the execution of the request to the GIOP block (viaSendMessage signal). Also, we have to process the response to therequest (via ReceiveMessage). Fig. 6 shows one of these services. Theservice process waits for two signals: Method1 and ReceiveMessage.Method1 is received when the application performs a new request. Onthe other hand, ReceiveMessage is received as a response after arequest is transferred to the server.
1080 M. Díaz et al. / Computer Standards & Interfaces 31 (2009) 1073–1091
When a new request is initiated (Method1 received), the stub isresponsible for establishing the connection. Subsequently, the datarelated to the invocation is packaged and finally a new SendMessage
signal is generated, with all the information required for the successfulcompletion of the request.
The services can wait for the ReceiveMessage signal. This signal isreceived as a response to a previous SendMessage. The steps are theopposite to those of the Method1 signal. The response is unpacked andsent to the application via the AnswerMethod1 signal.
We have presented several design patterns for the client side of aCORBA invocation. In order to make, for instance, a real-time analysiswe need to guarantee that the presented model is equivalent to theactual code of the application. The following code shows fragments ofthe stub class automatically generated by ROFES for the methodn of theexample discussed:
• Packaging parameters and transmission_output bb arg1;
• Reception of the responseGIOP::istream_ptr _input=connector-NWaitForReply(_request_id, _reply_status,_start_time, _timeout);
• Unpacking of the response(*_input) NN arg2;
In order to carry out some analysis at this abstraction level, we haveused an SDL design pattern which is equivalent to the code. If weconsider for example real-timeanalysis, this canbe carriedout so longaswe obtain information regarding worst-case execution times (WCETs).
It is not our intention to model methods such as _get_connector orgetOutputStream, but we can measure execution times of thesemethods (and others) in order to perform real-time analysis of theSDL model obtained following the design patterns presented.
2.3.2. Server sideThe server side is more complex. The remote object is contained in
another application which activates this object allowing remote invoca-tions to be received. Additional factors have to be considered such as theobject adapter (POA) and its interaction with skeleton and servant.
As in the case of the client side, some initial steps are necessary inorder to activate a CORBA object. These initial steps are carried out inthe server application (e.g. Apl2 in the example) and cover aspectssuch as the ORB initialization, obtaining the object adapter or objectactivation. They can be modelled inside the Apl2 block. Thesesequential steps are not very relevant for the modelling, becausethey are sequential. The following code shows some of these steps:
// Initialize the ORBCORBA::ORB_var orb=CORBA::ORB_init(argc, argv, qorbq);CORBA::Object_var rtorb_obj=orb-resolve_initial_references
//Activate the ServantPortableServer::ObjectId_var oid = poa-Nactivate_object
(&hello);
From the invocation point of view, the request is received by someentity: a thread or process depending on the RT-CORBA implementa-tion which is responsible for the treatment, execution and response.This is the role of the object adapter, more commonly known as POAfrom Portable Object Adapter. When an application wishes to activatea CORBA object, several steps have to be followed. One of these is thecreation of an object adapter which plays the role of intermediarybetween clients and remote objects. The object adapter is responsiblefor the management of several CORBA objects in the following way:when an invocation is received, the object adapter has to decide(using the information contained in the invocation) which is thetarget object from the set of objects it manages. Then, it uses theskeleton class (automatically generated and depending on the IDLCORBA interface) to execute the invocation, receiving the responseand transmitting it back to the caller.
How can we model this in SDL? Basically, the developer can createas many object adapters as necessary. The creation of one or severalobject adapters is decided by the developer who selects the mostsuitable strategy for the application. So, in the same way as discussedin the case of stub classes, wewill represent object adapters using SDLprocesses which are responsible for the different tasks involved in theserver-side processing. Again, the behaviour of these processes has tobe equivalent to the code of the RT-CORBA implementation used.However, the modelling of these elements can also depend on severalRT-CORBA features which may be selected by the developer. We willdetail this process in later sections.
In the case of the skeleton classes we have to model differentpossible CORBA objects which can receive concurrent invocations andwewill use SDL processes to model these invocations. These processeswill be connected with the object adapters on the one hand and withthe implementation of the CORBA object (the so called servant) on the
other. The following sections will detail the modelling of skeletonprocesses because they depend on some RT-CORBA features.
Fig. 7 shows these elements and the interaction between themwithout considering the implementation of the processes.
The POA waits for NewMessage signals (received from thecommunication platform) which represent new invocations. Subse-quently, it identifies the target object, and transfers the requestto the corresponding skeleton process, which invokes the methodfrom the servant. If the request has an associated response, this istransmitted back to the service process through the SendReplysignal.
2.4. Priority models
One of the main problems of distributed real-time applications isrelated to priorities. The different priority schemes used in differentoperating systems and how the priorities are managed in remoteinvocations may cause difficulties. For the first case, different operatingsystemsmay use different ranges for assigning priorities andmayassigna different number of possible values for priorities. The second problemis related to themanagementof priorities in remote invocations.When alow-priority client carries out an invocation, what priority must thisinvocation have when executed in a high-level priority server? As wehave seen, RT-CORBA provides mechanisms to overcome these draw-backs providing a uniform range of priorities which are transparentlyused by RT-CORBA based applications thanks to the use of the clientpropagated and the server declared models where the developer has toselect themost suitablemodel for the developed application. In the caseof the client propagated model, the developer can have several clientapplications (or threads) invoking methods of different remote objectsand possibly in different servers. If this model is used, the client priorityis the one used during the invocation with all the possibilities that thisbehaviour provides. The second possibility is to use the server declaredmodel where the invocations are executedwith the priority indicated inthe server, so invocations of different clients with different priorities areexecuted with one and the same priority.
The first problem (the heterogeneity of priority schemes) isautomatically hidden by RT-CORBA and we are going to consider itsolved. However, in the latter problem, (management of priorities inremote invocations) the developer has to activate the desired modelusing the so-called RT-CORBA policies. Basically, RT-CORBA providesan Application Programming Interface (API) with the possibility ofcreating different policies which allow the activation or selection of
Fig. 7. The server
different RT-CORBA features. Regarding the priority model used, thedifferences between the twomodels begin in the object adapterwhichqueries the selected model.
2.4.1. Client propagated modelIn this model, the client priority must be kept on the server side.
Basically, when the object adapter receives an invocation, it checks themodel priority used and then carries out the appropriate actions.Before this happens, the developer has to create a CORBA policy toselect this model, as the following code illustrates:
The above code fragment shows the creation of a CORBA policy(poa_policy_list) and a new object adapter (child_poa) which selectsthe client propagatedmodel using the create_priority_model_policy
method provided by RT-CORBA. Subsequently, CORBA objects whichwant to use this priority model have to be activated in this POA as thefollowing example shows:
The above code shows how an instance of a C++ classimplementing a CORBA interface (server_impl) is activated in thedesired object adapter (child_poa) using the method activate_ob-ject. Subsequent invocations on this object will use the prioritymodel of the object adapter, that is, the client propagated model.
We will not discuss in more detail the modelling of the differentmethods presented such as create_priority_model_policy or acti-vate_object, because they can be modelled simply like standardprocedure calls.
Thus, this priority model involves dynamic changes in thepriorities. From the SDL point of view, this priority model has to bemodelled, because it has not been addressed by the previous workscarried out in SDL. Basically, the transitions associated to the different
side blocks.
Fig. 8. The object adapter.
1082 M. Díaz et al. / Computer Standards & Interfaces 31 (2009) 1073–1091
methods of the servant can be executed with different prioritiesdepending on the client.
We have to focus our modelling on the priority changes. How arethose changes carried out in an RT-CORBA implementation? Basically,when the object adapter receives a new invocation, it checks the prioritymodel in use and it changes the priority of the current thread, process orwhatever abstraction is employed. We use a primitive to represent thispriority change. In reality, this primitive represents the equivalentfunction of the operating system responsible for the change or morespecifically, it is equivalent to the attribute Current::the_priority ofRT-CORBA. In this way, we can abstract from the operating system leveland we follow the RT-CORBA programming model.
Thus, we propose a primitive: ThePriority to represent the dynamicpriority change. At the implementation level it can be implemented indifferent ways. However, the primitive represents a priority change ofan SDL transition.
Tasks related to priority model management are carried out bythe object adapter. Fig. 8 shows the SDL process associated to a POA(this process was presented in Fig. 7). The change of the prioritymodel is performed in the POA creation with the procedureCreatePriorityModelPolicy which represents the steps presentedat the beginning of this section. At our design level, we are notinterested in specific implementation issues of this procedure (atmost, we are only interested for instance in the execution times forreal-time analysis). Additional CORBA policies could be created withequivalent methods such as for example multithreading behaviour.
The POA process waits for new messages (invocations). Thesemessages are received via the NewMessage signal from the GIOP block.When these messages arrive, the POA has to unpack the header of the
request in order to obtain some information such as the target object,method to be invoked, priority model used, etc. To do this, theUnpackHeader procedure is used and subsequently, a check of thepriority model, the CheckPriorityModel procedure, must be performedso as to use the most suitable model. In this procedure, ThePriorityprimitive is used if necessary. The next step is the location of the targetobject or skeleton. The target identification is represented with theIdentifyDestination procedure and subsequently, a signal for thetarget skeleton must be generated in order to delegate the requestto it. The POA must choose the target skeleton and generate theappropriate signal. Fig. 9 shows the CheckPriorityModelprocedure. Thisprocedure determines the priority model used: server declared or clientpropagated. If the desired model is the client propagated model, then apriority change happens andwemodel it usingThePrioritywhich is usedto set the priority of the transition extracted from the request(ExtractPriority). The case of the server declared model is differentand is explained later.
Skeletons were modelled with processes waiting for new requestsas presented in Section 2.3.2. Basically, the skeleton is the inter-mediate class which invokes the method on the remote object. So, wehave to model the reception of the invocation and the response. Theskeleton must carry out several steps:
• Method selection: the information of the header is used to select themethod to be executed.
• Unpacking the parameters: depending on the signature of themethods, different parameters must be unpacked (unlike the stubclass) in order to be used in the servant.
• Method execution: the method is executed in the servant using theinput parameters and possibly generates a response in the outputparameters.
• Transmission: the skeleton class will use additional classes whichallow transmission of the response to the host where the client iscontained.
Fig. 10 shows a generic skeleton with two transitions. The firsttransition (Sskeleton) is related to new requests on a servant. When anew request is received, the skeleton has to select the method to beinvoked and unpack the data stream. For this, it uses an unpackingprocedure (e.g. UnpackMethod1). When the arguments have beenextracted, the method of the servant is invoked. Our model uses asignal to represent this action.
Finally, the response in the skeleton is caught by the Result signal.This signal is transmitted by the servant process after the methodexecution. Subsequently, the response is packaged by the Packing
procedure and a new signal is generated for the response: SendReply.This is transmitted to the GIOP block and from the GIOP block to the client.
As in the case of the stub class we must make sure that the modelrepresents the actual code of the application. We have presentedseveral design patterns for the server side of a CORBA invocation. Inorder to make some analysis we need to guarantee that the assumedmodel is equivalent to the real code of the application.
The following code shows fragments of the automatic codegenerated in ROFES for the example we have presented.
Again, if we consider this abstraction level, our SDL design patternis equivalent to the code and we could carry out, for example, a real-time analysis if we obtain information regarding worst-case executiontimes (WCETs).
The last abstraction needed for an invocation is the servant, the realobject which services the invocation. We have modelled these objectsthough SDLprocesses similarly to thewaywe treated stubs and skeletons.Fig. 11 shows an SDL process representing a CORBA object servant. Theservant process has one transition for each method of the CORBAinterface. These transitions use the extension “with priority” of ourmodel, executing the transitions with the previously established priority(server declared or client propagated). The next step is the execution of themethod. As commented, we do not focus on the modelling of theapplications. After the execution of the method, the results of theexecution are sent to the skeleton generating a Result signal.
2.4.2. Server declared modelIn the server declaredmodel, the invocations are executedwith the
priority declared in the server independently of the client priority.This model is covered by the extensions proposed for SDL (i.e. theextension “with priority”). Many aspects of this model are similar towhat was discussed for the client priority model. Thus, in this sectionwe only comment on the main differences.
In this case, when the object adapter receives an invocation andchecks the model priority, the priority remains unchanged, the servantpriority is used (see Fig. 11) and there are no dynamic priority changes.
In our SDLmodel, the difference between the client propagated andthe server declared models occurs in the procedure CheckPriority-Model of the object adapter (Figs. 8 and 9), which checks the prioritymodel used and performs the actions necessary.
There are no other differences between the client propagated modeland the server declared model because if the client propagated modelwere used, the priority would be different in that procedure.
2.5. Multithreaded servers
In the previous section we described the design in SDL of the RT-CORBA priority models without taking into account multithreading or
shared resources. Multithreading is a necessary feature for real-timedistributed systems and the management of shared resources.
Standard CORBA ORBs follow multiple strategies about multi-threading ranging from ignoring it to considering it but leaving to theORB the decision on the number of threads to be created, priorities ofthese threads, etc. RT-CORBA goes further with thread pools. Withthread pools the user can configure the multithreading behaviour ofthe application through the creation of a set of static and dynamicthreads. We are going to perform static analysis, and therefore onlythread pools with a fixed number of threads are considered.
As well as multithreading we have to consider mutual exclusionbetween distributed objects. For this purpose, RT-CORBA providesmutexes, which allow us to obtain mutual exclusion in different partsof the application. In the following subsections, the SDL designpatterns for modeling these issues are described.
2.5.1. Thread poolsIn order to create a thread pool, several methods of the RT-CORBA
API must be used. Thread pools can be configured with static anddynamic threads, lanes, buffering, etc. In our case, we are going tofocus on themodelling of thread pools with static threads because it isthe only configuration we can analyze with our model and it is a verycommon configuration in real-time systems where all the elementsare known at compilation time.
The following code fragment shows how a thread pool can becreated in a CORBA server:
// Create a new POACORBA::PolicyList policy_list(1);policy_list.length(1);policy_list[0]=threadpool_policy;PortableServer::POA_var child_poa =root_poa-Ncreate_POA (qChild_POAq,poa_manager.in(),policy_list);
As we can see, the creation of a thread pool involves several stepsin order to be activated in an object adapter. Basically, the necessarysteps are the creation of a CORBA policy (ThreadpoolPolicy) withthe configuration of the thread pool and the creation of a new objectadapter where the thread pool is activated. After this, the objectshave to be activated in this object adapter in order to be able to usethe capacities of the thread pool (the activation of objects in anobject adapter was discussed in Section 2.4.1). When the activationtakes place, subsequent invocations will be managed by the threadpool. Internally, the creation of the pool causes the desired numberof threads to be created using the primitives provided by theoperating system. It is not our intention to model this, because thisprocedure is the responsibility of the underlying real-time operatingsystem. Instead, we have to focus our efforts on the modelling ofconcurrent invocations. So, we present an SDL design pattern withwhich thread pools can be modelled.
The first steps can be modelled as procedure calls in the serverapplication. From the point of view of the analysis, the only interestingpoints here are the duration of the different steps in order to measureresponse times.
The main part in the modelling of multithreading is related to theserver. We only consider static configurations where the number ofthreads is fixed and known at compilation time, so that we can carryout the analysis later. In this way, we simulate multithreading withSDL processes where each process represents a possible invocation (ina similar way to stubs and skeletons).
On the server side we indicate the maximum number ofsimultaneous requests that a skeleton can have. This is a commonSDL mechanism which allows processes to be replicated and whichperfectly simulates the behaviour of multithreading RT-CORBAapplications. Later, the analysis will take the different processes intoaccount in order to do the system analysis.
Fig. 7 showed the processes associated to skeletons. We can havesimultaneous requests ranging from 1 to n. The SDL model does notneed anything else for multithreading except the blocks, processes,procedures, etc. described in the previous sections.
2.5.2. SynchronizersThe second main issue related to multithreading is the use of
synchronizers in RT-CORBA applications which can also representtypical shared resources of the literature.
RT-CORBA provides a mutex class, providing three operations:lock, unlock and try_lock. The mutexes of RT-CORBA follow aPOSIX semantics which can be modelled with the extensionsproposed for SDL and the implementation depends on the under-lying operating system.
Usually, the developerwill use pairs of lock and unlock primitives toassure themutual exclusion and we have to model them in SDL. Shareddata and resources are encapsulated in a special kindof process. It acts as
Fig. 13. A Siroco cons
a passive server process and only uses remote procedure calls (RPC) asits communication mechanism, i.e. they are always waiting to receiveRPCs from other processes. In this way, in our modelling when the pairlock/unlock is used, the area between this pairmust be encapsulated ina shared resource as described.
ole application.
Fig. 14. Siroco: communication design.
1086 M. Díaz et al. / Computer Standards & Interfaces 31 (2009) 1073–1091
Each of these processes representing a lock/unlock pair has apriority ceiling assigned, which is the maximum number of prioritiesamong all the other process transitions where the resource is beingaccessed. In this way we follow the POSIX semantics used by RT-CORBA, avoiding a possible priority inversion in the data access, andblocking time in shared data access is predictable. Mutual exclusion isalso guaranteed, since all the process transitions will be executed atthe highest priority among all the processes sharing the resource. Thisinformation can be known because we use a static configuration witha fixed number of threads.
Fig. 15. SDL system for th
Let us suppose we have an instance called mutex of the classRTCORBA::Mutex and the following code for the implementation ofmethod1 and methodn in the example:
temp = arg1;mutex-Nlock();// Mutual exclusion zone with other threads using “mutex”arg2 = arg2 + 1; // do something with “arg2”mutex-Nunlock();}
In this code, the method implementation uses the lock operationon mutex obtaining a mutual exclusion zone. Fig. 11 shows themodelling of a servant process, where, the modelling of the methodswas abstracted. In the code above however, we cannot abstract theimplementation of method1 or methodn because we are using a CORBAmutex and so we need to model the use of the lock with a specialprocess. Fig. 12 shows this process which has several transitionsbelonging to the different situations where the mutex can be used(lock_method1 and lock_method2). As we know the clients which are
going to use the methods, we can assign a priority ceiling as indicatedin the label “with priority”.
Thus, we have presented an SDL design pattern where sharedresources work as an abstraction mechanism for the mutexes of RT-CORBA and we can therefore take these elements into account for theanalysis of the applications.
3. Example: the Siroco application
Siroco-Inside is a real time remote control application for inspec-tion systems developed in Tecnatom S.A [39]. The driver design isbased on intelligent hardware with a distributed control, intercon-nected by means of a Tecnatom bus. All In/Out functions areintegrated into this bus:
• Axes control (Encoded, end career sensors, etc…)• Level and temperature sensors.• Peripheral devices, e.g. TV cameras.• Internal variable monitorization.
Siroco-Inside can be operated by means of a console application(See Fig. 13). Several operators and controllers can be interconnectedto obtain a real time distributed control system. Fig.14 shows a generalconfiguration for Siroco. Originally, the communication platform wasan Ethernet network with communications implemented using TCP/IP sockets. We decided to change the implementation of thecommunications, replacing sockets with RT-CORBA. This way, weobtain several benefits. First of all, we can apply the design described
Fig. 18. Behavior for the stub of the speed invocation.
Fig. 19. POA of the Siroco control.
1088 M. Díaz et al. / Computer Standards & Interfaces 31 (2009) 1073–1091
in previous sections. Secondly, we can easily change the communica-tion platform itself. For instance, it is possible to change the Ethernetnetwork for another network type with a better performance orpredictability. Finally, we obtain the interoperability that RT-CORBAprovides and we can connect this application with other systemsbased on other communication systems.
Operators ask for data or send operations such as for example, therobot movements. They go through the network to Siroco Control andit communicates with the hardware. However, some operations suchas the robot movements may be critical. In order to consider thedifferent communication platforms without affecting the Sirocoimplementation, we have integrated them with RT-CORBA.
In this paper we have designed one part of the whole functionality.The following code shows the CORBA interface of the modelled system.We have CORBA objects for the robots and the controllers. The robotsprovide methods for their movements and send information aboutthemselves to theController objects,which additionally providemethodsfor querying information about the position and speed of the robots.
void Speed(in short nrobot,in float speed);void AxialPos(in short nrobot,in float x,in float y);void RotPos(in short nrobot,in float degrees);void GetSpeed(in short nrobot,out float speed);void GetAxialPos(in short nrobot,out float x,out float y);void GetRotPos(in short nrobot,out float degrees);void Go(in short nrobot,in float speed);void Stp(in short nrobot);void Rotate(in short nrobot,in float degrees);
};
As we can see in Fig. 15, two Siroco consoles send and receiverequests to/from the two robots using of the RT-CORBA platform. Eachrequest is analysed by Siroco control in order to send it to the Consoles
or Robots. In this example, the Consoles can send requests to obtainthe robot speed, the axial and rotational position and to control therobot movements (go, stop and rotate). SirocoControl is the serverfor every console request and also stores the robot information such asits position or speed.
Fig. 16 shows the design of clients and servers of the Sirocoapplication necessary to use the RT-CORBA platform. SirocoControl iscomposed of a server part related to storing the robot position andspeed or attending to the console requests, but it also acts as the robotclient. Robots too act both as clients and servers. The design meets theframework defined in Section 2. We have used the server declaredmodel of RT-CORBA, so the requests are carried out with the priorityindicated in the Robots or Controllers. To allow concurrent invocationsfrom the Consoles and Robots, we have also used thread pools takinginto account the number of possible clients. In addition, we have usedRT-CORBA mutexes in some operations to avoid problems, such as forexample robot movement.
Fig. 17 shows the different invocations that have to be made by thestub of the Siroco Console (ClSirococsl1). These services build themessage and then send them through RT-CORBA to the server ofSirocoControl. The stub has been built in accordance with the modeloutlined in section 2.3. The following code shows the stub of themethod Go of IController that was modelled with SDL processes.void IController::Go(CORBA::Short nrobot,CORBA::Float speed){
As we can see in Fig. 18, the remote invocation is packed and sentthrough RT-CORBA to its server. The process will stay in a state wherea response or new invocations can be carried out.
Requests are received by the POA of Siroco Control and the Skeletonanalyses whose method has been invoked (see Fig. 19). In the case ofthe Go, Stp and Rotate requests, Siroco control must send them to therobots (see process ClSirocoCtrl). The rest of the invocations areexecuted in the server and the result is sent to the processes that carryout the invocation.
In Fig. 20 we can see part of the behavior of Skeleton for SirocoControl. The received message is unpacked and analysed before theinvocation is sent to the process that will execute it. This process canbe seen in Fig. 21 and it is responsible for the execution of receivedinvocations. As an example of a skeleton, we show part of the skeletonfor the IController interface:
The above code includes some tasks such as the identification of themethod to be called, the unpacking of the parameters, the invocation ofthe method, and finally the packaging of the response. This codecorresponds to the steps described in the SDL design pattern presented.
The transition priorities are defined in the context of the wholeapplication. These priorities are packed in the RT-CORBA message.This guarantees that when several requests are simultaneous, thehighest priority message (the most critical) will be transmitted.
The integration of the RT-CORBA model into the design stage hasallowed us to isolate the application and to make the communicationplatform independent. Additionally, it allowed the simulation ofdifferent communication systems incorporating them into the GIOP.
This allows the selection and simulation of the best platform thatadapts to the application non-functional requirements.
Aswe have seen in this examplewe can use the framework proposedin Section 2 and integrate it into our designs modifying only the signaland service names. Additionally, from this SDL framework we will beable to generate a model for different analysis at this design phase.
4. Conclusions
From a general point of view the contributions presented in thispaper show the importance of the design stage in the development ofreal-time distributed systems. Specifically, we think that the use offormal description techniques is an interesting alternative. In thiscontext, we have presented an SDL framework to include the RT-CORBA middleware in the designs. In this model we have addressedimportant aspects for real-time applications such as the prioritymodels, access to shared resources and multithreading, as defined inthe RT-CORBA specification.
Finally, our proposals have been applied to an example of a real-time distributed system, allowing us to show that the SDL frameworkfor RT-CORBA can be easily applied.
Although the main real-time characteristics of RT-CORBA havebeen designed in SDL we are extending our model in order to includeother RT-CORBA features such as dynamic thread pools, connectionmanagement or communication protocols. Another line of investiga-tion is related to the development of tools to generate code compatiblewith the RT-CORBA specification.
Acknowledgements
This work is partially supported by the EU funded project SMEPP(www.smepp.org), FP6 IST-5-033563. We would like to acknowledgethe help from the staff of Tecnatom S.A. who contributed to thepreparation of this paper.
References
[1] J.M. Alvarez, M. Díaz, L. Llopis, E. Pimentel, J.M. Troya, Integrating schedulabilityanalysis and SDL in an object-oriented methodology, Proc. 9th SDL Forum.,Montreal, Canada, 1999, pp. 241–256.
[2] J.M. Alvarez, M. Díaz, L. Llopis, E. Pimentel, J.M. Troya, An analyzable executionmodel for SDL for embedded real-time systems, Real-Time Programming 1999,Elsevier, 1999, pp. 117–123.
[3] J.M. Alvarez, M. Díaz, L. Llopis, E. Pimentel, J.M. Troya, An object orientedmethodology for embedded real-time systems, The Computer Journal 46 (n° 2)(2003) 123–145.
[4] J.M. Alvarez, M. Díaz, L. Llopis, E. Pimentel, J.M. Troya, Integrating schedulabilityanalysis and design techniques in SDL, Real-Time Systems 24 (3) (2003) 267–302.
[5] M. Ashour, F. Khendek, T. Le-Ngoc, Formal description of real-time systems usingSDL, Proc. 6th. International Conference on Real-Time Computing Systems andApplications, Hong Kong. China, 1999, pp. 190–.
[6] M. Awad, J. Kuusela, J. Ziegler, Object Oriented Technology for Real-Time Systems,Prentice Hall, 1996.
[7] M. Bozga, S. Graf, A. Kerbrat, L. Mounier, I. Ober, D. Vincent, SDL for real-time: whatis missing, Proc. SDL and MSC (SAM00), Grenoble, France, 2000.
[8] M. Bozga, S. Graf, L. Mounier, I. Ober, J.L. Roux, D. Vincent, Timed extensions forSDL, Proc. 10th SDL Forum, Copenhagen, Denmark, 2001, pp. 223–240.
[9] A. Burns, A. Wellings, HRT-HOOD: A Structured Design Method for Hard Real-TimeAda Systems, Elsevier, 1995.
[10] Cinderella. http://www.cinderella.dk/.[11] L. Doldi, SDL Illustrated — Visually design executable models, 2001.[12] W. Dulz, S. Grughl, L. Kerber, M. Söllner, Early performance prediction of SDL/MSC
specified systems by automatic synthetic code generation, Proc. 9th SDL Forum.,Montreal, Canada, 1999, pp. 457–473.
[13] B. Geppert, R. Gozthein, F. Robler, Configuring communication protocols using SDLpatterns, Proc. 8th SDL Forum, Evry, France, 1997, pp. 523–538.
[14] S. Gorappa, J.A. Colmenares, H. Jafarpour, R. Klefstad, “Tool-based Configuration ofReal-time CORBA Middleware for Embedded Systems”.
[15] S. Graf, Expression of time and duration constraints in SDL, Proc. SDL and MSC(SAM02), Aberystwyth, United Kingdom, 2002.
[16] ITU recommendation Z.100: Specification and Description Language (SDL), 2000.[17] ITU recommendation Z.130: Extended Object Definition Language (eODL), 2005.[18] S. Lankes, A. Jabs, T. Bemmerl, Integration of a CAN-based connection-oriented
communication model into real-time CORBA, Proc. IEEE International Parallel andDistributed Processing Symposium (IPDPS 2003), Nice, France, 2003, p. 121.
blems and on parallel programming and softwareengineering for distributed real-time systems. He hassupervised twenty Ph.D. thesis and published morethan fifty papers in international refereed journals.
M. Díaz et al. / Computer Standards &
[19] D.L. Levine, S. Mungee, D.C. Schmidt, The design of the TAO real-time objectrequest broker, Computer Communications 21 (1998) 294–324.
[20] A. Mahimkar, Modeling of software radio aspects by mapping of SDL and CORBA,Proc. 4th Int. Workshop on Mobile and Wireless Communications Network, 2002,pp. 646–650.
[21] A. Mitschele-Thiel, B. Müller-Clostermann, Performance engineering of SDL/MSCsystems, Tutorial of the 8th SDL Forum, Amsterdam, Netherlands, 1997.
[22] R. Münzenberger, F. Slomka, M. Dörfel, R. Hofmann, A general approach for thespecification of real-time systems with SDL, Proc. 10th SDL Forum, Copenhagen,Denmark, 2001, pp. 203–223.
[23] Object Management Group, The Common Object Request Broker: Architecture andSpecification, 2.6 ed., 2001 December.
[24] Object Management Group, RealTime-CORBA Specification, Version 1.2, formal/05-01-04, 2005.
[25] Object Management Group, Minimum CORBA update, realtime/2004-06-01, 2004.[26] OIS Web Page. http://www.ois.com.[27] A. Olsen, D. Demany, E. Cardoso, F. Lodge, M. Kolberg, M. Björkander, R.O. Sinnott,
The pros and cons of using SDL for creation of distributed services, Proc.Intelligence in Services and Networks, 1999, pp. 342–354.
[28] Pragmadev. http://www.pragmadev.com/.[29] Prism Technologies Web Page. http://www.prismtechnologies.com/.[30] I. Pyarali, D.C. Schmidt, R.K. Cytron, Achieving end-to-end predictability in the TAO
real-time CORBA ORB, Proc. 8th IEEE Real-Time and Embedded Technology andApplications Symposium, USA, 2002, pp. 13–22.
[31] RTZen. UCI-DOC Group. http://doc.ece.uci.edu/rtzen/.[32] M. Saksena, P. Freedman, P. Rodziewicz, Guidelines for automated implementation
of executable object oriented models for real-time embedded control systems,Proc. IEEE Real Time Systems Symposium, San Francisco, USA, 1997, p. 240-.
[33] M. Saksena, A. Ptak, P. Freedman, P. Rodziewicz, Schedulability analysis forautomated implementations of real-time object oriented models, Proc. IEEE RealTime Systems Symposium, Madrid, Spain, 1998, p. 92-.
[34] M. Saksena, P. Karvelas, Designing for schedulability. integrating schedulabilityanalysis with object-oriented design, Proc. IEEE Euromicro Conference on Real-Time Systems, Stockholm, Sweden, 2000, p. 101.
[35] SanDriLa. http://www.sandrila.co.uk/.[36] D.C. Schmidt, ACE: an object-oriented framework for developing distributed
applications, Proceedings of the 6th USENIX C++ Technical Conference, USENIXAssociation, 1994.
[37] R. Sinnott, Real-time systems development with SDL and next generationvalidation tools, Proc. Workshop on Real Time and Embedded Systems, London,United Kingdom, 2001, pp. 3–6.
[38] S. Spitz, F. Slomka, M. Dörfel, SDL⁎— an annotated specification language forengineering multimedia communication, Proc. 6th Open Workshop on HighSpeed, Stuttgart, Germany, 1997.
[39] Tecnatom S.A. http://www.tecnatom.es.[40] Telelogic TAU SDL Manuals, 2004.[41] The Real-Time for Java Expert Group. The Real-Time Specification for Java. http://
www.rtj.org.[42] TIME— The integrate method, http://www.sintef.no/time/.[43] S. Wang, G. Tsai, Specification and timing analysis of real time systems, Real Time
Systems Journal 28 (2004) 69–90.[44] H. Wedde, A. Shaw, J. Zalewski, J.A. De la Puente, C.E. Pereira, J.P. Babau, Panel
discussion: critical issues in object oriented real time systems, Real-Time SystemsJournal, Kluwer Academic Publishers, 2000, pp. 69–99.
Manuel Díaz received his M.S. and Ph.D. degree inComputer Science from the University of Málaga in1990 and 1995, respectively. From 1990 to 1995 hewas an Assistant Professor in the Department ofLanguages and Computer Science of the University ofMálaga. Since 1995 he has been an Associate Professorin the same department. He has worked in the areasof distributed and parallel programming and in real-time systems, especially in the areas of softwareengineering for this kind of system. He has publishedseveral papers in international refereed journals and
representative congresses in the area. Currently, he is
the coordinator of the european project SMEPP: Secure Middleware forEmbedded P2P Systems.
Daniel Garrido received his M.S. and Ph. D. degree inComputer Science from the University of Málaga in1999 and 2006, respectively. From this year he hasworked in different public and private projects relatedto distributed programming, simulation and real-timesystems, especially in the areas of software engineer-
1091Interfaces 31 (2009) 1073–1091
ing. He has published several papers in international
refereed journals and representative congresses in thearea. Since 2007 he is an Assistant Professor in theDepartment of Languages and Computer Science ofthe University of Málaga.
Luis Llopis received his M.S. and Ph.D. degree inComputer Science from the University of Málaga in1995 and 2002, respectively. From 1997 to 2002 he wasan Assistant Professor in the Department of Languagesand Computer Science of the University of Málaga.Since 2002 he has been an Associate Professor in the
same department. He has worked in the area of real- time systems, especially in issues of software engineer-ing for this kind of system. He has published severalpapers in international refereed journals and repre-sentative congresses in the area.
José M. Troya received his M.S. and Ph.D. degrees fromtheUniversity Complutense ofMadrid in 1975 and 1980respectively. From 1980 to 1988 he was an AssociateProfessor in that University, and since 1988 he has beena Full Professor in the Department of Languages andComputing Science of the University of Málaga. He has
worked on parallel algorithms for optimization pro-
