*Corresponding author. Tel: #34-968-325-654; fax: #34-968-325-345.E-mail address: barbara.alvarez@upct.es (B. AD lvarez).

Control Engineering Practice 9 (2001) 395}402

Reference architecture for robot teleoperation:development details and practical use

BaH rbara AD lvarez��*, AndreH s Iborra�, Alejandro Alonso�, Juan Antonio de la Puente��Universidad Polite&cnica de Cartagena, Dpto.Tecnologn&a Electro& nica, Paseo Alfonso XIII, 50, 30203-Cartagena, Spain

�Universidad Polite& cnica de Madrid, Depto. Ingeniern&a de Sistemas Telema& ticos, Ciudad Universitaria s.n., E-28040 Madrid, Spain

Received 5 June 2000; accepted 11 August 2000

Abstract

The need to avoid redundant e!orts in software development has been recognized for a long time. Currently, work is focused on thegeneration of products that are designed to be reused. A reference architecture for robot teleoperation systems has been developedusing the domain-engineering process and certain architectural patterns. The architecture has been applied successfully for thedevelopment of di!erent teleoperation platforms used in the maintenance activities of nuclear power plants. In particular, this paperpresents how the reference architecture has been implemented in di!erent systems, such as the Remotely Operated Service Arm(ROSA), the Teleoperated and Robotized System for Maintenance Operation in Nuclear Power Plants Vessels (TRON) and theInspection Retrieving Vehicle (IRV). � 2001 Elsevier Science Ltd. All rights reserved.

Keywords: Software architecture; Robots control; Real-time systems; Teleoperation; Software engineering

1. Introduction

Software reuse has become an important factor incurrent developments due to market competitiveness andtime-to-market requirements. Although the interest inreusing software arose with the origins of the program-ming, this issue has not been practiced with success as yet(Prieto-Diaz, 1991; Tracz, 1995). One reason is the di$-culty of combining existing software components. In ad-dition, although reusability at this level is a goodpractice, it is not enough. One way of raising the degreeof reuse is to apply this approach to software architec-ture, which comprises the software components, theirvisible properties and their relationships (Bass, Clements,& Kazman, 1998).

In the next section, the stages of the domain engineer-ing process are described (Withey, 1994). Its goal is toobtain a domain-specixc software architecture (DSSA).This process was developed in the context of the programsoftware technology for adaptable and reliable software(Prieto-Diaz & Arango, 1991). Its success is derived from

the fact that the software requirements can be satis"ed indi!erent ways, and implementation limitations restrictthe ways in which these requirements can be ful"lled.Previous works on domain analysis did not allow forobtaining a design model.

The question is how to develop a software architecturethat can be e!ectively reused. The common approach isto concentrate on a domain area. It seems feasible toreuse a software architecture in a set of systems withcommon features. Then, a suitable practice is to developa reference architecture that takes into account thespecial properties of a type of system in a domain area.A reference architecture is de"ned as a division of func-tionality together with data #ow between pieces mappedonto software components (Bass et al., 1998).

The authors were involved in the development ofa teleoperation system. In addition to the common func-tional requirements of this type of system, the productshould be easily maintained and adaptable to di!erentoperational environments and robots. Many investiga-tors have described robot-control architectures based ona speci"c operating system and programming language.In these cases, the usual approach is to replace the robotcontrollers by generic controllers (Hayward & Paul,1986; Hayward & Hayati, 1988; Li, Tarn, & Berjczy,1991). These systems are focused on robot control and

0967-0661/01/$ - see front matter � 2001 Elsevier Science Ltd. All rights reserved.PII: S 0 9 6 7 - 0 6 6 1 ( 0 0 ) 0 0 1 2 1 - 0

Fig. 1. Domain-engineering process.

tasks planning, and little support is given to teleoper-ation. In other cases, the system does not allow theoperator to interact dynamically with the system(Brooks, 1986). In Albus, McGain, and Lumia (1989)a reference architecture for robot teleoperation, that fo-cuses on the control of autonomous systems, operating innon-structured environments is described. It uses com-plex and expensive arti"cial intelligence techniques.None of these approaches ful"ls the non-functional re-quirements previously described.

