distributed computing in robotics and automation

IEEE TRANSACTIONS ON ROBOTICS AND AUTOMATION, VOL. 18, NO. 4, AUGUST 2002 409

Distributed Computing in Robotics and AutomationDavide Brugali and Mohamed E. Fayad

Abstract—The pervasive introduction of the Internet intorobotics and automation systems pushes forward an evolutionthat began when the computer was introduced in the enterprisein the middle of the last century, and that continued with theinterconnection of shop-floor workstations in local networks inthe 1980s. Today, the Internet represents a challenge both forresearch and development in the area of distributed roboticsand automation. In order to gain a better understanding andevaluation of recent results in distributed computing, this paperclassifies the most promising technological approaches, providesexamples of how they are applied in robotics and automation, anddiscusses available standards and commercial solutions.

Index Terms—Distributed computing, frameworks, object-ori-ented technology.

I. INTRODUCTION

ROBOTICS and automation systems are now ubiquitous.Intelligent robots help human beings in everyday life; the

Internet connects factory automation systems to customers andproviders in order to build the so-called “Virtual Factory;” “WebRobotics” is a new fascinating frontier for research and enter-tainment.

Most of these new trends have been made possible by the evo-lution of the personal computer (PC) (in terms of cost, power,and robustness) and the Internet (in terms of security, speed, andreliability). This evolution has dramatically influenced the wayrobotics and automation systems are conceived and developedtoday. In the last few years, big companies like General Motorshave initiated radical moves to replace programmable logic con-trollers (PLCs) in manufacturing with PC-based systems run-ning PLC emulation software [46]. The Internet is becomingpervasive in those sectors that were out of scope until a few yearsago: real-time control [15], telemanipulation and vehicle teleop-eration [27], sensor measurement collection and integration formobile robots and manipulators [43]. The PC and Internet revo-lution promises easy peripheral integration, universal access toshared data and resources, and inexpensive reconfiguration ofdistributed systems. In reality, much research and developmenteffort is still needed. Distributed computing is the research fieldwhere new techniques, models, and methodologies are studiedand experimented with in order to reach such goals.

In order to gain a better understanding and evaluation of re-cent results in distributed computing, this paper classifies themost promising technological approaches, provides examples

Manuscript received December 1, 2001. This paper was recommended forpublication by Associate Editor Y. Narahari and Editor N. Viswanadham uponevaluation of the reviewers’ comments.

D. Brugali is with the School of Engineering, University of Bergamo, 5-24044Dalmine, Italy (e-mail: [email protected]).

M. E. Fayad is with the Department of Computer Science and Engineering,University of Nebraska, Lincoln, NE 68588 USA (e-mail: [email protected]).

Digital Object Identifier 10.1109/TRA.2002.802937

of how they are applied to the development of robotics and au-tomation systems, and discusses available standards and com-mercial solutions.

The paper is organized as follows. Section II analyzes thede-factostandard technology available to build large-scale soft-ware systems, namely the object-oriented technology (OOT),and introduces the concepts of framework. Section III presentsthree architectural models of distribution. Section IV presentsthree distributed computing paradigms. Section V discussesmiddleware frameworks for distributed computing. Section VIillustrates enterprise application frameworks. Section VIIdiscusses future trends. Finally, Section VIII draws the relevantconclusions.

II. BACKGROUND

OOT consists of techniques and mechanisms to be used instructuring models and program code after the entities (objects)found in the problem domain. OOT is based on the concept ofobject as program unit, which encapsulates both data and al-gorithms. This concept distinguishes the object-oriented (OO)programming paradigm from pure procedural and functionalparadigms. The code that accesses and modifies given data isconfined to one location in the program and not spread, uncon-trollably, throughout the program.

Take, for example, the simulation of dexterous manipulatorsin a robotic workcell [4]; an object can describe an end-effectorby means of attributes (e.g., the three-dimensional coordinatesof its position, the direction, the force), operations (e.g., rotate,grasp), and relationships with other objects (e.g., the solid objectwhich it is grasping, the robot arm which it is linked to). Objectswith similar properties belong to the same class. For example,the classEndEffectormight define a family of end-effector ob-jects that differ from each other in terms of their specific cur-rent position, direction, etc. In other words, a class defines thecommon type (structure) of a set of objects, while an object isan instance of a specific class.

Objects execute their operations on behalf of other objects,which invoke them. A single-threaded application (e.g., a graph-ical TeachPendant for motion control) is made up of a number ofcooperating objects and a main function that defines the applica-tion’s control and information flow. It manages the interactionwith the user, and determines the sequence of method invoca-tions of its component objects.

Active objects[37] are objects that possess, create, and in-ternally manage one or more independent threads of control(called activities), which govern the execution of their methods.An application made up of active objects is able to performmultiple activities concurrently. Each activity might be initiatedby the application’s main function, but can then proceed au-tonomously. The synchronization of concurrent activities is han-

1042-296X/02$17.00 © 2002 IEEE

410 IEEE TRANSACTIONS ON ROBOTICS AND AUTOMATION, VOL. 18, NO. 4, AUGUST 2002

dled by specific mechanisms such as semaphores, monitors, andtransactions. For example, a workcell controller can be madeup of a number of active objects that execute multiple activi-ties concurrently, e.g., scheduling, dispatching, and monitoring.Active and passive (nonactive) objects can be distributed on thenetwork. An application that integrates objects running on dif-ferent networked computers is called a distributed application.For example, the controller of a manipulator in a workcell can beimplemented as an active object running on a PC linked to themanipulator. The workcell controller coordinates its activitieswith the remote controllers of each manipulator in the workcellby exchanging information via Internet.

A. Object-Oriented Software Development

OOT supports the development of software applications byoffering three basic techniques.

1) Encapsulation, which consists of constructing new classesaround objects of existing classes. For example, the classMa-nipulator is made up of several instances of classJoint, of classLink, and one instance of classEndEffector.

2) Inheritance, which consists of deriving new classes as spe-cializations of classes which already exist. For example, theclassHandextends the classEndEffector(the parent class) byincluding a set of instances of classFinger and redefining thegraspbehavior.

3) Polymorphism, which allows two or more subclasses of thesame class to respond to the same message in different ways.For example, all the subclasses ofEndEffectorrespond to thesame messagegrasp, but each subclass implements a differentprocedure (e.g., moving a hand’s fingers). At run time, aManip-ulator object can send the messagegraspto objects of anyEn-dEffectorsubclass and still get the correct response (the end-ef-fector grasping a solid object). OOT has the advantage of facili-tating the development of highly modular systems. The behaviorof a composite object is the result of the collaboration amongits component objects. The basic mechanism of collaborationis delegation. For example, theManipulatorobject coordinatesthe positioning of the end-effector by delegating the relative ro-tation of the links to theJoint objects.

B. Object-Oriented Frameworks

Complex applications are rarely built from scratch. They usu-ally derive from the reuse of similar applications or part of them.OOT supports the concept of OO framework for the develop-ment of families of similar applications. A framework is an inte-grated set of classes and relations describing structures of coop-erating objects. A framework is more than a library of softwarecomponents: it defines the common architecture underlying theconcrete applications built on the framework. Frameworks are apowerful developing approach as they consist of both reusablecode (the component library) and reusable design (the architec-ture). Although the benefits and design principles underlyingframeworks are largely independent of the application domain,we have found it useful to classify frameworks by their scope asfollows.

1) System infrastructure frameworks[18] simplify the de-velopment of portable and efficient system infrastructuresuch as operating system and communication frame-

works, as well as frameworks for user interfaces andlanguage-processing tools. System infrastructure frame-works are primarily used internally within a softwareorganization and are not sold to customers directly.

