Control Engineering Practice 6 (1998) 409—416

Timing analysis of a generic robot teleoperationsoftware architecture

Barbara Alvarez, Alejandro Alonso*, Juan A. de la Puente

Universidad Politecnica de Madrid, Dpto. Ingenierı&a de Sistemas Telematicos. Ciudad Universitaria s/n., E-28040 Madrid, Spain

Received October 1997; in revised form November 1997

Abstract

The development of generic software architectures for specific application domains is an effective way of reusing software. This wasone of the aims in the development of an architecture for teleoperating robots, which can be adapted to deal with different jobs,operational environments and robots. However these kinds of systems have timing requirements. The purpose of this paper is to presenta characterization of this architecture, for an analysis of its timing properties using the Rate Monotonic Analysis method. In this waya generic architecture, and a method of checking its timing properties, are provided. ( 1998 Elsevier Science Ltd. All rights reserved.

Keywords: Real-time systems, software architectures, robot control, teleoperation, software engineering

1. Introduction

The correctness of real-time systems depends not onlyon the computational results, but also on the time atwhich outputs are generated. Hence, when developinga real-time system, it is necessary to check that its timingrequirements are fulfilled. This makes its developmentmore complex.

Furthermore, the complexity of current computer sys-tems is increasing. The reuse of software (designs, codeand documentation) is a way of dealing with this prob-lem. An efficient way of reusing software is the develop-ment of generic software architectures for specificapplication domains. In this area, a reference architecturefor teleoperation systems has been proposed, which canbe adapted to deal with different jobs, operational envi-ronments and even robots (Alonso et al., 1997). In orderto achieve this purpose, the stages of the domain-engin-eering process have been applied. Domain-engineeringprocess defines the activities to build a common softwarecore for a family of systems (Withey, 1994). This was theapproach taken here, in the development of the genericsoftware architecture for robot teleoperation systems(Alonso et al., 1997).

*Corresponding author. Fax: #34-1-336 7333; e-mail:alonso@dit.upm.es

In robot teleoperation systems, the timing re-quirements should be met, in order to ensure that theinformation that the operator receives is valid, and re-flects the current state of the robot. Therefore, the systemmust respond to external stimuli; the response dependsnot only on the stimulus itself, but also on what haspreviously happened in the system. These characteristicsare typical of a real-time system (Hassan Gomaa, 1989).Hence, when evaluating the feasibility of the architecturefor a particular application, it is necessary to check, notonly that the appropriate functions are included butthat the timing requirements are fulfilled as well. Themeasures of merit in a real-time system include:

f Predictably fast response to urgent events.f A high degree of schedulability. Schedulability is the

degree of resource utilization, at or below which thetiming requirements of tasks can be ensured.

f Stability under transient overload. When the system isoverloaded by events, and it becomes impossible tomeet all the deadlines, the deadlines of selected criticaltasks must be guaranteed.

The Rate Monotonic Scheduling (RMS) theory (Liuand Ayland, 1973) ensures that as long as the CPUutilization of all tasks lies below a certain bound andappropriate scheduling algorithms are used, all tasks willmeet their deadlines without the programmer knowingexactly when any given task will be running. Even if

0967-0661/98/$19.00 ( 1998 Elsevier Science Ltd. All rights reservedPII S 0 9 6 7 - 0 6 6 1 ( 9 8 ) 0 0 0 1 7 - 3

Fig. 2. High-level description of the architecture.

a transient overload occurs, a fixed subset of critical taskswill still meet their deadlines, as long as their CPU utiliz-ations lie within the appropriate bound. The Rate Mono-tonic Analysis (RMA) method is based on this theory.

In general, the proposed reference architecture can beported to any platform, and can be executed on anyoperating system that is not necessarily a real-time oper-ating system. However, the timing behavior of the systemcan be analysed using the Rate Monotonic Analysis(RMA) method (Sha and Goodenough, 1991) if certainconditions are met. The most important conditions arethe following ones:

f A real-time operating system is used, and task schedul-ing is based on fixed priorities and preemptive schedul-ing (Sha et al., 1986). The priorities of tasks are fixed inthe sense that they do not vary from one event to thenext, and the scheduling is preemptive because if a high-er-priority task becomes eligible to run, a lower-prioritytask will be preempted from using the processor.

f Inter-task communication is based on a suitable proto-col, such as the priority ceiling protocol, for boundingpriority inversion (Sha et al., 1987). The priority ceilingprotocol guarantees that a high-priority task will beblocked by any lower-priority task for a bounded time.

The rate monotonic scheduling theory allows the de-signers to reason with confidence about timing correct-ness at the tasking level of abstraction, and it analyseswhether the deadlines of the tasks can be guaranteed. Inthis way, a generic architecture, with a framework foranalysing its timing response, is proposed. This is pro-vided by identifying the sequences of events, actions and

Fig. 1. Scheme of the system.

resources in the architecture, following RMA (Kleinet al., 1993). In this way, the designer of a new applicationcan reuse the architecture, and can easily check to seewhether the architecture can meet the timing require-ments, by providing the specific timing requirements ofthe particular application, as well as the computationtime of the activities in the target platform if the aboveconditions hold.

1.1. System description

A schematic view of the components of the system isshown in Fig. 1. The operator is in charge of monitoringand operating the robot according to the informationprovided by the teleoperation system. This system re-ceives commands from the operator, and performs thecorresponding actions required to execute them. For thispurpose, it communicates with the robot control unit(ROC), which physically actuates the robot to move it.The robot control unit senses some information from therobot in order to evaluate its global state. It then sendsthis information to the teleoperation system, which usesit to represent the state of the robot graphically to theoperator, and to ensure the correctness of its behaviour.

410 B. A!lvarez et al. /Control Engineering Practice 6 (1998) 409—416

Different tools are attached to the robot to perform themaintenance operations. The tools are operated in a sim-ilar way to the robot.

At the system requirements analysis phase, the func-tional and non-functional requirements are defined(Hassan Gomaa, 1989). The high-level design of thearchitecture is shown in Fig. 2. The design was based onan analysis of the system functionality. The controllersinteract with the following subsystems:

f Graphical representation: This subsystem is in charge ofdrawing the environment in which the robot is operat-ing, as well as the robot itself. The application can beadapted to work with other robots and tools, in differ-ent environments. The robot controller module requestsa service, and the status of the operation is returned.

f Collision detection: This server provides the systemwith operations for checking if a given movement com-mand will imply a collision between the robot and theoperating environment, or with itself.

f User Interface: This is in charge of interacting with theuser. It allows him to issue the desired command to therobot, and to show the status of its execution.

f Communications: This embodies the communicationprotocol with the ROC computer. This module returnsthe received status from robot control unit.

2. Process model

The development of the teleoperation architecture hasbeen based on the 4#1 views model (Krutchen, 1995). Ituses different system descriptions in order to contemplateall the important aspects. In this paper, the processmodel is presented, which is the most important one inanalysing the timing requirements of the proposed soft-ware architecture.

Fig. 3 shows the process model of the robot controller.This model describes the task structure, which is basedon the fact that it is not desirable for the controller to beblocked for any reason, because it is in charge of execut-ing the main system functions, in particular, for safestopping procedures in case of severe errors. For thisreason, several tasks have been allocated for communica-tion with each of the other subsystems, thereby decoup-ling the controller task from having to interact directlywith the other subsystems. A queue for storing the eventsin a prioritized order is used by the other tasks, to reportthe results of the interactions with the other subsystems.

The tool-controller subsystem was the first example ofreuse within this project. The tools are handled as if theywere a more simpler and more specialized robot. In thisway, the tool controller shares the same structure andcode as the robot controller. With respect to Fig. 3, theonly modification when adding the tool controller is theneed to synchronize the two controllers. The rest of this

Fig. 3. System process model.

paper concentrates on identifying the RMA model of therobot controller; the other controller model is exactly thesame.

In the controllers, the task that receives messages fromthe ROC (t5) is periodic, because the robot status in-formation is sent periodically from the robot control unit(ROC). When this task is activated, an order to obtainthis information is sent to the communication module.This information is processed, and the results are sentback to the controller buffer to be processed by therobot—controller task.

A task for sending messages to the robot control unit(t4) is activated sporadically by the robot controller. TheROC accepts commands with a minimum separationtime between them. In addition, the system does notallow a request for a command, before the previous onehas been handled. The only exception to this rule is anemergency stop for the robot.

The controller buffer (s5) is a shared resource, and isbased on the priority ceiling protocol. Hence, its priorityis immediately higher than the highest-priority client.Therefore, the maximum time for which a task can beblocked by a lower-priority task is the duration of the

B. A!lvarez et al. /Control Engineering Practice 6 (1998) 409—416 411

largest critical region. In this case, the highest priorityclient is the robot controller.

When the robot controller receives a status message, itsends a request to the graphic representation module (s2)through Graphics—Data—Processing task (t2), in order topresent the current robot status to the user.

The syntactical and lexical analysis of the operatorcommands is performed by the user interface sub-system. If a command is correct, it is sent to theUser—Data—Processing (t3). This task periodically checksthe commands from user, and it sends them to the con-troller buffer (s5), to be handled.

If the user’s command is a robot motion command, therobot controller requests a service from the collisionsdetection server (s1), to ensure that there will be nocollisions with the environment. If this check is success-ful, the command is sent to the robot. The server (s1)spends some computation time on calculating the robotkinematics.

The Kinematic—Data—Processing (t1) and Graphi-cal—Data—Processing (t2) are activated sporadically, andtheir priorities depend on the timing requirements of theassociated motion request.

In the next section, the RMA method is applied, andthe sequences of events, actions, and resources in thesystem are identified. In this way, it is possible to predictthe worst-case response for each of the meaningful sys-tem events.

3. System model for timing analysis

Rate Monotonic Analysis (Klein et al., 1993) is basedon an identification of the system events and the asso-ciated actions, to draw conclusions about the timingbehaviour of the real-time system. An event occurs whenthe system or environment state changes. Since an eventcan occur repeatedly, RMA refers to the recurrence ofevents as an event sequence, and a computation that isperformed as a consequence of a event is genericallyreferred to as the response to the event. An event se-quence is classified by its type, which is based on itsorigin. Events can originate outside the system, inside thesystem, or because of the passage of time:

f An external event sequence (environment events) ap-pears when a change occurs in the environment; forexample, a key depression from a console, or a messagefrom another computer.

f An internal event sequence appears when a change isdetected in the system; for example, when an alarm isdetected as a result of the processing of data; or whena tracking algorithm predicts a collision between therobot and its environment.

f A timed event sequence occurs when the event is gene-rated by a system clock. For example, controlling the

temperature of a reactor may require that the temper-ature be sensed regularly, after a certain time.

Event sequence arrivals are characterized by theirarrival pattern, and by the mode of the system duringwhich the events can occur. The arrival pattern andmodes of an event sequence are important because theyidentify when the event will be competing for resources.For a particular event sequence, it is critical to be able tocharacterize the event’s pattern of occurrence as a func-tion of time. This is called the arrival pattern, in the RMAmethod.

In general, there are three parameters that characterizethe timing behaviour of robot teleoperation systems: (1)The minimum separation for the sending of commandsto the robot unit control (ROC), (2) the minimum separ-ation between user commands, and (3) the robot statusinformation, which is sent periodically from the ROC. Inthis work, these general parameters are illustrated fora specific product.

The controller task is the most critical one. It is incharge of handling system events. A queue is used forstoring the messages associated with the events that thecontroller receives from other subsystems. In this way itis possible to handle the events on the basis of theirpriority. Whenever a new message is inserted in thequeue, the event Proc—Message is raised. It is necessaryto bound the maximum number of these events that canoccur in a certain interval of time, in order to be able toanalyse the timing requirements.

If the next event can occur arbitrarily close to a pre-vious event, but the number of events over a specifiedperiod of time is restricted, then the event arrival patternis called ‘‘bursty’’ in the RMA method. Bursty arrivalpatterns are characterized by the length of time overwhich the burst restriction applies, and the number ofevents that can occur during that duration of time. In thecase described here, there is a limit to the number ofevents that can be generated between the generation oftwo messages to the ROC (60 ms)1. The events that thecontroller can receive during this time are as follows:

f Status—msg; a new status message has been receivedfrom the ROC.

f Command—msg; a command has been introduced bythe operator.

f Kin—msg; a result of the operation for calculating colli-sions detection is returned to the controller.

f Graphics—msg; a result of the operation for updatinggraphical representation is returned to the controller.

f Error—msg; an error message indicates to the controllera failure in sending to the ROC.

1For purposes of illustration, the timing requirements of the productdevelopment for performing maintenance operations in the bowl ofa steam generator are included.

412 B. A!lvarez et al. /Control Engineering Practice 6 (1998) 409—416

f Sync—msg; a synchronization message from tool (robot)controller is received by the robot (tool) controller. Thesynchronization between the robot and tool controllersis required because some tool (robot) operations canonly be done when the robot (tool) is in a certain state;for example, the loading and unloading of tools.

The generation of these kinds of messages by the robotcontroller implies the generation of new ones, to activateappropriate activities in the rest of the subsystems. Theseinternal events are as follows:

f Send—User: The user interface must be updated. Anyaction to control the robot is limited by the time ofreception of commands in the ROC (60 ms). Therefore,a higher frequency for updating the user interface is notnecessary.

f Send—Command: A command must be sent to theROC. The minimum separation time between two suchmessages to the ROC is 60 ms.

f Coll—Operation: A motion command has been re-ceived, and the controller checks its feasibility byrequiring this service from the Collision Detectionmodule. The minimum separation time between twocommands of motion is 2s, which is the highest periodfor the operator to send commands to the robot.

f Graphical—Update: A new robot position must be up-dated in the screen. This event is generated when a newrobot status is received; therefore it occurs with a min-imum separation time equal to 250 ms.

f Automatic—Action: The controller decides to executean action as a consequence of the current state of thesystem. Any action to control the robot is limited bythe minimum separation time between commands thatthe ROC can receive (60 ms).

When a change is detected in the environment, thefollowing events can be generated:

f Capt—Status: A status message is received periodicallyfrom the ROC. The period of reception is 250 ms.

f Capt—Command: A task periodically checks the intro-duction of commands by the operator. The period ofreception is 2s.

Every event sequence has an associated response. A re-sponse is the computational work that must be per-formed as a consequence of the occurrence of an event.An action is the smallest decomposition of a response. Inthis way, a response consist of an ordered collection ofactions and lower-level responses. In the following nextsections, the sequences of actions that are executed forhandling system events are described.

3.1. Sequence for capturing robot status

Description. This sequence handles the Capt—Statusevent. It is initiated by the timer of the reception

messages task (t5), and it finishes when a robot statusmessage is inserted in the controller buffer (s5). Whenthe events arrive at constant intervals, they have anarrival pattern that is described as periodic in the RMAmethod.

¹ype. External, periodic.Response. a5.1 P a5.2 P a5.3a5.1: This action is executed by the communications

module, to obtain the robot status from the ROC.a5.2: The received status is converted to a controller

message.a5.3: The message is inserted in the controller buffer

3.2. Sequence for handling user commands

Description. This sequence is executed when the oper-ator issues a command (Capt—Command event). Its anaperiodic sequence, but the minimum separation be-tween commands is fixed and limited. This event arrivalpattern is called ‘‘bounded’’ in the RMA method.

¹ype. External, bounded aperiodic.Response. a3.1 P a3.2a3.1: The User—Data—Processing task analyses the re-

ceived user command, and converts it to a controllermessage.

a3.2: The message is inserted in the controller buffer.

3.3. Sequences for processing control messages

Description. The event Proc—Messages is generatedwhen a new message is inserted in the controller buffer.As a result, the controller—robot task gets and analyses itscontents, and then executes the appropriate activity. Themessages associated with the event can occur arbitrarilyclose to each other, in the worst case. However, themaximum number of event occurrences over a specificperiod (60 ms) is restricted to six. This specific period isfixed by the reception time of commands by the ROC.

¹ype. Timed, bounded aperiodic.Response. ac.1 P D [ac.2.. ac.7]ac.1: A controller message is extracted from buffer.ac.x: The controller message is processed by the robot

controller, and sent to the appropriate task.

3.4. Sequence for updating the user interface

Description. This sequence is initiated by the task (t6)that is in charge of interacting with the user interface. Theassociated event (Graphical—Update) is issued by therobot—controller task.

¹ype. Timed, bounded aperiodic.Response. a6.1 P a6.2a6.1: A message is processed for sending to the user

interface.a6.2: The user interface is updated.

B. A!lvarez et al. /Control Engineering Practice 6 (1998) 409—416 413

Table 1Events

Event ID Type Mode Arrival Pattern Timing req. Activity

Capt—Status External Normal Periodic, (250) Hard, n/a a5.1Pa5.2Pa5.3Automatic—Action Internal Normal Bounded, (60) Hard, n/a ac.8Proc—Messages Timed Normal Bursty, (60, 6) Hard, n/a ac.1PD[ac.2,ac.3,ac.4,ac.5,ac.6,ac.7]Capt—Command External Normal Bounded, (2000) Hard, n/a a3.1Pa3.2Send—Command Timed Normal Bounded, (60) Hard, n/a a4.1Pa4.2Send—User Timed Normal Bounded, (60) Hard, n/a a6.1Pa6.2Coll—Operation Timed Normal Bounded, (2000) Hard, n/a a1.1Pa1.2Pa1.3Pa1.4Graphical—Update Timed Normal Bounded, (250) Hard, n/a a2.1Pa2.2Pa2.3Pa2.4

3.5. Sequence for the calculation of kinematics

Description. This sequence is initiated by task (t1),which is in charge of interaction with the collision-detec-tion server, and it finishes when the status of the opera-tion is inserted in the controller buffer. This sequence isexecuted in response to the Coll—Operation event.

¹ype. Timed, bounded aperiodic.Response. a1.1 P a1.2 P a1.3 P a1.4a1.1: A message is sent to the server.a1.2: The robot kinematics calculation is made.a1.3: The result of the operation is converted into

a message for the controller.a1.4: A message is inserted in the buffer.

3.6. Sequence for graphical updating

Description. As mentioned above, the status informa-tion from the robot control unit is received periodically.When this information is received, a service from thegraphical representation module, to update the robotrepresentation is requested. The sequence handles theevent Graphical—Update, and is initiated by task (t2),which is in charge of interacting with the graphical rep-resentation subsystem.

¹ype. Timed, bounded aperiodic.Response. a2.1 P a2.2 P a2.3 P a2.4a2.1: The status is processed and sent to the graphical

representation module.a2.2: The graphical representation is updated.a2.3: The graphical representation answer is converted

into a controller message.a2.4: The message is inserted in the controller buffer.

3.7. Sequence for sending commands to the ROC

Description. The sequence is initiated by task (t4),which is in charge of interacting with the ROC. It is theresponse associated to the Send—Command event.

¹ype. Timed, bounded aperiodic.Response. a4.1 P a4.2a4.1: The robot command is formatted, to be sent to

the ROC.a4.2: The command is sent.

3.8. Sequences for automatic commands

Description. At any time, the controller can senda command to the robot. This is an aperiodic sequence,but the minimum separation between commands is fixedand limited by the robot control unit.

¹ype. Internal, bounded aperiodic.Response. ac.8ac.8: A robot message is generated, for sending to the

ROC.

3.9. System situation table

The essence of a real-time situation is expressed inthree tables. In Table 1, the system events and the asso-ciated information are shown. The system has only oneoperating mode (Normal). For example, Proc—Messagesis a timed event. Its arrival pattern is bursty. The timeinterval in which the arrival burst will occur is 60 ms.This event’s deadline is hard.

In Table 2, the actions of the system are shown. Eachaction is characterized by its attributes. The timing be-havior of an action is affected by:

f Which resource it uses.f The priority of the action on that resource. The prior-

ity is a value, associated with an action, that is used byan allocation policy to resolve contentions for sharedresources. It can be expressed in integer values orsymbolic values.

f The amount of time for which it will be using thatresource.

f The policy being used to allocate the resource. Anallocation policy is characterized by the type of re-source being used, and the specific policy name.

f Whether the action requires exclusive use of the re-source. This is called ‘‘atomic’’ action. An action maybe atomic on one resource, such as a data object, whichsimultaneously using another resource, such as theCPU, in a non-atomic manner.

f Whether the action has to be performed with limitedjitter. Some actions within the response to a periodicevent require that the action, usually input/output, be

414 B. A!lvarez et al. /Control Engineering Practice 6 (1998) 409—416

Table 2Actions

Action ID Jitter Resource ID Atomic Time used User ID Priority

a5.1 n/a CPU No c51 t5 App Pa5.2 n/a CPU No c52 t5 App Pa5.3 n/a CPU No c53 t5 App P

BUFFER Yesa3.1 n/a CPU No c31 t3 App Pa3.2 n/a CPU No c32 t3 App P

BUFFER Yesa6.1 n/a CPU No c61 t6 App Pa6.2 n/a CPU No c62 t6 App Pa1.1 n/a CPU No c11 t1 App Pa1.2 n/a CPU No c12 t1 App Pa1.3 n/a CPU No c13 t1 App Pa1.4 n/a CPU No c14 t1 App P

BUFFER Yesa2.1 n/a CPU No c21 t2 App Pa2.2 n/a CPU No c22 t2 App Pa2.3 n/a CPU No c23 t2 App Pa2.4 n/a CPU No c24 t2 App P

BUFFER Yesa4.1 n/a CPU No c41 t4 App Pa4.2 n/a CPU No c42 t4 App Pac.1 n/a CPU No cc1 tc App P

BUFFER Yesac.2 n/a CPU No cc2 tc App Pac.3 n/a CPU No cc3 tc App Pac.4 n/a CPU No cc4 tc App Pac.5 n/a CPU No cc5 tc App Pac.6 n/a CPU No cc6 tc App Pac.7 n/a CPU No cc7 tc App Pac.8 n/a CPU No cc8 tc App P

performed without jitter. ‘‘Jitter’’ is a measure of thedeviation between the desired time for an input/outputto be performed, and the actual time at which theinput/output is performed. A specification of ‘‘n/a’’means that there is no requirement to control jitter.

In this way, the jitter policy, the use of resources, thetime computation, the user task, and the priority aredescribed for each action. The fields that can vary be-tween different implementations of the situation are leftas general parameters, such as C11 or App[P]. Thedesigner of a new application can analyse whether thearchitecture can meet the timing requirements, by pro-viding the specific values for general parameters.

Finally, Table 3 shows the resources, their types andthe policy for dealing with simultaneous events. Resourcetypes include: CPU, data object, device, backplane bus,and so on. The processor, or CPU, is perhaps the mostcommon shared resource in software systems. The sched-uling policies or set rules that determine which of all theactions that are ready to execute will be allocated theCPU are generally implemented by an operating system.In this case, the scheduling policy is called a ‘‘fixed-priority policy’’ which uses priorities of actions that

Table 3Resources

Resource ID Type Policy Switch Time

CPU CPU Fixed priority n/aBUFFER Data Highest locker n/a

are fixed, in the sense that they do not vary from oneevent to the next.

Another software mechanism that is frequently used asa resource is the data object. When data objects areshared in a mutually exclusive fashion between concur-rent entities like tasks, one task can cause delays for othertasks. The allocation policy for the data object will deter-mine the size of the delay. In this case, the ‘‘highestlocker’’ protocol is used. The user of the data objectexecutes at the priority of the highest-priority task thatcan access the data object. In this way, Table 3 showsa fixed priority for the CPU, and highest locker for thebuffer.

Although a system has been already implemented onthe basis of this architecture, it has not been possible touse the framework presented here. This product is not

B. A!lvarez et al. /Control Engineering Practice 6 (1998) 409—416 415

based on a real-time operating system, because the tim-ing requirements do not require it. In addition, otherrequirements, such as the need to use commercial toolsfor collision detection and graphical representation, pre-cludes the above option. However, the architecture isbeing used for the development of other products, and itis intended to use the framework to check their timingbehaviour.

4. Conclusions

Rate Monotonic Analysis has been applied to a genericsoftware architecture for teleoperation systems. In orderto analyze the timing requirements of the system, a set ofassumptions have been made. In this way, the timingbehaviour of the system can be predicted.

This framework allows the designer to evaluate thesuitability of the generic architecture to fulfil the timingrequirements of a particular application.

The analysis presented above provides a pattern foridentifying the sequences of events, actions and sharedresources in the architecture. Then, the designer canprovide the required timing information, and check thatthe application deadlines are guaranteed. The timinginformation required consists of:

f general requirements, which characterize the timingbehaviour of robot teleoperation systems,

f the minimum separation between commands to therobot unit control,

f the minimum separation between user commands alsof status robot information, sent periodically from the

robot unit control,f time computation of the activities in the target platform,f the priority of the action for each resource.

In this work, these general parameters are illustratedfor a specific product, and are 60, 2000, and 250 ms,respectively. However the designers of other applicationswould have to provide this timing information.

Acknowledgements

This work has been funded by the Spanish Govern-ment Committee for Science and Technology (CICYT),project no. TIC96-0614.

References

Alonso, A., Alvarez, B., Pastor, J., de la Puente, J.A., Iborra, A., 1997.Software architecture for a robot teleoperation system. 4th IFACWorkshop on AARTC. April, 1997. Vilamoura, Portugal.

Hassan Gomaa, 1989. Software Design Methods for Real-Time Sys-tems. Software Engineering Institute, Carnegie Mellon University.

Krutchen, P., 1995. Architectural Blueprints — The ‘‘4#1’’ View ofSoftware Architecture, IEEE Software.

Klein, M., Ralya, T., Pollack, B., Obenza, R., Gonzalez Harbour, M.,1993. A Practitioner’s Handbook for Rate Monotonic Analysis, forReal-Time Systems. Luwer Academics Publishers, Boston.

Liu, C.L., Ayland, J.W.L., 1973. Scheduling Algorithms for Multiprog-ramming in a Hard Real-Time Environment, J.ACM 20(1), 46—61.

Sha, Lui, Goodenough, J.B., 1991. ‘‘Real-time scheduling theory andada’’. IEEE Computer.

Sha, L., Lehoczky, J.P., Rajkumar, R., 1986. Solutions for some practi-cal problems in prioritized preemptive scheduling. Proc. IEEE Real-Time Systems Symp., CS Press, Los Alamitos, Calif, Order No. 749,pp. 181—191.

Sha, L., Rajkumar, R., Lehoczky, J.P., 1987. ‘‘Priority inheritance pro-tocols: An Approach to Real-Time Synchronization’’, Technicalreport, Dept. of Computer Science, Carnegie Mellon Univ.

Withey, J.V., 1994. Implementing model-based software engineering inyour organization: An approach to Domain Engineering. Technicalreport, Software Engineering Institute (CMU).

416 B. A!lvarez et al. /Control Engineering Practice 6 (1998) 409—416