The domain engineering process was used by theauthors and, as a result (Alonso, AD lvarez, Pastor, de laPuente, & Iborra, 1997) a Domain-Speci"c SoftwareArchitecture (DSSA) for robot teleoperation systems wasdeveloped. Since the publication of that paper, the refer-ence architecture has been used with great success in thedevelopment of a number of teleoperation systems fordi!erent robots and tools. The goal of this article is torevisit the approach taken from a more abstract andmature point of view, and to describe the cases where ithas been used.

Section 2 shows the process followed to identify thecomponents, relations and requirements of teleoperationsystems. In Section 3, the way certain architectural styleswere selected for the interaction among subsystems isdescribed. In Sections 4}6 several teleoperation robotsystems developed with the proposed reference architec-ture are described. Section 7 includes some conclusions.

2. Domain engineering

The process of domain engineering covers all the activ-ities required to build a common software core for a fam-ily of systems (Withey, 1994). This process was applied tobuilding a reference architecture for robot teleoperationsystems (Alonso et al., 1997). The following activitieswere performed (Fig. 1 shows this process):

(1) Domain analysis: in order to identify the set ofcomponents that are common to teleoperation applica-tions. The result was a domain model.

(2) Domain design: in order to obtain a generic design,based on the previous result and on the study of patternsor common models.

(3) Implementation of the design: based on reusablecomponents that can be used in di!erent products.

There are several methods of performing a domainanalysis but most of them do not o!er techniques tocapture and to represent the information related toa family of systems. Featured-oriented domain analysis(FODA) (Kang & Cohen, 1990) o!ers these techniquesand supports reusability, not only at the purely func-tional level, but at the architectural level as well. TheFODA method proposes the use of certain models forperforming a domain analysis. In particular, it proposesthe following activities: (1) a context analysis, that allows

the environment of the domain to be de"ned and (2)a functional analysis, in order to identify the similaritiesand di!erences of the existent systems. As a result of theapplication of this method to teleoperation systems,a generic speci"cation of requirements has been ob-tained. In Alonso et al. (1997) functional and non-func-tional requirements for a general teleoperation systemare described, as well as the basic functional requirementsor services that the system should provide to the endusers, and the timing requirements. In these systems, timerequirements should be met in order to ensure that theinformation that the operator receives is valid and re-#ects the current state of the robot.

The following step in the domain-engineering processis domain design. There are many studies that describehow to perform a domain analysis, however these do notexplain how to use the results of such an analysis toobtain a generic design. The approach described in Peter-son and Stanley (1994) was used. It groups the elementsthat work together to performing a certain task in tosubsystems.

The next step in de"ning the reference model forteleoperation systems is to split the functionality amonga number of components and to identify the data #owamong the pieces. Fig. 2 shows how the teleoperationreference model is mapped onto software components. Inshort, the functionality of these components or subsys-tems is the following:

� Graphical representation: This subsystem is in chargeof showing the operator the current state of the robotand the environment in which it is operating. It pro-vides operations for initializing the representation andfor updating the status of the robot, according to theinformation received from the remote control unit.

� Collisions detection: This subsystem provides the re-quired functions for checking whether a given move-ment command is safe, in the sense that the robot doesnot collide with the operating environment or withitself.

� User Interface: It is in charge of interacting with theoperator. It allows him to issue commands to therobot and to know their execution status.

396 B. A!lvarez et al. / Control Engineering Practice 9 (2001) 395}402

Fig. 2. High-level architecture description.

� Communications: This subsystem embodies the com-munication protocol with the remote control unit. Itprovides a means to send commands and to receivestatus information. In this module, a mechanism forfault treatment should be included to guarantee safety,in case communication with the control unit is lost.

� Controller: It is the core of the system and it is incharge of executing the commands from the user, byusing the other components and sending the appropri-ate orders to the robot. It also receives the robot'sstatus from the remote control unit, to check its con-sistency and to show it to the operator.