2) Middleware integration frameworks[6] enhance theability of software developers to modularize, reuse,and extend their system infrastructure to work seam-lessly in a distributed environment. There is a thrivingmarket for middleware frameworks, which are rapidlybecoming commodities. Common examples includemessage-oriented middleware and object request broker(ORB) frameworks. Middleware frameworks simplifythe development of interoperable applications and arenow commonly used for the development of distributedrobotics and automation systems. Section V will discussthem in detail.

3) Enterprise application frameworks[17] are structuredcollections of software components conceived for spe-cific application domains. They solve most of the designand implementation problems common to the applica-tions in that domain and are usually built on top of amiddleware framework. They address broad applicationdomains (such as telecommunications, manufacturing,avionics, and financial engineering) and are the corner-stone of enterprise business activities [19]. Comparedwith system infrastructure and middleware integrationframeworks, enterprise frameworks are expensive todevelop and/or purchase. However, they can providea substantial return on investment since they supportthe development of end-user applications and productsdirectly [20]. Examples of enterprise frameworks forthe industrial automation domain will be presented inSection VI.

4) Global information frameworksaddress large scale andglobal application domains (such as healthcare, war man-agement, global labor systems, banking and financial in-stitutions). The concept of global information frameworkis still a research issue in robotics and automation; it isapplied in the development of multinational virtual orga-nizations.

Regardless of their scope, frameworks can also be classified bythe techniques used to customize them in concrete applications,which range along a continuum from white-box, gray-box, toblack-box frameworks.

White-box frameworksrely heavily on OO language featureslike inheritance and dynamic binding in order to achieveextensibility. Existing functionality is reused and extended byinheriting from framework base classes, and overriding pre-defined hook methods using design patterns like the templatemethod [24].Black-box frameworkssupport extensibility bydefining interfaces for components that can be plugged intothe framework via object composition. Existing functionalityis reused by defining components that conform to a particularinterface and integrating these components into the frame-work. Gray-box frameworksavoid the disadvantages of bothwhite-box and black-box frameworks, since they have enoughflexibility and extendibility, and hide unnecessary informationfrom the application developer [60].

BRUGALI AND FAYAD: DISTRIBUTED COMPUTING IN ROBOTICS AND AUTOMATION 411

III. D ISTRIBUTED ARCHITECTUREMODELS

Distributed computing can be described as the effort to unifymultiple networked machines in such a way that informationor other resources can be shared by all of these connected com-puters [53]. The architecture of a distributed system is describedin terms of identified system components (the applications orparts of them), how they are connected (the relationships amongthe components), and the nature of the connections (the mech-anisms used to establish the relationships) [25]. Four architec-tural models are described in the following.

A. Client/Server Model

In OO programming, interactions between two objects areimplemented as operations on one of the two. The object thatperforms the operations is called theserver, while the objectthat requests an operation and uses its results is called theclient[35]. When both the client and the server reside in the sameaddress space (i.e., they are part of the same single program),the client holds a reference to the server (its memory address)to invoke its operations. When the client and the server resideon remote computers, a middleware framework allows them toexchange data and services through the network. A typical ex-ample of client/server architecture is the reference model forflexible manufacturing systems (FMS) as specified by the U.S.National Bureau of Standards [36]. The layers of this hierar-chical and distributed control architecture are indicated as fa-cility, shop, cell, workstation, machine, and equipment. Eachlayer contains control modules, which are the servers to clientsat a higher layer and, in turn, are clients of servers at a lowerlayer [9].

B. Three-Tier Model

Designing a client/server system requires the system’sfunctionality to be split between the clients and the servers.The question is whether to have fat servers (the server managesboth the data and the processing) or fat clients (the servermanages only the data). It is a matter of how many clients sharecommon data and operations on them, and has implications forthe system scalability, portability, and efficiency. An evolutionof the client/server model is the three-tier model [47].

The main difference is that in a three-tier architecture, most ofthe functionality is separated out from the client and the serverin a middle layer, called application servers. The three-tier ar-chitecture improves the system’s robustness, dependability, andmodularity, since it decouples the independent functionality of aclient/server system. An example of three-tier architecture is theWeb Interface for Telescience System used by the Mars PolarLander [2]. An example in mobile robotics can be found in [7].

C. Broker-Based Model

Due to advances in networking technology, increasinglyheterogeneous distributed computing resources are becomingavailable on the Internet. For example, the Internet connectsa network of organizations to build the so-called “VirtualOrganization” [39]. In an open distributed environment likethe Internet, resources (the servers that manage them) are free

to appear and disappear and the mapping of client requests toserver services is highly dynamic.

The problem is finding what service is available from whichserver [13]. Since it is not feasible to broadcast on the Internetthe information that a resource has appeared, specific compo-nents take on the role of broker. A broker represents a mediationlevel between clients and servers. According to the informationthat it manages, the broker acts like a domain name server (itknows the name and Internet location of a group of server ob-jects), matchmaker (it knows the service offered by the serverobjects), facilitator (it knows the policies and protocols to accessthe services of the server objects), or mediator (it offers new ser-vices as a composition of other servers’ services). Examples ofbroker-based systems can be found in [14].

D. Multiagent Model

Software agents are integrated systems that incorporate majorcapabilities drawn from several research areas: artificial intelli-gence, databases, and operational research, to name a few. Theyare usually implemented as software objects that may be cus-tomized and made up with other similar objects to build complexmultiagent systems [51]. From an architectural point of view, thefollowing two aspects characterize multiagent systems.

1) Task-Based Roles: Within a multiagent system there is nota clear-cut distinction between clients and servers. Theroles are not assigned to the agents at compile time, butare determined by the specific task assigned to the system.

2) Task-Oriented Relationships: Software agents formulateproblem-solving plans and carry out these plans throughquerying and exchanging information with other softwareagents. They act on behalf of another agent, they react toexternal or internal events, or they perform autonomousactivities such as monitoring their own activity or theexternal environment. Examples of multiagent systemscan be found in [42] (manufacturing domain) and [40](robotics domain).

IV. DISTRIBUTED COMPUTING PARADIGMS

Since the advent of distributed computing in the 1980s, in-formation sharing across a network has assumed several formsat different levels of abstraction. In this context, abstractionmeans the capability of accessing distributed resources in atransparent way with regards to their physical location, dataformat, structure, implementation language, and execution sup-port. Sections IV-A–C introduce three distribution paradigms.

A. Stub/Skeleton Paradigm

The distribution paradigm adopted by some middlewareframeworks like Object Management Group (OMG) commonobject request broker architecture (CORBA) [58] and Javaremote method invocation (RMI) [29] consists in implementinga distributed address space where client and server objects canexchange messages. This is accomplished by means of twoancillary objects called thestuband theskeleton(see Fig. 1).The stub is a surrogate (proxy) of the server and resides inthe client’s address space. It offers the same set of operations


Fig. 1. Stub/skeleton paradigm.

Fig. 2. Mobile code paradigm.

(called theinterface) as the remote server. The client invokesthe stub’s operations as if it were the server itself. The stub isin charge of marshalling the client’s request and transmittingit through the network. The skeleton resides in the server’saddress space, and is in charge of receiving and unmarshallingthe client’s request and invoking the corresponding server’soperation. Similarly, the matched pair stub/skeleton is used totransmit the result of a server’s operation to the client throughthe network. The matched pair stub/skeleton is automaticallygenerated at compile time or at run time by the middlewareused to network the client and the server.

B. Mobile Code Paradigm

In most distributed object systems, the information that canbe passed between the client and the server is limited to a smallnumber of primitive data types, or references to other distributedobjects, or structures made up of these types and [61]. It seemsnatural to expect clients and servers to be able to exchange full-fledged objects carrying over both the data and the code thatmanipulates it. This is possible using a different approach todistributed computing, i.e., code mobility. Code mobility canbe defined as the capability to dynamically change the bindingsbetween objects and the location where they are executed [23].

