A Reference Architecture for Managing

8/12/2019 A Reference Architecture for Managing

http://slidepdf.com/reader/full/a-reference-architecture-for-managing 1/7

A REFERENCE ARCHITECTURE FOR MANAGING

VARIABILITY AMONG TELEOPERATED SERVICEROBOTS

Francisco Ortiz, Juan Ángel Pastor, Diego Alonso, Fernando Losilla and Esther de JódarSystems and Electronics Engineering Division, Technical University of Cartagena, Campus Muralla del Mar, s/n,

Cartagena, Spain

[email protected], [email protected] [email protected], [email protected], [email protected]

Keywords: Architectures, Fieldbus, robot control, teleoperation.

Abstract: Teleoperated robots are used to perform hazardous tasks that human operators cannot carry out. The purpose of this paper is to present a new architecture (ACROSET) for the development of these systemsthat takes into account the current advances in robotic architectures while adopting the component-orientedapproach. ACROSET provides a common framework for developing this kind of robotized systems and forintegrating intelligent components. The architecture is currently being used, tested and improved in thedevelopment of a family of robots, teleoperated cranes and vehicles which perform environmentallyfriendly cleaning of ship-hull surfaces (the EFTCoR project).

1 INTRODUCTION

Teleoperated mechanisms, such as robots, vehiclesand tools (or a combination of these), perform

inspection and maintenance tasks in hostileenvironments. The capabilities and the areas ofapplication of these systems grow from day to day, but so does their complexity. As stated in (Coste,2000), one way of dealing with this complexity is to

use architectural frameworks and tools that embody

well defined concepts to enable effective realization

of systems to meet high level goals.There have been numerous efforts to provide

developers with architectural frameworks of thiskind (Bruyninckx, 2002), (Nesnas, 2003), (Scholl,2001). The objects of this paper are twofold: to present an architectural approach to the developmentof control units for these systems and to present anexample of its use in the development of a realsystem. The architectural approach, ACROSET, is based on the latest advances in robotic architecturesand adopts a component-oriented approach.ACROSET offers a way to re-use the samecomponents in very different systems by separatingthe components from their interaction patterns. Italso provides a common framework for developingrobotized systems with very different behavioursand for integrating intelligent components. The

architecture is currently being used, tested andimproved in the development of a family ofteleoperated cranes and vehicles for environmentallyfriendly cleaning of ship hull surfaces (the EFTCoR

project).This paper is structured in six sections. Sectiontwo presents the characteristics of the applicationdomain which determine the architectural driversthat have guided the design of ACROSET. The thirdsection presents a brief description of the EFTCoRmissions and mechanisms. Sections four and fiverespectively describe the ACROSET architectureand two of its instantiations. Finally, section sixsummarizes the conclusions and future plans.

2 THE TELEOPERATION

DOMAIN

Teleoperated systems cover a broad range ofmechanisms that carry out inspection andmaintenance activities in hostile environments.Usually these systems perform a small number ofhighly specialized tasks. Such specialization implies:

• High variability of functionality and physicalcharacteristics.



• Different combinations of vehicles,manipulators and tools.

• A large variety of execution infrastructures,including different kinds of processors,

communication links and HMIs.• A large variety of sensors and actuators.• Different kinds of control algorithms, from very

simple reactive actions to extremely complexnavigation strategies.

• Different degrees of autonomy, from operator-driven systems to semi-autonomous robots.

And yet, despite all these differences, teleoperatedsystems are normally very similar from a logical point of view, having many common requirementsin their definition and many common components,either logical or physical, in their implementation.

These similarities allow the designer to define acommon architecture for all such systems. To beable to use such architecture for all developments isextremely useful. It allows rapid development ofsystems and reuse of a large variety of components,with concomitant savings in time and money.Considering the differences among the systemsmentioned above, it is clear that the main objectiveof the architecture is to deal with such variability.To achieve that, there are a number of points thatmust be considered:

• Very different systems should be able to use the

same components. This implies that thearchitecture should make a clear distinction between components and interaction patterns.