In this domain, it is common to have a robot withdi!erent controllers. This is true in the case of a movingarm, where it is necessary to consider the control of anarticulated arm whose base can be "xed on a vehicle andwhose end joint holds a tool for performing speci"coperations. In this case, the teleoperation system has todeal with three controllers and the proper synchroniza-tion mechanisms should be implemented.

3. Re5nement of the reference model

In order to get the reference architecture it is necessaryto specify how the di!erent components are going tointeract. For this purpose, the approach followed is basedon characterizing the interaction between the compo-nents and selecting an appropriate architectural style,which de"nes a particular pattern for run-time controland the data transfer mode. The use of architecturalstyles allows the use of well de"ned, well understood andsuccessfully tested interaction mechanisms. They help todevelop systems with desirable properties, such as main-tainability and portability.

Two architectural styles were used to de"ne the inter-action between the components: client-server (Berson,1996) and communicating processes, according to theclassi"cation in Bass et al. (1998). The client-server styleis appropriate when there is a component that providesa service and another that requests it. It allows the serveror the client to be changed, as long as the de"ned servicesare requested and provided following the designed inter-face. This is the case in the interactions between theGraphical Representation and the Collisions Detectioncomponents with the Controller component. The "rstcomponent provides services for showing the status ofthe robot. The second checks whether or not a robotmovement could result in a collision. In these two cases,the interfaces were implemented based on messages, inorder to allow distribution. The interaction is asyn-chronous, because the controller cannot be blocked fora long time while it waits for a service to be completed.

A general communicating processes style was used forthe interaction between the User Interface and the Com-munication components with the Controller. This is be-cause there is not necessarily a cause and e!ectrelationship that guides these interactions Any of thecomponents can take the initiative to send data. Forexample, consider the information that the Communica-tion component sends to the Controller. It can be periodicstatus data or aperiodic alarms, caused by some unex-pected robot behavior. On the other hand, the controllermay send commands to the robot at any time. The sameholds for the relationship between user interface and thecontroller(s). A controller sends sporadic messages to theuser interface when the robot's status changes or somefailure occurs in the system. The user sends commands tothe controller when a certain robot behavior is required.

In the internal design of the components, two styleswere used: layered and object-oriented. The layered styleis useful to achieve portability and easy modi"cation. It isbased on structuring the components as a set of layersand it was used in the design of the Communicationscomponent. Only some of the layers need to be changed ifthe system has to be ported to di!erent hardware or hasto use alternative protocols.

The internal design and implementation of the rest ofthe subsystems is based on object-oriented and abstractdata-types styles. These paradigms emphasize thebundling of data and how to manipulate and access thatdata. Data encapsulation promotes reusability and easymodi"cation.

The robot's control should not be interrupted for anyreason. Therefore, certain mechanisms have been intro-duced for decoupling the control task from the rest of thesubsystems and for receiving the information from them.In this way, if a failure occurs in another subsystem, thecontroller can continue operating. These mechanisms aremodules in charge of communicating with the rest andtranslating data. The communication of these modules

B. A!lvarez et al. / Control Engineering Practice 9 (2001) 395}402 397

Fig. 3. The ROSA arm.

Fig. 4. High-level architecture for ROSA.

with the interfaces is by means of procedure calls. Whena message is sent to a controller, these decoupling mod-ules store it in a bu!er, so that the controller is notinterrupted. Each controller can be seen as a control loopwhich continuously checks the received messages bu!er.

The general controller that has been designed performsthe following operations: (1) it receives commands fromthe operator, (2) it checks if the operations are feasible, (3)it simulates the movements before executing them, (4) itsends commands to the remote control unit, and (5) itupdates the state of the system. This design has shown tobe general enough to be used for the implementation ofcontrollers for di!erent robots. In case a robot has sev-eral controllers, as mentioned in the previous section,Step 2 includes synchronizing them.

This kind of system may have time requirements thatmust be met. The Rate Monotonic Analysis (RMA) (Klein,Ralya, Pollak, Obenza, & GonzaH lez-Harbour, 1993) the-ory allows the designer to reason with con"dence abouttiming correctness at the tasking level and to analyzewhether tasks deadlines can be met. In this way, a refer-ence architecture has been developed and a frameworkfor analyzing its timing response has been built, as de-scribed in AD lvarez, Alonso, and de la Puente (1998).