An object can migrate at run time from the client’s to theserver’s execution environment or vice-versa (see Fig. 2). De-pending on the direction of the migration, code mobility is clas-sified as follows.

1) Code on Demand: The client downloads from the server’ssite the software components, called mobile objects, thatit needs to execute its tasks. The mobile objects arelinked at run time to the client’s application and areexecuted in its address space. Mobile objects might bepassive components or threads that start running when

the downloading has been completed. Mobile objects arestored in the client host and deleted after use.

2) Mobile Agents: The client sends an active object calledmobile agent to the server’s site. The mobile agent usesthe server’s resources to perform some useful activitieson behalf of the client. The mobile agent can already berunning at the client’s site before migrating; its state isserialized, transmitted over the network, and then restoredat the destination site so that it can resume its execution.

Compared with the traditional client/server paradigm, the codemobility approach can reduce network traffic and improve com-munication reliability. In fact, moving part of the client or theserver to the other side of the communication link allows thetight interactions between the two to bypass the network. Thismakes interactivity possible even in cases where connection ispoor, and it provides a much cheaper alternative to increasingthe network bandwidth.

Code mobility makes the client/server paradigm moreflexible, since both the client and the server can extend theircapability dynamically. In particular, code mobility simplifiessystem maintenance, since the server and the client can beupgraded independently. The client always downloads thelast version of the server’s mobile objects; the server can beupgraded from a remote host by sending a mobile agent withnew functionalities.

C. Declarative Communication Paradigm

Both the stub/skeleton and the mobile code paradigms requirethe client and the server to commonly agree on a set of datastructure definitions and on the meaning of the operations onthose structures.

This is a strong requirement that limits the possibility of in-tegrating heterogeneous (e.g., legacy) systems.

An alternative approach has emerged from the distributedartificial intelligence field: the definition of standard applica-tion-level communication languages and protocols.

Distributed applications, usually calledagents, can coop-erate since they share the same communication language anda common vocabulary, which contains words appropriate tocommon application areas and whose meaning is defined in ashared ontology [16]. An agent communication language is amessaging protocol, where a message is a textual expressioncomposed of a communication primitive, called performative,that corresponds to a specific linguistic action (e.g., query,answer, assert, define), and the content, i.e., a sequence ofdeclarative statements built using a knowledge representationlanguage. The implementation of the declarative communica-tion paradigm does not call for the use of the stub/skeletonmechanism, nor a common execution environment, as codemobility does. Each agent relies on a parser component thatinterprets the incoming messages (see Fig. 3). Interactionsamong agents are established dynamically through standardnetwork protocols.

Recently, the declarative communication paradigm has foundapplicability in the broad domain of Web applications. The ex-tensible markup language (XML) technology has been proposed


Fig. 3. Declarative communication paradigm.

as the uniform data and exchange format among distributed ap-plications (see the web site of the W3C consortium [62]). XMLdocuments are semistructured, as they have a flexible syntacticstructure based on tag (mark up) nesting, which may contain un-structured information. The document structure is defined by adocument-type definition (DTD), an XML specification basedon suitable metatags; a document that respects a specific DTDis said to bevalid. Following the original spirit of the W3C rec-ommendation that introduced XML, a generic XML processorshould be able to process a generic XML document. Most of theframeworks presented in Section V support the XML format andprovide software tools and components for parsing, processing,and visualizing XML documents.

V. MIDDLEWARE FRAMEWORKS

A middleware framework for distributed computing consistsof an integrated set of service components that allow distributedsystems to operate together. Typically, middleware frameworksoffer the following services.

1) Distributed event managementsupports dynamic notifi-cation of events raised by remote objects.

2) Location-transparent access to remote objectsallows dis-tributed objects to cooperate regardless of their networklocation, of the operating platforms where they are exe-cuted, and possibly of their implementation language.

3) Distributed objects locationallows client objects to iden-tify at run time which server objects offer the function-ality they need. Client and server objects can appear anddisappear on the network dynamically.

4) Network security managementsupports digital signaturesand data encryption.

5) Persistency and transaction managementsupports persis-tent storage, access to distributed data, data replication,and data consistency.

Using a middleware framework consists of developingend-user applications by delegating the execution of commonfunctionalities to middleware services.

A. OMG CORBA

CORBA is a standard for distributed middleware defined bythe OMG, a consortium of more than 700 organizations in-cluding software industry leaders such as Sun, HP, IBM, Mi-crosoft, and Rational. This architecture has reached a good levelof maturity and is now implemented in more than ten commer-cial products.

The basic component of the architecture is the ORB, whichshould be installed on each connected host. The ORB uses thestub/skeleton mechanism for remote communication betweenclient and server objects. The stub and the skeleton of a serverobject are generated at compile time from a declarative speci-fication of the server’s interface in the language-neutral inter-face definition language (IDL). The interface describes whichmethods the server object supports, which events the object cantrigger, and which exceptions the object raises. The server ob-ject can be implemented in any programming language (C, C++,Java, etc.). The ORB installed on the server side is in chargeof translating the incoming IDL service requests from the re-mote clients into the server’s method invocations. The IDL sup-ports the declaration of only basic type arguments, which haveto be passed to a remote server. The connection between the stuband the skeleton is established using the remote procedure call(RPC) mechanism.

The ORB supports location transparency, as it provides theclient with a reference to the server object regardless of its net-work location. The client side ORB dispatches service requeststo the server side ORB transparently. Since CORBA can be im-plemented using different technologies, the Internet interORBprotocol (IIOP) defines the standard communication protocolfor intervendor ORB compatibility.

The ORB supports the control of the threading policy used bythe servers, such as one thread per request and one thread per ob-jects. This threading capability is at the basis of recent CORBAextensions toward a real-time ORB (see [21] for a comprehen-sive survey on recent results in developing a standard real-timeCORBA).

1) CORBA Services:Server objects can publish the IDLspecifications of their interface using the interface repositoryapplication programming interface (API). The interface repos-itory is used to implement two services for object location.The trader serviceis similar to the yellow pages. It allowsclient objects to find out which distributed server objectssupport a given interface. The trader service returns a list ofreferences to the objects, which have registered that interfaceand a description of the usage constraints for each object. Thenaming serviceallows client objects to identify which interfaceis supported by an object that has been registered with a givenname. In some cases, the client object has to request the serviceof a server object, whose interface was not known at compiletime. This means that the client object does not have a stubof the remote server object, but it can use a generic interface,called dynamic invocation interface, that makes it possible toconstruct method invocations at run time [58].

Other common services are thepersistent objectservice forstoring and retrieving objects in/from a persistent storage, thetransactionservice, thelife-cycleservice to create, delete, copy,and move objects, and theeventservice for asynchronous com-munication among distributed objects. The real-time CORBAstandard specifies an optionalschedulingservice, which usesthe primitives of the real-time ORB to achieve a uniform sched-uling policy in CORBA systems [21].

2) CORBA for Robotics and Automation Systems:A varietyof distributed systems in robotics and automation are imple-mented on top of the CORBA middleware. In [28], the server


controls a mobile platform, while the client integrates commontasks such as path planning, localization, sensor fusion, and en-vironmental modeling. In [9], the architecture of an FMS isimplemented as a client/server system. OMG has establisheda number of Working Groups whose aim is to define standardinterfaces for CORBA objects which support a variety of man-ufacturing functionalities, with the goal of enabling interoper-ability among heterogeneous and legacy systems. The followingWorking Groups are part of theManufacturing Domain TaskForce.

a) Enterprise Resource Planning: Typical business objectsbeing standardized are manufacturing orders, bills ofmaterials, item descriptions (goods, materials, compo-nent parts), process specifications (routings, recipes),and tooling.