• The component implementations could besoftware or hardware, probably includingCOTS (Commercial off the Shelf).

• It should be possible to derive concretearchitectures for operator-driven systems andautonomous intelligent systems.

3 THE EFTCOR SYSTEM

A good example in teleoperation domain could be theEFTCoR project (EFTCoR, 2002), which addressesthe development of a family of robots whose missionis to retrieve and confine the paint, oxide andadherences from ship hulls. The EFTCoR system is part of the European Industry’s current effort tointroduce environmental friendly ship maintenance.Although the EFTCoR family of robots arespecifically designed for ship hull maintenance, they

still present a broad spectrum of behaviours anddegrees of complexity and as such provide anexcellent test bench for a reference architecture. Thesources of variability in EFTCoR are the following:

• Hull dimensions and shapes differ widely.• Different areas of any given hull impose very

different working conditions for robots.• Working areas differ in different shipyards or

even within the same shipyard.• There are operational differences between

cleaning small, discrete areas (spotting) and full blasting.

• Other hull maintenance operations can beincluded, such as fresh water washing and painting before and after coating removal.

The tremendous variety described abovegenerates very different problems, and these requiredifferent robotic systems, each suited to a given typeof shipyard, hull, part of the hull, operation, etc.

It may then be impossible to design a singlerobotic system to perform all tasks, but it is still possible to design the different robotic systems insuch a way that as many components as possible areshared. EFTCoR’s robotized systems consist of a primary positioning system capable of coveringlarge hull areas and a secondary positioning systemmounted on primary system that can position a toolover a relatively small area (4 to 16 m2). Different

combinations of primary/secondary/tool have beenconsidered and tested (see Fig. 1).

a) XYZ table & cherry-picker b) Scissor crane

c) Tower with a tool positioner d) Climbing vehicle

Fig. 1 Different solutions for grit blasting



Finally, it is important to stress that theEFTCoR is an industrial project and as such shoulduse components that are common in industrialfacilities (PLCs rather than work-stations, field

buses rather LANs, etc.)

4 THE REFERENCE

ARCHITECTURE

ACROSET ( Arquitectura de Control para Robots de

Servicio Teleoperados*) is a reference architecture

for teleoperated service robot control units. Thearchitecture emerged from previous works at theDSIE ( División de Sistemas e Ingeniería

Electrónica, Universidad de Cartagena, Spain)

(Iborra, 2003), (Ortiz, 2000), and is currently beingused in the EFTCoR project. ACROSET takesaccount of the sources of variability explained insections 2 and 3 and the architectural driversdeveloped to deal with them.

ACROSET is supposed to make very differentsystems to use the same components, and thereforethe first step was to define the rules and commoninfrastructure that would allow components to beassembled or connected. To that end, the concepts ofcomponents, ports and connectors were adopted asdefined in (Hofmeister, 2000). The connectorconcept allows components’ functionality to be

separated from their interaction patterns, becausesuch patterns contained within the connectors. Thenotation followed to describe the components, portsand connectors is inspired by the 4 views ofHofmeister (Hofmeister, 2000) and ROOM (Selic,1994), which extend the UML notation withstereotyped classes and special symbols (seesubsection 4.1.)

The subsystems defined by ACROSET areshown in Fig. 2. The first subsystem of thearchitecture, which should be present in everysystem, is the Coordination, Control and

Abstraction Subsystem (CCAS). The CCAS abstractsand encapsulates the functionality of the physicaldevices of the system. The CCAS is composed of virtual components which can be implemented ineither software or hardware, even consideringCOTS. This subsystem breaks down into severalcomponents distributed in hierarchical layers (seesection 4.1).

* Control Architecture for Teleoperated Service Robots.

To deal with operator-driven and semi-autonomous systems, an Intelligence Subsystem ( IS )is proposed. In this way, autonomous behaviourscan be added if necessary, interacting with the