The three teleoperation systems that use the referencearchitecture is used do not have hard real-time require-ments. The three robots move quite slowly and hence thetime requirements were relatively long and soft. In addi-tion, there was no special safety requirement. As a result,the only component with hard real-time requirementswas the remote control unit.

The rest of the article presents the developmentof di!erent teleoperation systems using this referencearchitecture.

4. The ROSA system

The remotely operated service arm (ROSA) system pro-vides a remote user interface for controlling a jointed armwith six-axis (Fig. 3). Di!erent tools are used for inspect-ing and repairing the tubes in the steam generators.

The development platform is a Hewlett Packard 9000model 725 workstation, with the HP-UX operating sys-tem. A local area network connects the teleoperationplatformwith the robot control unit. The remote control-ler is based on an Heurikon HK68/V30XE processor,a VME bus, an ampli"er, and several control cardsattached to it.

Fig. 4 shows a high-level description of the architecturefor the ROSA system. This scheme includes two control-lers: a robot and tool. A generic controller was developedin Ada, since its modular characteristics and genericfacilities make the development of reusable code easier.

The implementation of the components for thegraphics and the collision detection were based on

a commercial tool called Robcad. It allows the user tode"ne the robot and its operation environment in 3-D. Itautomates the operations for collision detection and itsgraphical output is excellent. These components weredeveloped in the programming language C##, since thelibraries o!ered by this commercial tool were developedin this language.

The user interface was developed in the programminglanguage ANSI-C. The resources o!ered by X Windowswere used by means of user interface language (UIL) andMotif.

The rest of the architecture has been implemented inAda. In particular, the communications subsystem wasbased on TCP and UDP sockets. A package of asyn-chronous real-time Ada drivers for interconnected sys-tems exchange (PARADISE) was used. This packageo!ers an interface to the communication routines of theUnix operating system. Generic modules were developedfor the interfaces among the subsystems. They o!er servi-ces for communication among processes.

For the planned steam generator maintenance opera-tions, it was necessary to develop a number of mechan-ical tools to perform speci"c operations in the tubesheetof steam generators, such as detecting the wrong tubes.

398 B. A!lvarez et al. / Control Engineering Practice 9 (2001) 395}402

Fig. 5. Electro-disintegration machine.Fig. 6. Gripper.

Fig. 7. Screwdriver.

Fig. 8. Welding machine.

An inspection process based on eddy currents is used, tocancel the wrong tubes, to recover them, to drill plugsand to place the nozzle-dams.

Tools controllers have been developed for dealing withthese tools. They are di!erent instances of the genericcontroller described in the previous section. The requiredparameters of these software packages are related to theelements used to characterize the mechanisms (jointedarm and tools). These elements are speci"c commandsand state machines. This allows the de"nition of: (1)robot status, (2) its evolution after a command executionand (3) the commands that are feasible for each state.

A controller was developed for an electro-disintegra-tion machine (Fig. 5). This tool was designed for thedisintegration of unwanted elements which could belocated in the tubesheet (plugs, drills, etc.). The toolconsists of the following parts: a cone for anchoring it tothe robot's end, a "xed platform on which the visiondevices are installed, linear potentiometers for aligning itwith the tubesheet and some camlocks for anchoring it tothe tubesheet. The electro-disintegration head is locatedon the surface of a sliding table. Commands were pro-vided to insert the electro-disintegration head in thewrong tube, to activate it, to set the intensity and voltage,and to load and unload the tool.

Two tool controllers are used to tighten and to controla gripper which is used for positioning the nozzledams.Fig. 6 shows a gripper. This tool consists of four pneu-matic pistons. These activate four pincers that are usedfor positioning the nozzledams in the primary circuits.

The fasteners and nuts that hold the nozzledams areinstalled by means of a screwdriver (Fig. 7). In the case ofthe gripper, commands are provided to control the pin-cers and anchor the tool to the robot. To control thescrewdriver, some commands to adjust the head, to screwand to unscrew are provided.