b) Product and Process Engineering: The objective is to es-tablish standard interfaces that enable the interoperabilityof computer-aided drawing (CAD), computer-aidedmanufacturing (CAM), and computer-aided engineering(CAE) tools.

c) Manufacturing Execution Systems/Machine Control:The objective is to establish standard interfaces forcomputerized systems, which support manufacturingfunctions (data collection, information management, jobdispatching, etc.).

Similar efforts are being carried out by theTransportationDomain Task Force, and theEnterprise Application IntegrationDomain Task Force.

B. SUN Java

Java is the OO programming language from Sun Mi-crosystems [29]. The most relevant characteristic (calledWriteOnce/Run Anywhere) is its portability. Java programs written onone type of hardware or operating system can run unmodifiedon almost any other type of computer. This is possible becauseJava programs are compiled in an intermediate format calledbyte code that is interpreted by the Java Virtual Machine (JVM),an architecture-neutral platform implemented on top of a ma-chine’s native operating system. Specific implementations ofthe JVM are now available for almost all the existing operatingsystems. A variety of class libraries (called packages) provideready-to-use service components for distributed computing.Examples are thejava.netpackage for TCP-IP socket-basedcommunication, thejava.securitypackage for cryptographyand resource access control, theorg.xml.saxandorg.w3c.dompackages for XML parsing, and thejava.jni package for in-teroperability with applications written in different languages.Four more important packages follow.

1) RMI is the Java mechanism for remote object communi-cation. It implements the stub/skeleton approach but, dif-ferent to CORBA IDL, the server’s interface is writtenin Java. The stub is not linked within the client’s ad-dress space at compile time, but it is downloaded fromthe server side when the client needs a connection tothe server object. The client can invoke remote servermethods by passing object arguments to the server’s stub

and receiving object values from it. Thanks to RMI, theclient can pass objects belonging to subclasses of the ar-guments supported by the server’s methods. If the serverdoes not know the class, it downloads its code dynami-cally.

2) Appletsare small graphical applications that run within aWeb browser. The programmer implements specific ap-plets on the server side. When a remote user accesses aweb page containing a reference to an applet, the applet’scode is downloaded from the web site and executed insidethe browser. The applet is not allowed to access the localresources on the client side (e.g., its file system), but itsends data and commands to the remote server (e.g., viaRMI).

3) Servletsare small applications that run within a Webserver. The programmer implements specific servlets onthe server side and gives them network names in the sameway as is done for standard web pages. A remote userconnects to a servlet’s uniform resource locator (URL)using a web browser. A servlet can receive multipleconnection requests from different browsers simultane-ously and can return entire web pages containing images,sounds, and text resulting from a query to the server’sdatabase. The user can send data and commands to aremote servlet by means of a hypertext markup language(HTML) form or an applet.JavaServer pages(JSP)are an extension of servlet technology that provides adeclarative method of developing servlets.

4) Enterprise Java Beans (EJB)are a component-basedtechnology for developing server-side applications.The basic concept is the EJB container, a databasemanagement application that provides persistence andtransaction services to the enterprise beans. There are twotypes of enterprise beans. Session beans offer serviceson demand to the container’s clients and are usuallystateless. Entity beans represent data maintained in adatabase and are persistent.

J2EE: J2EE [54] is a middleware framework specifically de-signed to build enterprise applications. It is a software platformstructured as a three-tier architecture. In reality, the middle ap-plication tier is made up of two distinct but tightly coupled tiers:the Web tier and the business tier.

1) TheClient Tier typically consists of a Web browser or astand-alone application that displays information and col-lects data from the users. Web clients interact through theHTTP protocol with the Web tier exchanging XML data,while stand-alone clients interact with the EJB containersof the business tier through the RMI mechanism.

2) TheWeb Tiermanages the dynamic content creation ofthe web pages available to the web clients. Servlets andJSP pages map JavaBeans components to the HTML (orXML) presentation format.

3) The Business Tierhosts the EJB components (businessobjects) that implement application-specific businesslogic. It represents the core J2EE infrastructure im-plementing system-level services such as transactionmanagement, concurrency control, and security.


The Server Tier builds on the J2EE connector architecturewhich is the bridge between the business tier and heterogeneousenterprise information systems such as enterprise resource plan-ning, mainframe transaction processing, and database systems.

J2EE Services:The J2EE platform includes a set of EJBcomponents that implement middleware services to simplify ap-plication programming.

1) Naming Servicesprovide EJB components with namingand directory functionalities, such as searching for objectsusing their attributes.

2) Deployment Servicesprovide facilities to associate de-ployment descriptors to components and to manipulatethem. These descriptors define how the component can beconfigured, customized, and installed when it is reused ina new environment.

3) Transaction Servicesallow EJB components to create,start, and control transaction objects. These objects areused to divide an application into a series of atomic unitsof work.

4) Security Servicesprovide mechanisms for the identity au-thentication and resource access authorization of softwarecomponents and users.

Other Java-Based Frameworks:Two more important frame-works should be mentioned.

TheIBM Agletspackage [33] is an API that supports the mo-bile agent paradigm. Aglets are active objects that can suspendtheir activity, migrate to a remote host, and resume their exe-cution on that host. Before dispatch, the aglet serializes its in-ternal state into a standard form. When the aglet (the bytecodeof its class plus its serialized state) arrives at the receiver side,it is assigned a new thread and executed. An aglet always be-longs to anAgletContext, a container class that provides an in-terface for the runtime environment on the local host. This in-terface allows aglets to create new aglets in a context, to getreferences (proxies) to other aglets, and to manage data securityand access authorization. Client-side aglets establish a link witha server-side aglet through its proxy (similar to the RMI stub).Aglets adopt an asynchronous communication protocol.

TheSun JINI Platform[1] is an extension of the RMI frame-work. The stub (called proxy) is no longer a simple interface,which maps the server’s methods and forward the client’s re-quests. Instead, it is a full-fledged object, which embeds the co-operation protocol between the client and the server, executes(part of) the service logic within the client’s address space, ordelegate its execution to the remote server. The server can be anyphysical device (e.g., a mobile platform, a robot manipulator, asensor), which is powerful enough to run a JVM. Any client thathas to request services from a networked device (calledSmartDevice) downloads the corresponding proxy object from the de-vice and is ready to use its services. The Jini platform imple-ments the LookUp service in order to identify available serviceson the network.

Java for Robotics and Automation Systems:There are atleast two reasons why Java is not yet a wide-spread technologyin robotics and automation. The Java language has not yet beenassessed well. New releases of the core functionality replace theold ones that become deprecated. Performance is still a big con-

cern since Java is only partially compiled. The byte code cannotaccess the computational resources of the hosting machinedirectly, but only through the JVM. The strength of the Javatechnologies lies in the growing support that it is gaining. Manyready-to-use solutions for a variety of application domains(e.g., computer graphics, networking, telecommunications) areprovided as freeware packages available on the Web.

In the near future, we envisage a wider adoption of the Javatechnology in those application areas where the flexible inter-connection of decentralized functionality is going to becomea necessity. An example is factory automation [12], wherebusiness and production processes are spreading across factoryboundaries (see the Terpsichore project for interfactory orderprocessing [10]). In the automotive industry, the challengesare “infotainment” systems which combine vehicle safetyand entertainment features with data-driven applications thatare often associated with the Internet or cellular phones. Inthis context, Sun Microsystems is working along with majorcar manufacturers to develop the Java Concept Car proof ofconcept [55]. NASA’s Jet Propulsion Laboratory has adoptedJava Applet technology for the remote command of the MarsPathfinder spacecraft [2]. An example of Web access to mobilerobots can be found in [59] and access to a robotic arm (usingapplets) in [26]. Siemens has developed the SICOMP Javafor Process Control (JFPC) environment, a Java package thatmakes it possible to address process devices from a highabstraction level with real-time performance [8]