functionality offered by the CCAS as another user.This separation of intelligence and functionalityenhances the modifiability and adaptability of thesystem to new missions and behaviours. Theintelligence can be combined with the operatorcommands depending on the application or mode ofoperation. A User Interaction Subsystem (UIS) is proposed to interpret, combine and arbitrate betweenorders that may come simultaneously from differentusers of the system’s functionality (CCAS ), since thesystem does not concern itself with the source of theorder.

Fig. 2 An overview of ACROSET subsystems.

Other important aspects besides thefunctionality or the intelligence of the systeminclude the safety and the possibilities ofconfiguration and management of the application.To differentiate between functionality per se and themonitoring of such functionality, a Safety,

Management and Configuration Subsystem (SMCS)

is proposed. Another function of this subsystem is tomanage and configure the initialization of theapplication.

4.1 The Coordination, Control and

Abstraction Subsystem (CCAS)

The CCAS of a given system comprises componentsthat are defined in four layers of granularity:• Layer 1: Abstract the characteristics of atomic

components, such as sensors and actuators.• Layer 2: Simple Unit Controllers (SUCs).• Layer 3: Mechanisms controllers (MUCs).

CCAS

Users

Devices

UIS

Stra-tegies

Coord

Control

Abstract Devices

Intellig. 1

React.

Intellig. 2

SMCSIS

Mngment

Safety

Config



• Layer 4: Robot controllers (RUCs).

The simplest components modelled by thearchitecture are the sensors and actuators, which aredefined at the lowest architectural level. The SUCcomponents model the control over the actuators(Fig. 3). For example, there will be SUCs defined tocontrol every joint of a given mechanism. The SUCgenerates commands for the actuator according to:• The orders that it receives from another

component (through the SUC_Control port).• The information it receives from the sensors.• Its installed control policy.

Fig. 3 MUC and SUC. 1 actuator.- N sensors.

The control policy is an interchangeable part ofthe SUC. For example, the ControlStrategy of agiven joint may be a traditional control (PID) or may be changed for a fuzzy logic strategy. The SUCsusually need to accomplish hard real timerequirements and are generally implemented inhardware. Where they are implemented in softwarethey impose severe real time constraints onoperating systems and platforms.

Defined at the third level of granularity is theMechanism Unit Controller (MUC). The MUCcomponent models the control over a wholemechanism (vehicle, manipulator or end effector).As Fig. 4 shows, the MUC is a logical entitycomposed of:• An aggregation of SUCs.• A Coordinator responsible for coordinating

SUC actions according to the commands andinformation that it receives.

• Its installed coordination strategy.

The coordination strategy is an interchangeable part of the SUC component. For example, theCoordinationStrategy of a given manipulator may be a particular solution for its inverse kinematics,

the coordinator strategy for a given vehicle could bea particular navigation strategy, etc.Although the architecture defines the MUCs as

relational aggregates, they can actually becomecomponents (hard or soft) when the architecture isinstantiated to develop a concrete system. Whetheror not the interfaces of the inner SUCs are directlyaccessible is a decision for the architectureinstantiation. In fact, although MUCs may beimplemented in either hardware or software, theyare very commonly commercial motion controlcards that constrain the range of possible commandsto its internal components. COTS elements limit the

flexibility of the approach, in the sense that they donot always provide direct access to their inner sub-components or to their inner state.

Finally, at the fourth level, the architecturedefines the RUC (Robot Unit Controller)component. The RUC component models the controlover a whole robot, for example a robot composedof a vehicle with an arm and several interchangeabletools. As Fig. 4 shows, the RUCs are anaggregation of MUCs and a global coordinator thatgenerates the commands for the MUCs andcoordinates their actions, according to the orders and

the information that it receives and its installedcoordination strategy.

Fig. 4. RUC: Robot Unit Controller.

This strategy is an interchangeable part of theRUC. For example, the CoordinationStrategy of a

strConfig

+ / MUC_Control~

Coordinator

+ / MUC_DataOut

MUC

+ / SUC_Control~ + / SUC_DataOut

< < d a t a >

< < d a t a >

< < c o n t r o

l