A commercial machine was adapted for welding plugsin the tubesheet of the steam generator. Fig. 8 shows thistool. Commands to activate the head, to gauge the tooland to load and unload the tool are provided.

For each tool, a common model was used for develop-ing the user interface and the generic communicationmodule. In this case, appropriate parameters were pro-vided for connecting with the tool processes of the remotecontrol unit.

B. A!lvarez et al. / Control Engineering Practice 9 (2001) 395}402 399

Fig. 9. Vehicle of the system IRV. Fig. 10. TRON system.

5. The IRV system

The Inspection Retrieving Vehicle (IRV) system isa teleoperated vehicle with sensors, lights, cameras andinterchangeable end-e!ectors. The vehicle can operateten meters underwater, inside pipes of 400mm and larger.This system is used for retrieving foreign objects frominside the primary circuit nozzles of nuclear powerplants. Fig. 9 shows the vehicle.

The hardware platform for this teleoperation system isthe same as that in the ROSA system. Most of thatsystem was directly reused. In particular, it was necessaryto implement three controllers: for the vehicle, arm andtool. These controllers communicate among themselvesin order to synchronize the operations of the controlledelements. In order to implement the controllers, the gen-eric packages developed in the ROSA system were in-stanced for the IRV system. The generic parameters arerelated to the operations of the devices (commands andstate machines).

The graphic representation component consists of anarti"cial vision system. Its function was to identify theedges of the objects and the most signi"cant elements ofthe environment and to superimpose a wire frame repres-entation of these onto real images provided by cameras(Iborra, LaH zaro, DommHnguez, & Campoy, 1993). The in-put information for this module is sent, due to e$ciencyreasons, through an independent channel directly fromthe cameras. This subsystem is implemented on a di!er-ent hardware platform (a personal computer). The rest ofthe teleoperation system runs on a HP 9000/725.

In the current implementation, there is no collisiondetection subsystem, and the graphical representationsubsystem does not include a model of the environmentor devices. They are not necessary for the current opera-tions, but they can be added using commercial tools. Theuser interface subsystem is based on Motif. The visionsystem and the communications modules have been de-veloped in the programming language C. It is importantto note that the changes in the graphical representationcomponent did not require modi"cation of the rest of thesystem.

6. The TRON system

Teleoperated and Robotized System for MaintenanceOperation in Nuclear Power Plants Vessels (TRON) isa robotized system used for retrieving objects in thenuclear plant's reactor vessels. Fig. 10 shows this system.Due to human error during the recharging fuel opera-tion, objects can fall into the vessel. This system can beintroduced through holes, which are called bottom inter-nals, to inspect the vessel and to recover the objectswithout having to dismantel the nucleus.

The whole system comprises a jointed pole, theend-e!ectors and a navigation system based on arti"cialvision techniques, that helps the operator to movethrough really complex environments (dark and fullof obstacles). The pole consists of four joints. Theend-e!ector and the inspection cameras are attached tothe end link. The reduced dimensions of the inlet (3.8 cm)prevents the use of more complex mechanisms.

In this system, a real-time operating system was notrequired. The pole moves very slowly. Therefore, poten-tial collisions with the environment can be detected andthe motors can be disabled before it happens. For thisreason, the controllers and user interface componentswere implemented on a Pentium PC, running Windows.The programming language was C##. New interfacemodules among subsystems were developed withoutmodifying the communication mechanisms among them.

In this case, the architecture design was reused. Theimplementation language and the execution platformwere di!erent to those in the previous cases, hence therewas no code reuse. The generic controller class wasimplemented at the top of the hierarchy class. The poleand end-e!ector controllers were derived from such

400 B. A!lvarez et al. / Control Engineering Practice 9 (2001) 395}402

Table 1Characteristics of the robot systems

System ROSA IRV TRON

Motion speed Slow Slow SlowReal-time requirement Soft Soft SoftOperation environment Known Unknown UnknownExecution platform HP 9000 HP 9000 Win. NT