C. Microsoft .NET

This is the new Microsoft technology for developing dis-tributed systems [57]. It borrows many successful concepts fromthe Java world and from CORBA in order to achieve interop-erability of heterogeneous applications. The following four as-pects characterize the .NET framework.

1) TheCommon Type System (CTS)is an object model thatextends the previous COM and DCOM models with thegoal of supporting multiple-language software develop-ment.

2) TheIntermediate Language (IL)is an OO language thatconforms to the CTS. Various Microsoft and third-partylanguage compilers (for C++, Java, etc.) generate code inthe IL language (e.g., Microsoft VisualStudio.NET).

3) TheCommon Language Infrastructure (CLI)is a runtimeenvironment (similar to the JVM) that executes code com-piled in the IL language.

4) The.NET Software Development Kit (SDK)is an OO col-lection of reusable components. It provides runtime hostsfor the CLI for a variety of execution platforms. InternetExplorer is an example of a runtime host. It also supportsthe development of customer runtime hosts.

The essence of the Microsoft proposal is the possibilityof compiling existing code and new code written in the pro-grammer’s favorite language. The resulting applications caninteroperate with class libraries and components written indifferent languages using the .NET runtime environment.

.NET Services:The .NET framework simplifies the devel-opment of software applications by making an extensive use of


the reflection mechanism. Reflection is the capability of the CLIruntime environment that allows applications to explore theirown structure at runtime. This is possible because every objectenforcing the CTS is associated with metadata information thatdescribes its structure and functionality. The following servicesbuild on the reflection mechanism.

1) .NET Remotingallows objects to interact over the Internetusing binary encoding where performance is critical, orXML encoding where interoperability with other applica-tions is essential. Similar to Java RMI, it is based on thestub/skeleton model: the stub (called proxy) is created atrun time using the metadata published by the server.

2) Web Servicesare reusable components which are used todevelop server-side applications. They combine the dis-tributed computing capability with the Web portal con-cepts and can be compared to the Java Servlets and JSP.The ASP.NET is the hosting environment for Web ser-vices. Examples of common Web services are email, cal-endaring, notification, authentications, etc. Clients usethe ubiquitous wsdl.exe utility (a Web service directorysupplied with the .NET SDK) to discover and find Webservices.

3) Serializationallows a memory object or graph of objectsto be converted into a linear sequence of bytes that can bestored on a disk or sent to another networked computer.This mechanism is at the basis of the .NET persistenceservice that uses metadata information to automaticallystore and to reconstruct memory object.

The .NET framework is a brand new technology. No relevantexamples of .NET applications in robotics and automation aredocumented in the literature yet. Prior to .NET, the Microsoftframework was based on COM/DCOM technology. A middle-ware technology for factory automation based on COM/DCOMis OPC (OLE for Process Control) [41].

D. Foundation for Intelligent Physical Agents (FIPA)

FIPA [22] is an international association of companies and or-ganizations whose aim is to define specifications of agent tech-nologies. FIPA’s primary focus is agent interoperability. A mul-tiagent system might be made up of hundreds of heterogeneousagents implemented in different languages and running on dif-ferent platforms. The FIPA agent model defines the minimumset of requirements that allow them to cooperate. Up to now,FIPA has produced specifications for the rules described in Sec-tions V-D.1–3. Together these specifications define the FIPAAbstract Architecture. Specific implementations of this archi-tecture result in concrete middleware platforms. FIPA does notimpose any restriction on the technology used for the platformimplementation. For example, the JADE framework [5] is a Javamultithread platform.

1) Agent Communication Language:FIPA agents adopt theintelligent agent paradigm for distribution. In order to cooperate,heterogeneous agents should use the same agent communica-tion language (ACL), which standardizes both the performativesand the content format. An ACL message consists of the fol-lowing list of parameters: the performative (e.g., request, pro-pose, inform, confirm); the sender and the receiver (the unique

names that identify two agents in the system); the content (intext format); the ontology (the reference to a common dictio-nary, e.g., containing common terms in manufacturing); and theinteraction protocol (see Section V-D.2). ACL messages are en-coded in an envelope that specifies the transport protocol (http,smtp, ftp), maps the logical agent name (e.g., “abc”) to trans-port addresses (e.g., “[email protected]”), and defines the encryp-tion protocol (e.g., the public key).

2) Agent Interaction Protocols:FIPA defines standard pat-terns of communication between agents called interaction pro-tocols. Each protocol specifies the roles played by the agents en-gaged in a conversation and the sequence of message exchangesbetween them. Here are some examples of negotiation proto-cols.

1) Contract net. The client agent (calledManager) issues acall for proposalact, which specifies the service it needsand the service execution constraints. A set of serveragents (calledContractors) reply issuing aproposeact,which specifies the service execution preconditions. Themanager can issue anaccept-proposalor a reject-pro-posalact.

2) English Auction. It is similar to the Contract net, but theclient (calledAuctioneer) issues a newcall for proposalact every time at least one server (calledParticipant) is-sues aproposeact. Every new call for a proposal specifiestighter constraints until the last participant issues the bestproposal.

3) Agent Services:FIPA defines a limited set of middlewareservices that guarantee the regular management of interagentcommunication and cooperation, and three mandatory serviceshave been identified.

1) Message Transport Service. Each FIPA platform im-plements a component called Agent CommunicationChannel (ACC). It is equivalent to the parser componentin Fig. 3 and is in charge of parsing the input–outputmessages in accordance with the transport instructionscontained in the message envelope. FIPA does notspecify how the content should be parsed, that is tosay, how the content should be mapped to the internalactions of the agent. The ACC component also offersa message routing service and supports the mappingbetween different transport protocols.

2) Agent Management Service. Each FIPA platform imple-ments a component called Agent Management System(AMS). It is similar to theAgletContextof the IBM agletframework and manages the creation, the deletion, andthe authentication of agents, as well as the migration ofagents when agent mobility is supported by the platform.FIPA agents can query the AMS to get references to otheragents running on the same platform.

3) Directory Service. Each FIPA platform has a DirectoryFacilitator (DF) agent that provides a yellow-page serviceto the agent platform. It is similar to the LookUp serviceof the Jini platform. FIPA defines a property-based de-scription of the services supported by an agent. The DFallows agents to register their service descriptions and to


query it for the name of the agents that provide a givenservice.

4) Intelligent Agents in Robotics and Automation:The FIPAorganization has not yet addressed the robotics and automationdomain, that is to say, no specific standards have been definedfor this domain, and what is more, the literature does not docu-ment robotics and automation systems that enforce current FIPAstandards. Nevertheless, the intelligent agent paradigm has re-cently become popular in robotics and automation due to its suit-ability for modeling autonomous cooperating systems. Agentssupport decision making by formulating problem-solving plansand carrying out these plans through the exchange of informa-tion with other agents. Agents interact with the user receivinguser specifications and delivering results. They acquire, model,and utilize user preferences to guide system coordination inorder to support the user’s tasks. In an open distributed system(e.g., the Internet) agents are free to appear and disappear, toenter or exit a multiagent community. A few examples of multi-agent systems in typical robotics and automation research areasshould be mentioned.

1) Factory Automation. This domain of industrial sys-tems is characterized by the large number of activitiesthat have to be coordinated (process control, resourcemanagement, production planning, logistics, etc.). Suchsystems consist of several geographically distributedsubsystems (plants, workcells, shops, factories, etc.) thatare interconnected via the Internet. In this context, intel-ligent agents are software programs that operate physicalequipment (machines, robots, transport, etc.), manageresources (stores, product data, etc.), interact with thehuman operators, and cooperate in a flexible way so as tocarry out their activities properly. Multiagent systems area viable alternative to centralized control systems, whichare highly sensitive to system failures (e.g., machinebreakdowns), and depend heavily on the availability ofthe single decision, which makes a component work.See, for example, [3] and [41].