+ / sensorDataIn~ + / actuatorControl

+ / devDataIn~

+ / sensorDataOut + / actuatorControl~

+ / devControl

<<data>> <<control>>

Actuator Sensor n 1

Strategy

1

SUC n

Strategy

RUC_Control~

Coordinator

RUC_DataOut

RUC

MUC_Control MUC_DataOut

SUC_DataOut SUC_Control~

strConfig

< < d a t a

< < d a t a >

< < c o n t r o l > >

<<control>> <<data>>

Strategy

sensorDataIn~ actuatorControl

<<data>> <<control>

Actuator Sensor n 1

SUC

MUC

1

n

n



robot composed of a vehicle with a manipulatorcould be a generalised kinematics solution thatcontemplates the possibility of moving the vehicle toreach a given target. Like the MUCs, the RUCs are

logical components that can become physicalcomponents depending on the concrete instantiation.In general, the RUC is quite a complex componentthat comprises hardware and software componentsand can expose a wide variety of interfacesdepending on the complexity of the controlledsystem.

4.2 The Intelligence Subsystem (IS)

It is beyond the scope of this paper to give a detailedexplanation of the IS , but we do offer some

considerations at this point. The CCAS is well suitedto operator-driven systems and systems where thereactive or autonomous behaviour responds tosimple rules that can be added to controllers andcoordinators. However, there are systems where theautonomous behaviour is anything but simple. Insuch cases, the intelligent component needs tointegrate more information and access morefunctionality than what is embedded in a givencomponent. The approach adopted here is tosuperimpose “intelligent ” autonomous behaviourand operator-driven behaviour, and to provide themeans of integrating both and resolving the potential

conflicts by means of “arbitration” componentswhich merge commands from several sourcesfollowing different strategies and provide a uniquecommand to the goal component. This approachdoes not entail any change in the componentsdefined so far, but it does entail new sources ofcommands for them. Such “arbitrators” permits thegoal components not to change although newsources are introduced.

5 ACROSET INSTANTIATION ON

EFTCOR

The ACROSET architecture is being implementedon a real system, the family of robots in EFTCoR project. This section presents two instantiations ofthe architecture. As we will see, they have beenchosen to illustrate the suitability of ACROSET fordefining the concrete control architectures of twovery different systems.

5.1 ACROSET in teleoperated XYZ table

The first instantiation of ACROSET is used fordeveloping the control unit of a system composed ofa XYZ table (Fig. 1. a, c) holding the cleaning tool.This tool consists of an enclosed nozzle for making

the blasting and recovering of residues. The systemcan be driven by a human operator and it can also perform some autonomous tasks. The XYZ table issupported by a commercial crane whose control isnot considered in this instantiation.

Fig. 5. Components of CCAS in XYZ table Control Unit.

The components integrated in the Coordination,Control and Abstraction Subsystem (CCAS) areshown in Fig. 5. The RUC encloses all thefunctionality required to drive the XYZ table and thetool. The MUC and SUC included in the RUCcontrol the XYZ table and the blasting toolrespectively. The MUC coordinates three SUCs, onefor each axis of the table. In this case the actuatorsare logically placed inside the SUCs and areaccessed through the SUC interface. This is imposed by the system’s hardware architecture. In this case,COTS hardware controllers have been used tocontrol the electrical motors of the XYZ table.

Therefore, the hardware that is abstracted is notmerely an engine but a complete axis controller. Theactuator is hidden to the control unit and the SUC isthus a “hardware abstraction component” contained in a MUC. The SUCs that control the axestherefore have a software part and a hardware part.The RUC and the MUC are implemented entirely insoftware.

Following ACROSET, the intelligence of thesystem, like the fault and configurationmanagement, is located outside the CCAS. The two

RUC_Control~

Coordinator

RUC_DataOut

RUC

MUC_Control MUC_DataOut

SUC_DataOut SUC_Control~

strConfig

< < d a t a

<

< d a t a > >

<

< c o n t r o l > >

Strategy