a mechanism controller class. The object-oriented pro-gramming paradigms allow software designs to beadapted or extended if new functionality has to be added.As in previous systems, the pole and the end-e!ector weredescribed in terms of their basic commands, their statemachine and their structural and dynamic models.

The graphical representation and collisions detectioncomponents run on a HP 9000/725 workstation and theutilities provided by Robcad were used. In this case, thecollision detection module is very simple because it doesnot require inverse kinematics. Communications linksbetween processes running on the PC (user interface andcontrollers) and the processes running on the worksta-tion (graphical representation and collisions detection)are done with TCP/IP sockets.

7. Applications development summary

This section describes the di!erences and similaritiesbetween the previous systems. In this way, it will be easierto understand the development decisions taken. Table 1tries to summarize this information.

The basic requirements for a teleoperation system aresimilar in most cases, i.e. to provide a means for allowingan operator to send commands to the robot and toretrieve its state information. For the three reuse scen-arios, a common characteristic of the robots is that theirspeed of motion is slow. This implies that the real-timerequirements are not very tight and therefore easy toful"l. Hence, the worst response time required for a com-mand to be sent to the robot or to receive the status wasrelatively long, and in the range of 100}300ms. Thisimplies that the hardest real-time requirements were todo with the control of the motors and the processing ofthe sensors of the robot. These functions are imple-mented in the remote control unit component, which isoutside the scope of this paper.

The working environments of the robots were anotherimportant issue that a!ected the decisions taken. In thecase of the ROSA system, it was necessary to know veryprecisely the structure of the steam generator and thegeometry of its tubes, in order to perform the mainten-ance operations correctly. This information allowed theenvironment to be modeled with an appropriate tool andto have this information accessible during the system's

operation. The advantage of using the facilities of thecommercial tool was that it was very easy to dynamicallychange the view-point of the representation. This facilitywas very much appreciated by the operators who usedthe system.

In the case of the IRV and TRON systems, it was notfeasible to know their operational environment with thesame level of detail. For this purpose, cameras weremounted on the robots. Instead of showing the operatora graphical representation of the robot and its environ-ment, the images taken by the cameras were used.

The "nal aspect that has an important in#uence on thesystem implementation was the execution environmentof the teleoperation system. In the case of the IRV andthe ROSA systems, exactly the same platform was used.Obviously, this allows the developers to raise the level ofreuse, which dramatically reduces the development timeand e!ort. In the TRON case, the requirements imposedby the contractor made it necessary to choose a di!erentplatform. This implied that although the reference archi-tecture was reused, most of the code was rewritten.

8. Conclusions and future work

The application of domain-engineering process andsoftware architecting techniques were the basis for thedevelopment of a reference architecture for robot tele-operation systems. Several architectural styles have beenselected for describing the interaction rules among thecomponents. Each style depends on which qualities arerequired.

The suitability of this architecture has been validatedby its use in the development of di!erent products withthe same basis and its application to other robots. Theuse of the Ada language facilitated the development ofgeneric components that could be reused for di!erentproducts of the same system. Furthermore, the interac-tion between components written in Ada with othersubsystems written in C has not been a problem.

In the three systems, the software has been testedsuccessfully with a real robot and a 1 : 1 mock-up of thenuclear plant part where it will work. The developmentof these tools and their control software results in theacquisition of a proprietary technology for maintenanceworks in nuclear plants. Due to the qualities of thereference architecture, the cost of this development wasa!ordable.

The reference architecture was shown to be appropri-ate for systems such as those presented in the previoussections. One common characteristic of these systems istheir slow motion speed. The development team wouldlike to use the reference architecture with faster robots.It could behave correctly, although some modi"cationsmay be necessary for guaranteeing time requirements,such as the need to use a separate computer for the

B. A!lvarez et al. / Control Engineering Practice 9 (2001) 395}402 401

graphical representation and using a real-time operatingsystem.

There are plans to modify the reference architecture inorder to allow it to teleoperate more than one robot fromthe same computer. This improvement will be probablyused for dealing with a number of slow-motion robotsdesigned for cleaning ships surfaces.