2) Mobile Robotics. The synergy between intelligent agentsand mobile robotics is twofold. Virtual environments sim-ulating multirobot systems are conveniently modeled asmultiagent systems. When moving from the simulation tothe real environment, the mapping of autonomous mobilerobots to intelligent agents allows a seamless associationbetween the physical devices and the software programsthat control them. See, for example, [56]. Internet robots[50] are physical devices interconnected with the Internetvia wireless communication. Intelligent agents act as net-work nodes, which map the physical robots and allowthem to cooperate.

3) Collaborative Design. Specialized agents, called inter-face agents, acquire, model, and utilize users’ preferencesto coordinate the actions of multiple engineering de-signers in order to support collaboration in their design[38]. They usually manage a graphical user interface andapply humanlike skills to engage users in rich conversa-tional interactions. They interact with the other agentsand automate several of the most time-consuming stages

of the design process, for example, constraint satisfactionand conflict resolution. Specifically, agents can be of helpin operations that are repetitive, for example, comparingalternative design solutions, which take into account alarge number of parameters.

VI. ENTERPRISEAPPLICATION FRAMEWORKS

The aim of this section is to illustrate examples of recentprojects that have developed or have defined specifications fordistributed application frameworks in the robotics and automa-tion domain on top of the middleware infrastructures presentedabove. A broad review of the current literature shows that signif-icant results can be found more in the automation domain than inthe robotics domain. This is mainly due to the complexity andcost of building enterprise application frameworks. It is clearthat the decision to develop an enterprise framework involvesboth organizational and marketing issues: the effort is cost ef-fective only in large industrial contexts.

Enterprise application frameworks aim at solving the mosturgent problem of enterprise application integration (EAI): thelack of common business and technical architectures, which isnot just the difference in data formats, but the lack of definitionof common business concepts [44].

The OMG is promoting an intense standardization activity fora common business object model (BOM). The OMG EnterpriseApplication Integration (EAI) Working Group has the missionto define a software architecture and a design methodology withwhich to integrate enterprise business systems.

A. Sematech CIM Framework

Sematech is the semiconductor manufacturing technologyconsortium (IBM, Intel, Motorola, and Digital are some of themember companies) that has worked with major US semicon-ductor companies to define a CORBA-compliant frameworkfor agile manufacturing execution systems. The SematechCIM Framework [14] is specifically targeted to manufacturinginformation management and control for both the planningand the operational phases of semiconductor wafer fabrication.The framework defines a set of IDL interface specificationsfor the software objects that map real world semiconductormanufacturing entities. Examples aremachine, storageunit,process job, product, lot, and wafer. Collections of relatedinterfaces that form a coherent unit are called components.Examples arematerial movement, machine management, andprocess management. Each component specification definesthe interactions between the constituent objects, the infor-mation model, and the description of the services provided.CIM developers adopt the framework specifications in orderto build applications that are interoperable (the framework isa de-facto standard), flexible in adapting to changes in thebusiness requirements (the framework is highly modular), andmaintainable (the framework supports the integration of legacysystems).

B. OpenDREAMS Framework

The OpenDREAMS framework [11] is the result of aEuropean-funded ESPRIT project. It supports the develop-


ment of CORBA-compliant supervision and control (SC)systems. These systems are characterized by real time andfault-tolerance requirements, which are not addressed by thecurrent CORBA specifications. The OpenDREAMS frameworkenriches the basic CORBA through a set of service objects,such as theReplication Servicefor the definition of replicasof critical objects and theQuery Servicefor querying objectsgrouped in collections. The framework also provides a set ofdomain-specific modules. There are modules which supportbasic mechanisms of the SC activity, modules which offer waysto classify SC-related events, modules for alarm management,and so on. The development of concrete applications using theframework is supported by a methodology based on the TRIOformal language for the specification of real-time systems.

C. NIIIP

The National Industrial Information Infrastructure Protocols(NIIIP) consortium (Lockheed, NIST, Texas Instruments, andRensselaer Polytechnic Institute are some of the member or-ganizations) aims at providing technologies to enable virtualenterprises. A virtual enterprise is a temporary consortium ofcompanies all linked by a distributed information system thatenables them to operate as one sharing resources and enactingcommon business processes. The NIIIP consortium has defineda CORBA-compliant reference architecture that is comprised ofa set of IDL interface specifications for common service com-ponents.

Examples are theWorkflowservice in order to manage theexecution of distributed user tasks, theAgentservice for en-terprise resource management (e.g., tool controller, shop floorcontroller, human operator), and theMediationservice in orderto translate data from different ontologies and to resolve ambi-guities. Service components are grouped in subsystems such asDecision SupportandTask and Session Management.

D. RosettaNet

RosettaNet [45] is an industry consortium launched in 1998dedicated to the definition of standards for e-commerce insupply chain settings. The standardization effort builds on theXML technology and has produced three main outcomes.

1) A comprehensive set of XML-based business documentschemas and data dictionaries. These schemas are used tocreate business and technical documents that are to be ex-changed between business units, departments, factories,and companies.

2) A model of a business process that defines the standardsteps to execute a generic supply-chain process. Themodel is instantiated in concrete processes such aspurchase order management.

3) The implementation framework consists of an architec-tural model and a set of software components that allowthe development of supply-chain information systems.The architectural model specifies standards for a varietyof fundamental services such as digital signature of docu-ments, authentication, and transactions. An example of asoftware component is the messaging service component.

E. Commercial Products

A number of commercial products provide solutions for rapiddevelopment of enterprise-class applications and for rapid pro-totyping of automation systems. This is a very fast-growingmarket, and a survey of the existing proposals is immediately outof date. We mention two platforms that build on the three-tiermodel and mainly consist in an application server that manages,executes, and exports business components.

1) Sun iPlanet[52]. It is fully compliant with the J2EE spec-ifications including JavaServer Pages support for presen-tation logic, Java Servlets for server side logic, and EJBsfor core business logic, JDBC for access to relationaldatabases. Diamelle Technologies offers a suite of EJBcomponents on iPlanet application server that provide avariety of business services: catalog management, shop-ping cart, order management, etc.

2) IBM WebSphere[32]. It builds on the J2EE technology,but concentrates attention on interoperability withCORBA and the Microsoft standards such as ActiveXand Active Server Pages. The internationalizationenhancements including bean-managed support areparticularly interesting.

F. Agent-Based Systems

A large number of agent-based systems are described in theliterature (for a survey in the manufacturing domain see [48]).A few of them are reusable and customizable frameworks (foran example, see [34]). An interesting agent-based infrastructurefor the development of intelligent manufacturing systems is de-scribed in [49]. It consists of three categories of agents.

1) Basic components(middle agents) provide communica-tion and cooperation services. The cooperation domainserver routes the messages exchanged by other agents, theyellow page agent publishes information about agents’services, and the local area coordinator partitions the net-work of agents in domains and subdomains.

2) Domain-independent componentsembed techniques andmechanisms for agent mobility, collaboration, autonomy,and reasoning. Knowledge management agents are as-sociated with databases and knowledge bases, ontologyservers manage multiple and evolving classifications ofterms and concepts used by other agents, and collabora-tion agents play the role of mediators in large communi-ties of agents.

3) Domain-specific componentsencapsulate various manu-facturing behaviors: planning, scheduling, executions.

VII. FUTURE TRENDS

The OOT is an evolutionary research area. Frameworks, com-ponents [30], and product line architectures [31] are new tech-niques that offer partial (sometimes overlapping) views and so-lutions to the problem of developing modular, reusable, stable,and efficient software systems. Individually, they support onlyone or some parts and phases of the software life cycle. While