sensorDataIn~ actuatorControl

<<data>> <<control>

eValve switch n 1

XYZtable:MUC

1

1

blastTool:SUC 1

<<data>>

n

switch

Axis:SUC 3

Coordinator 1



are respectively included in the Intelligence

Subsystem (IS) and the SMCS, as shown in Fig. 2.The real intelligence included in the IS variesconsiderably from system to system. In this

particular case the IS interprets a pre-programmedsequence of motions and orders that have beengenerated by a vision system. The vision system isan external system, running on a PC, that analysesthe surface to be cleaned, generates trajectories anddelivers them to the IS, which in turn delivers themto the UIS and supervises their execution. A humanoperator can supervise the movements commanded by the vision subsystem and take corrective action by means of a joystick. An arbitrator situated in theUIS determines which is controlling the system at alltimes (note that the CCAS only receives orders fromone channel coming from the UIS).

In response to the special industrial requirementsof the EFTCoR project, the system has beenimplemented using a PLC† SIMATIC S7-300 (4 infigure 6) and a Field-Bus (PROFIBUS-DP, 2 infigure 6). The development environment is “STEP7” from SIEMENS (SIMATIC, 2002). Each SUC,MUC and RUC has been translated to PLC Function

Blocks (FBs) (SIMATIC, 2002). With the option ofFB instantiation in SIMATIC S7-300 series, it is possible to program the PLC with a philosophy thatis close to the object-oriented paradigm (each FBacts as a class which can be instantiated). Forinstance, a generic axis controller (SUC) has beendefined to create three instances, the controllers(SUCs) for the X, Y and Z axes, each with their particular features. In this case, the SUCs implementinterfaces to the hardware controllers (drivers) of theelectrical motors (6 and 7 in figure 6)

Fig. 6. Hardware architecture

The PLC and Field-Bus based solution adoptedis based entirely on standard industrial equipment(SIEMENS devices interconnected via PROFIBUS-DP), which facilitates the integrability,

† Programmable Logic Controller

interoperability and maintainability of the completesystem.

5.2 ACROSET for a teleoperated vehicle

The second instantiation is a caterpillar vehiclecapable of scaling a hull thanks to permanentmagnets (Fig. 1- d), carrying a manipulator thatholds a cleaning tool. Like the previous system, thevehicle can be driven by a human operator and also performs some autonomous tasks, such as obstacleavoidance and simple path execution.

Fig. 7. Components of CCAS in climbing vehicle

Fig. 7 shows the CCAS instantiated for the

control unit in this system. As can be seen in thefigure, two different MUCs have been implemented:one to control the vehicle and another to control themanipulator. The first contains one SUC to controleach of the electrical motors that move the vehicle.On the other side, the manipulator MUC coordinatestwo SUCs, one for each manipulator axis. Thevehicle uses the same tool as the XYZ table, so thisSUC is conceptually the same, but it has beenimplemented in a different way.

Unlike the previous case, the motion controllersare not implemented by means of COTS hardwarecomponents, but by means of Ada packages that

implement the interfaces defined by ACROSET. Inthis case the implementation allows direct access tothe hardware without mediation by any SUC.However, as in the previous case, the application has been designed to allow either a human operator oran external system to access the CCAS functionalitythrough the UIS. Two different intelligent behaviours have been added to the IS: obstacleavoidance and path execution. The components ofthe IS that implement these behaviours obtain theinformation they need from the vehicle sensors and

<<control>>

eValve 1

RUC_Control

Coordinator

RUC_DataOut

strCon

< < d a t a > >

< < c o n t r o l > >

Strategy

<<data>>

switch 1

1

1

blastTool:SUC 1

<<data>>

2 encoder

Axis:SUC 2

Coordinator 1

1

wheel:SUC 2

Coordinator 1

<<data>> <<control>>

eMotor encoder 2 2

<<control>>

eMotor 2

RUC

(1) PG/PC

(2) Field-Bus

(3) Operator Panel

(4) PLC

(5) Sensors(6) Driver

(7) Motor