Finally, some components of the implementation ofthe architecture in Ada will be rewritten using the newlanguage standard approved in 1995. In this way, itwould be possible to take advantage of language features,such as the object-oriented facilities, hierarchical pack-ages, and the real-time and distributed annexes.

Acknowledgements

This work has been partially supported by the SpanishGovernment Programmes for Research in ElectricalPower (Project PIE-041049), and for Technological Ac-tuation in Industry (PAUTA projects 753/ 95 y 53/96).TRON is supported inside EUREKA}MAINE program(EU1565).

References

Albus, J. S., McGain, H. G., & Lumia, R. (1989). NASA/NBS standardreference model for telerobot control system architecture (NASREM).Technical Report 1235, National Inst. Standards and Tech.,Gaithersburg, USA.

Alonso, A., AD lvarez, B., Pastor, J.A., de la Puente, J.A., & Iborra,A. (1997). Software architecture for a robot teleoperation system.4th IFAC Workshop on Algorithms and Architectures for Real-TimeControl. Vilamoura, Portugal.

AD lvarez, B., Alonso, A., & de la Puente, J. A. (1998). Timing analysis ofa generic robot teleoperation software architecture. Control Engin-eering Practice, 6(6), 409}416.

Bass, L., Clements, P., & Kazman, R. (1998). Software Architecture inPractice. MA, USA: Addison-Wesley.

Berson, A. (1996). Client/Server Architecture. New York, USA:McGraw-Hill.

Brooks, R. A. (1986). A robust layered control system for a mobilerobot. IEEE Transactions of Robotics and Automation, 2(1), 505}515.

Hayward, V., & Hayati, S., (1988). KALI: An environment for theprogramming and control of cooperative manipulators. AmericanControl Conference, Atlanta, USA.

Hayward, V., & Paul, R. (1986). Robot manipulator control underUnix: A robot control C library. The International Journal ofRobotics Research 5(4), 54}63.

Iborra, A., LaH zaro, M. A., Dominguez, S., Campoy, P., Alvarez, M.,& R. Aracil (1993). An automatic system for the real time integra-tion of live action and synthetic 3-D computer images. 4th Euro-graphics Animation and Simulation Workshop. Grenoble, France.

Kang, K. C., & Cohen, S. (1990). Feature-Oriented Domain Analysis(FODA) feasibility study. Technical report, CMU/SEI-90-TR-21.Software Engineering Institute. Carnegie Mellon University:Pittsburgh, USA.

Klein, M. H., Ralya, T., Pollack, B., Obenza, R., & Gonzalez Harbour,M. (1993). A Practitioner's Handbook for Rate Monotonic Analysis.MA, USA: Kluwer Academics Publishers.

Li, Z., Tarn, T. J., & Berjczy, A. K. (1991). Dynamic workspace analysisof multiple cooperating robot arms. IEEE Transanctions on Roboticand Automation, 7(5), 589}596.

Peterson, A. S., & Stanley Jr, J .L. (1994). Mapping a Domain Model andArchitecture to a Generic Design. Technical report, CMU/SEI-94-TR-008. Software Engineering Institute, Carnegie Mellon Univer-sity: Pittsburgh, USA.

Prieto-Diaz, R. (1991), Reuse in the U.S.A. Proceedings of the 13thannual international conference on software engineering. IEEEComputer Society Press: Austin, USA.

Prieto-Diaz, R., & Arango, G. (1991). Domain analysis and softwaresystems modeling. Los Alamitos, USA: IEEE Computer SocietyPress.

Tracz,W. (1995). Confessions of a used program salesman: Institutionaliz-ing software reuse. Reading, MA: Addison-Wesley PublishingCompany: MA, USA.

Withey, J. V. (1994). Implementing model based software engineering inyour organization: An approach to domain engineering. TechnicalReport, CMU/SEI-90-TR-21. Software Engineering Institute,Carnegie Mellon University, Pittsburgh, USA.

402 B. A!lvarez et al. / Control Engineering Practice 9 (2001) 395}402