frameworks have already been applied in the robotics and au-tomation domain, the other techniques can be considered futuretrends.

A. Components-Based Software Development

Nowadays, software engineering is moving forward on anarchitecture-based development conception where systems arebuilt by composing or assembling components that are oftendeveloped independently. The key to making a large varietyof software products and reducing time to market is to buildpieces of software where the development effort can servein other products as well. Thus, large-grained componentsare becoming a practical part of an enterprise componentstrategy. Such generic components usually include interactionswith other components, code, design models, design patterns,and specifications. They provide ways to be adaptable andcustomizable according to the client’s needs. In this context,enterprise frameworks offer an appropriate base with which thesoftware architectures, components, and core requirements canbe weaved into one container that is adaptable, customizable,extensible, and reusable. The component-based technology isquite well established, but it is not the same with the methodsto develop them.

B. Product-Line Architectures

Product-line architectures are emerging as a new and impor-tant software development paradigm. A product-line architec-ture (PLA) is a design for a family of related applications, and itsmotivation is to simplify the design and maintenance of programfamilies and to address the needs of highly customizable appli-cations in an economical manner. Companies are beginning torealize that the practice of building sets of related systems fromcommon assets can yield remarkable improvements in produc-tivity, time to market, product quality, and customer satisfac-tion. But these gains are only a part of the picture; organiza-tional, technical, and management issues are other factors thathave to be considered. Although there are encouraging researchexperiences with PLAs and some guidelines exist to help in thedevelopment process, many issues about component-based de-velopment in PLAs are still being studied.

VIII. C ONCLUSIONS

Internet is promoting a style and a series of related technolo-gies that leads to the exploration of new research and develop-ment frontiers, and without doubt, will permeate the roboticsand automation field in the years to come. At the same time,the Internet induces new requirements in traditional applicationdomains. Decentralized control is becoming a necessity in in-dustrial process management and enterprise integration. Flex-ibility and interoperability are of fundamental importance forcooperative design support. Robust communication character-izes robotic teleoperation. Scalability and autonomous execu-tion are mandatory for multirobot teams. This paper argues thatarchitectural reference models, a consolidated distributed com-puting technology, and a development methodology which in-corporates reuse both of design and code, are essential vehiclesfor the successful development of large and complex distributed

systems. The paper has provided a comparative analysis of thestate of the art in the research related to distributed computingand a survey of its possible exploitation in the robotics and au-tomation domain.

REFERENCES

[1] K. Arnold et al., The Jini™ Specification. Reading, MA: Addison-Wesley, 1999.

[2] P. G. Backeset al., “Internet-based operations for the Mars polar landermission,” in Proc. IEEE Int. Conf. Robotics and Automation, ICRA,2000, pp. 2025–2032.

[3] F. Balduzzi and D. Brugali, “A hybrid software agent model for decen-tralized control,” inProc. IEEE Int. Conf. Robotics and Automation,ICRA, 2001, pp. 836–841.

[4] J. E. Becket al., “Applying a component-based software architecture torobotic workcell applications,”IEEE Trans. Robot. Automat., vol. 16,pp. 207–217, June 2000.

[5] F. Bellifemine, A. Poggi, and G. Rimassa, “JADE—A FIPA-compliantagent framework,” inProc. PAAM’99, pp. 97–108.

[6] P. A. Bernstein, “Middleware: A model for distributed system services,”Commun. ACM, vol. 39, no. 2, pp. 86–98, Feb. 1996.

[7] R. P. Bonassoet al., “A proven three-tiered architecture for program-ming autonomous robots,”J. Experim. Theoret. Artificial Intell., vol. 9,no. 2, pp. 54–68, 1997.

[8] P. Brichet al., Real-Time Programming in Java. Automation in the Mi-crosecond Range. New York: Springer-Verlag, 2000.

[9] D. Brugali, G. Menga, and A. Aarsten, “The framework lifespan,”Commun. ACM, vol. 40, no. 10, pp. 65–68, Oct. 1997.

[10] D. Brugali, G. Menga, and S. Galarraga, “Intercompany supply chainsintegration via mobile agents,” inGloblization of Manufacturing inthe Digital Communications Era of the 21st Century. Norwell, MA:Kluwer, 1998.

[11] R. Capobianchi, D. Carcagno, A. Coen-Porisini, D. Mandrioli, and A.Morzenti, “A framework architecture for the development of new gener-ation supervision and control systems,” inObject Oriented ApplicationFrameworks, M. Fayad, D. Schmid, and R. Johnson, Eds. New York:Wiley, 1998.

[12] M. L. Chen, S. Kume, A. A. Rizzi, and R. L. Hollis, “Visually guided co-ordination for distributed precision assembly,” inProc. IEEE Int. Conf.Robotics and Automation, ICRA, 2000, pp. 1651–1656.

[13] K. Decker, M. Williamson, and K. Sycara, “Matchmaking and bro-kering,” in Proc. 2nd Int. Conf. Multiagent Systems (ICMAS’96), 1996,pp. 432–443.

[14] D. Doscher and R. Hodges, “SEMATECH’S experiences with the CIMframework,”Commun. ACM, vol. 40, no. 10, pp. 82–84, 1997.

[15] I. Elhajj, N. Xi, and Y.-H. Liu, “Real-time control of internet based tele-operation with force reflection,” inProc. 2000 IEEE Int. Conf. Roboticsand Automation, ICRA, 2000, pp. 3284–3289.

[16] S. Falasconi, G. Lanzola, and M. Stefanelli, “Using ontologies in mul-tiagent systems,” inTenth Knowledge Acquisition or Knowledge-BasedSystems Workshop (KAW’96), Banff, AB, Canada, 1996, pp. 20–28.

[17] M. E. Fayad et.al., Eds., “Object-oriented application frameworks,”Commun. ACM, vol. 40, no. 10, 1997.

[18] M. E. Fayad, D. Schmidt, and R. Johnson,Building Application Frame-works: Object-Oriented Foundations of Framework Design. NewYork: Wiley, 1999.

[19] M. E. Fayad and D. Hamu, “Enterprise frameworks,” inProc. ACMComputing Surveys’ Symp. Object-Oriented Application Frameworks,vol. 32, 2000, pp. 1–9.

[20] M. E. Fayad, D. Hamu, and D. Brugali, “Enterprise frameworks charac-teristics, criteria, and challenges,”Commun. ACM, vol. 43, no. 10, pp.39–46, Oct. 2000.

[21] V. Faye-Wolfe, L. C. DiPippo, G. Cooper, R. Johnston, P. Kortmann, andB. Thuraisigham, “Real-Time CORBA,”IEEE Trans. Parallel Distrib.Syst., vol. 11, pp. 1073–1089, Oct. 2000.

[22] (1999) Specifications. Foundation for Intelligent Physical Agents. [On-line]. Available: http://www.fipa.org

[23] A. Fuggetta, G. P. Picco, and G. Vigna, “Understanding code mobility,”IEEE Trans. Software Eng., vol. 24, pp. 342–361, 1988.

[24] E. Gamma, R. Helm, R. Johnson, and J. Vlissides,Design Patterns:Elements of Reusable Object Oriented Software. Reading, MA: Ad-dison-Wesley, 1995.

[25] D. Garland and M. Shaw, “An introduction to software architecture,”in Advances in Software Engineering and Knowledge Engineering, V.Ambriola and G. Tortora, Eds. Singapore: World Scientific, 1993.


[26] K. Goldberget al., “Collaborative teleoperation via the internet,” inProc. IEEE Int. Conf. Robotics and Automation, ICRA, 2000, pp.2019–2024.

[27] S. Grange, T. Fong, and C. Baur, “Effective vehicle teleoperation on theworld wide web,” inProc. IEEE Int. Conf. Robotics and Automation,ICRA, 2000, pp. 2007–2012.