generate commands to the CCAS. Integration between these commands and the operatorcommands is resolved by an arbitrator in the UIS.

The execution platform is an on-board

embedded PC. The PC/104 bus (PC104, 2004) is awidely used industrial standard with manyadvantages, such as vibration-resistance, modularity,mechanical robustness, small form factor (96 x 115mm), low power consumption, etc. Moreover, it can be easily extended with boards that provide the kindof functions needed by robots (digital and analogueI/O, motion control, PCMCIA expansion, etc). Thechosen OS is RTLinux (Baravanov, 1997), withwhich makes it is possible to have a real-timeapplication running while retaining all the power ofa Linux distribution (though with some restrictions)underneath.

6 CONCLUSIONS AND FUTURE

WORKS

The use of a common architecture for a domain orfamily of systems allows rapid developments andthe reuse of components. This paper has presented acommon architectural framework for thedevelopment of teleoperated service robots controlunits (ACROSET), and also two applicationexamples in the context of the EFTCoR project that

show the ability of ACROSET to cope with theneeds and requirements of very different systems.The separation of the conventional functionality ofthe systems (CCAS ) from the intelligent behavioursgreatly facilitates the addition of new functionalitiesand the maintenance of applications. The maindrawback is the lack of language support forexpressing a component-oriented style of programming.

ACKNOWLEDGMENT

The DSIE wishes to thank the Spanish Government(CICYT) and the Regional Government of Murcia(Seneca Programmes) for their support: TIC2003-07804-C05-02 and PB/5/FS/02.

REFERENCES

Barabanov M.. "A Linux-based Real-Time OperatingSystem". Master Thesis, New Mexico Institute of

Mining and Technology, Socorro, New Mexico, June1997.

Bruyninckx, H., Konincks, B. and Soetens, P., “ASoftware Framework for Advanced Motion Control”,Dpt. of Mechanical Engineering, K.U. Leuven.

OROCOS project inside EURON. Belgium. February2002. Retrieved October 12, 2003 fromhttp://www.orocos.org

Coste-Manière, E. and Simmons, R., “Architecture, theBackbone of Robotic System”, Proc. of the 2000

IEEE International Conference on Robotics &

Automation, San Francisco, April 2000.EFTCoR - Environmental Friendly and Cost-Effective

Technology for Coating Removal. V FrameworkProgram GROWTH G3RD-CT-00794. 2002-2005

Gamma E., Helm R., Johnson R., Vlissides J., “DesignPatterns: Elements of Reusable Object OrientedSoftware”, Addison Wesley, Reading Mass. 1995.

Hofmeister, C. Nord, R., Soni, D., “Applied Software

Architecture”, Addison-Wesley. ISBN 0-201-32571-3.USA. January 2000.

Iborra, A. Pastor, J.A., Álvarez, B. C. Fernández andFernández-Meroño J. M., “Robots in RadioactiveEnvironments”, IEEE Robotics and Automation

Magazine, vol. 10, no. 4, pp. 12-22, December 2003. Nesnas, I. et al, “CLARAty: An Architecture for Reusable

Robotic Software”, Jet Propulsion Laboratory, NASA,Carnegie Mellon University, March 2003.

Ortiz, F.J. et al “GOYA: A teleoperated system for blasting applied to ships maintenance”. 3rd

International Conference on Climbing and Walking

Robots. CLAWAR´2000. October, 2000.Scholl, K.U. Albiez, J. and Gassmann, B. “MCA – An

Expandable Modular Controller Architecture”,Karlsruhe University, Germany, 2001.

Selic, B. Gullekson G., Ward P.T., “Real-Time Object-Oriented Modeling” (ROOM). John Wiley and Sons, New York. 1994.

SIMATIC - Working with STEP 7 5.2. ref. 6ES7810-4CA06-8BA0. SIEMENS manuals. 2002.

PC104. Retrieved May 1, 2004, fromhttp://www.pc104.org

A Reference Architecture for Managing

Documents

Transcript of A Reference Architecture for Managing