[28] A. Gueorguiev, P. K. Allen, E. Gold, and P. Blaer, “Design architectureand control of a mobile site-modeling robot,” inProc. IEEE Int. Conf.Robotics and Automation, ICRA, 2000, pp. 3266–3271.

[29] B. Joy et al., The Java Language Specification. Reading, MA: Ad-dison-Wesley, 2000.

[30] D. Kiely, “Are components the future of software?,”IEEE ComputerMag., pp. 10–11, Feb. 1998.

[31] P. Knauber and G. Succi, “Software product lines: Economics, architec-tures, and applications,” inProc. Int. Conf. Software Engineering, ICSE,2000, pp. 632–639.

[32] IBM WebSphere [Online]. Available: http://ibm.com/websphere[33] D. B. Lange and M. Oshima,Programming and Deploying Mobile

Agents With Java and Aglets. Reading, MA: Addison-Wesley, 1998.[34] M. Lejter and T. Dean, “A framework for the development of multi-

agent architectures,”IEEE Expert (Special Issue Intell. Syst. and TheirApplications), pp. 47–59, Dec. 1996.

[35] S. M. Lewandowsky, “Frameworks for component-based client/servercomputing,”ACM Comput. Surv., vol. 30, no. 1, pp. 4–27, Mar. 1998.

[36] C. McLean, M. Mitchel, and E. Barkmeyer, “A computer architecture forsmall-batch manufacturing,”IEEE Spectrum, vol. 20, no. 5, pp. 59–64,1983.

[37] T. Minoura, S. Pargaonkar, and K. Rehfuss, “Structural active objectsystems for simulation,” inProc. ACM OOPSLA’93, pp. 338–355.

[38] T. Mori and M. R. Cutkosky. Agent-Based collaborative design of partsin assembly. presented at Proc. DETC’98 ASME Design EngineeringTech. Conf.. [Online]. Available: http://www-cdr.stanford.edu/Pro-cessLink/papers/toshiba/MoriASME98.pdf

[39] A. Mowshowitz, “Virtual organizations,”Commun. ACM, vol. 40, no. 9,pp. 30–37, 1997.

[40] F. R. Noreils, “Toward a robot architecture integrating cooperation be-tween mobile robots: Application to indoor environment,”Int. J. Robot.Res., vol. 12, no. 1, pp. 79–98, Feb. 1993.

[41] OPC Foundation [Online]. Available: http://www.opcfoundation.org[42] D. Ouelhadj, C. Hanachi, and B. Bouzouid, “Multiagent architecture

for distributed monitoring in flexible manufacturing systems,” inProc.IEEE Int. Conf. Robotics and Automation, ICRA, 2000, pp. 2416–2421.

[43] J. L. Richmond and D. K. Pai, “Active measurement of contact sounds,”in Proc. IEEE Int. Conf. Robotics and Automation, ICRA, 2000, pp.2146–2152.

[44] R. Prins, Developing Business Objects. A Framework Driven Ap-proach. New York: McGraw-Hill, 1996.

[45] RosettaNet [Online]. Available: http://www.rosettanet.org[46] G. R. Rutledge, “The PC and its influence on robot controllers,” inProc.

IEEE Int. Conf. Robotics and Automation, ICRA, 2000, pp. 717–721.[47] Y.-P. Shan and R. H. Earle,Enterprise Computing With Objects. From

Client/Server Environments to the Internet. Reading, MA: Addison-Wesley, 1998.

[48] W. Shen and D. H. Norrie, “Agent-based systems for intelligent man-ufacturing: A state-of-the-art survey,”Knowledge Inform. Syst., Int. J.,vol. 1, no. 2, pp. 129–156, 1999.

[49] , “Implementing internet enabled virtual enterprises using collabo-rative agents,” inInfrastructures for Virtual Enterprises, L. M. Camar-inha-Matos, Ed. Norwell, MA: Kluwer Academic, 1999, pp. 343–352.

[50] G. S. Sukhatme and M. J. Mataric, “Embedding robots into the internet,”Commun. ACM, vol. 43, no. 5, pp. 67–73, May 2000.

[51] K. Sycara, A. Pannu, M. Williamson, and D. Zeng, “Distributed intelli-gent agents,”IEEE Expert (Special Issue Intell. Syst. and Their Appli-cations), vol. 11, pp. 36–4, Dec. 1996.

[52] Sun IPlanet [Online]. Available: http://iplanet.com[53] A New Approach to Distributed Computing [Online]. Available:

http://java.sun.com/products/javaspaces/whitepapers/dcpaper.pdf[54] Java 2 Platform Enterprise Edition (J2EE) [Online]. Available:

http://java.sun.com/j2ee/white/j2ee.pdf[55] The Java Technology Concept Car [Online]. Available:

http://www.sun.com/research/features/javacar[56] S. Tadokoroet al., “The robocup-rescue project: A robotic approach to

the disaster mitigation problem,” inProc. IEEE Int. Conf. Robotics andAutomation, ICRA, 2000, pp. 4090–4095.

[57] .NET Framework Essentials, T. Thai and H. Lam. [Online]. Available:0–596–00302–1, http://www.oreilly.comcatalog/dotnetfrmess2/

[58] S. Vinoski, “CORBA: Integrating diverse applications within distributedheterogeneous environments,”IEEE Commun. Mag., vol. 14, no. 2, pp.46–55, Feb. 1997.

[59] H. Yamaguchi, “A cooperative hunting behavior by mobile robottroops,”Int. J. Robot. Res., vol. 18, no. 9, pp. 931–940, 1999.

[60] A. F. Yassin and M. E. Fayad, “A survey of object-oriented applicationframeworks,” inDomain-Specific Application Frameworks, M. E. Fayadand R. Johnson, Eds. New York: Wiley, 1999, ch. 29.

[61] J. Waldo, “Object-Oriented programming on the network,” inProc.ECOOP’99, R. Guerraoui, Ed., 1999, LNCS 1628, pp. 441–448.

[62] W3C Consortium [Online]. Available: http://www.w3.org

Davide Brugali received the M.S. degree inelectronics engineering from the Polytechnic ofMilan, Milan, Italy, in 1994 and the Ph.D. degreein computer science from the Politecnico di Torino,Torino, Italy, in 1998.

In 1997, he spent one year at the Robotics Insti-tute, Carnegie Mellon University, Pittsburgh, PA, re-searching multiagent systems. He is currently an As-sistant Professor at the Facoltà di Ingegneria, Univer-sity of Bergamo, Bergamo, Italy. His main researchactivity is in techniques to build and reuse software,

such as design patterns, application frameworks, component development, andsoftware agents. He is also researching mobile robotics, multiagent systems,distributed systems, and constraint programming.

Dr. Brugali is Co-Chair of the IEEE RAS Technical Committee on Program-ming Environments in Robotics and Automation. His most significant publi-cations are inACM Computing Surveys, Communications of the ACM, and anumber of book chapters.

Mohamed Fayad received the M.S. and Ph.D. degrees in computer sciencefrom the University of Minnesota at Minneapolis.

He is currently a J.D. Edwards Professor and an Associate Professor of Com-puter Science and Engineering at the University of Nebraska, Lincoln.

Dr. Fayad is an Associate Editor and Columnist of theCommunications ofthe ACM(CACM) and Distinguished Speaker (IEEE Computer Society), andwas Editor-In-Chief for the IEEE Computer Society Press, 1995–1997. He wasa guest editor on six theme issues dealing with OO software development andapplications, and is currently working on three more. He has published arti-cles in IEEE SOFTWARE, IEEE COMPUTER, theJournal of Object-Oriented Pro-gramming, ACM Computing Surveys, and CACM on OO software engineeringmethods, experiences, design patterns, and management, and is the lead authorof several books.

distributed computing in robotics and automation

Documents