A Task-based Approach to Generate Optimal Software-Architecture for Intelligent Service Robots

(1)

16th IEEE International Conference on Robot& Human Interactive Communication August 26 ^- 29, 2007 / Jeju, Korea

A Task-based Approach to Generate Optimal Software-Architecture for Intelligent Service Robots

Yu-Sik Park', In-Young Ko2, and Sooyong Park3

"2Yu-Sik Park andIn-Young Ko,School of Engineering, Information and Communications University, Daejeon, Republic of Korea,e-mail: (yusikpark, iko)@icu.ac.kr

3SooyongPark, Department of Computer Science, Sogang University, Seoul, Republic of Korea, e-mail: syparkgsogang.ac.kr

Abstract- In order to provide services morereliably, intelligent service robots need to consider various factors, such as theirsurrounding environments, user'schanging requirements, and constrained resources. Most of the intelligent service ro- botsarecontrolled basedon atask-based control system,which generatesataskplan that consists ofasequenceofactions,and executes the actions byinvoking the corresponding functions.

However,this task-based control system did notseriously consider resource factors even though intelligent service robots havelimited resources (limited computational power, memory space, and network bandwidth). Ifwe consider these factors duringthe taskgeneration time,thecomplexityof theplan may becomeunmanageable.Therefore, inthis paper,we proposea mechanism for robots to efficiently use their resources on-demand. We define reusable software-architectures corresponding to each action of a task plan, andprovideawayof usingthelimited resources byminimizingredundantsoftware components. We conducted an experimentof this mechanism for an infotainment robot. The experiment shows the effec- tiveness ofourmechanism.

I. INTRODUCTION

Anintelligent service robot needsto supportrobustness ofcontinually providing services forusers atrun-time. To accomplish this, many researchers have developed tech- niques for robots to deal with changing tasks in the real world [1, 2]. They developed robot controlsystems togen- erate aplan for atask. The control system generates aplan for robots to move from aninitialstate to agoal state. The plan consists of actions that the robot needs to perform to accomplish the task. Such plan isnormally representedina DAG-basedstructure.

Task-based robots generally use three-layer software architecture as depictedinFig. 1. The Decision Layergen- erates atask plan and supervises the execution of theplan.

The Execution Layer is in charge ofan execution of the actual functions and controls for the plan. The Function Layer provides basic functions such as perception and navigation functions [3].

However, this traditional architecture has three limita- tionsasfollows:

* Inthisthree-layer architecture, as we addmore condi- tional factors to consider, the complexity of the plan generation becomes unmanageable. Ifthe number of factors increases, the depth of the plan graph grows exponentially. This would tremendously increase the planning efforts [4].

* This architecture does not suggest any way to efficiently use the limited resources of the robots by maintaining only the essential functions that are re- quiredtoperformatask.

* The decisionlayer decides statically which functionsto use rather than it chooses the functions dynamically basedonenvironmental condition.

Todeal with theseproblems, the SHAGEframework has beendeveloped. The SHAGE framework enables robotsto analyze generated task plans and select appropriate software architectures for the actions in aplan. The framework also provides a mechanism to reduce resource consumption by identifying and removing redundant functionalities in the selected architectures. By using this mechanism, we could successfully reduce the complexity of the plan generation, andovercomethe limitedresourcesof robots.

Therestofthepaperisorganizedasfollows.InSection2, webriefly explain theSHAGEframework.InSection3,we elaborate onthe task-based architecture generation mechanism. Section4presentsthe experiment thatwe conducted.

Section5 discuses about related works that handleresource variability issues. We drawaconclusion andpresentfuture worksinSection6.

II. THESHAGEFRAMEWORK

SHAGEisaframeworktosupportself-managed software for intelligent service robots, stands for Self-Healing, Adaptive, and Growing software [5]. Ourprevious research aimedtoadaptrobot softwaretovarious situationsby using run-time software architecture anda componentreconfigu- ration mechanism. However, our purpose inthispaperisto provide softwaresystemthathelps intelligent service robots provide services withoutahitch.

Fig.1Three-layersoftware architecture for robots

WB1-5

(2)

WibEu\PeLc

ca

A4s.fCxct7ses1asdctiskpl*mtaskmDdd)

... ... .....

C4pntMxitnlMiic

Fig.2Role of the SHAGE framework

The SHAGE framework is located between the decision layer (deliberative layer) and the execution layer (sequenc- ing layer). The framework plays a role ofa configuration manager as depicted in Fig. 2. The configuration manager has two roles: component management and configuration management. Component management isto manage components at run-time by loading and unloading components for a plan. Configuration management is to generate and reconfigure software architecture instances. Inrealizing this framework, the positioner is added to our framework. The positioner is responsible for assigning selected components to SBCs (Single Board Computers). Thispaperfocuses on selecting and merging sub-architectures forataskplan.

III. TASK-BASEDARCHITECTUREGENERATION Inordertoefficientlyuselimitedresourcesofrobots, it is importanttominimize redundant software components that provide similar functionality. Therefore, we propose a task-basedapproachtoreduce theresource consumption by identifying redundant components inrobot software architectures. We define a reusable sub-architecture corre- spondingtoeach action ofaplan.

The architecturegeneration phase consists of threesteps:

sub-architecture search, architecture consolidation, and concretearchitecturegenerationasdepictedinFig.3.Inthe sub-architecture search phase, the given task plan is ana- lyzed and sub-architectures are selected. Inthe architecture consolidation phase, the selected sub-architectures are merged into a single architecture by collapsing similar functionalities.Finally, componentinstancesare selected in theconcretearchitecturegeneration phase.

The sub-architecture search and architecture consolidation phases deal with abstract architectures. Search andin- ference inthese steps are based on anontology-basedrep- resentation. Inthis section,we explain the ontology thatwe constructed for these phases, and the detail steps of the phases.

AcnOntoloy & hitectue Ontoly ComiponentOnlogy (Properti Qualityat ibute) (Properes Resources

Fig. 3 Task-based architecture generation phase

A. Ontology description model

Therearethree mainontologies thatwe use inthe architecturegeneration phases: the'Action', 'Sub-architecture', and'Components' ontologies as showninFig. 4. The Ac- tion ontology describes services which robots canprovide.

Navigation, object recognition, and speech recognition are example servicesinthisontology.

The Sub-architecture ontology has information about the sub-architectures thatprovide functionalitytosupportan action. Each class of the Sub-architecture ontology includes a description about which actions are supported by the sub-architecture. This enables robotstoinferappropriate sub-architectures for an action in a plan. In addition, this ontology keeps detail architecture descriptionsinaproperty.

This architecture description specifies components and connectorsthatareneeded for thearchitecture, and relations amongthem. The components specified inthe architecture description are associated with the classes in the Compo- nentontology (see Section3.2fordetails).

The 'Component' ontology is constructed based on the functionality ofcomponents. Thisontology is usedtoselect component instances that are requiredto concretize a consolidated architecture. This ontology also allows robots to identify alternative components thatprovide similar functions. In addition, the Component ontology includes descriptions ofresources constraints such as computational power, memory space, and network bandwidth ofcomponents. By using this information, we can choose a set of component for an architecture such that the components optimize theresourceconsumption.

B. Sub-architecture search

Ataskplan consists ofa sequenceof actions and condi- tional statements. Tomake robots operate accordingtothe generatedplan, actions inthe taskplan needtobeidentified and their corresponding sub-architectures need to be selected. Ataskplan from the decision layer specifiesneces- saryactionstoperform. Sub-architectures for aspecificac- tioncanbe selectedby using the Sub-architecture ontology.

There canbemultiple sub-architectures thatsupport an action. Among the candidate sub-architectures, the robot se- lects a specific one that satisfies quality requirements ofa userand minimizes theresourceconsumption.

(3)

actionsupported 1 hitectureDeskriplji

*required components

*configuraton

omonOnentDesrptio 1 generalinforrnatin

Input/output pre/postconditons

requiredreE

max-vaIlue max a~LBm

I 1

I

^MemorFy ^BandvAt

F

'lasspa

X/11

bClssOf fsources

ax-_alu

3CPUI

CPI

Fig.4Ontology description model

A sub-architecture is an abstract architecture corre- spondingto anaction. Itspecifies aset of abstractcompo- nents and their connections. That is, a sub-architecture specifies functionality ofcomponents and relations among the constituent components. Atthe architecture consolida- tionphase explained in Section III. D, specific component instances are selected for the abstract components in a sub-architecture. Inthisway,multiple implementations ofa sub-architecture canbeproducedby selecting differentsets ofcomponentinstances.

Usually, some actions are used in multiple task plans.

Therefore, bydefining asub-architecture foranaction, we canmaximize thereusability ofthesub-architecture, and the componentsthat constitute the sub-architecture.

C. Consolidated architecturegeneration

The selected sub-architecturesintheprevious phase need to be merged while reducing redundant components that provide similar functionalities. The hierarchy of the Componentontology is usedtoidentify similarity between component functionalities. Component functionalities in a higher level in the Component ontology subsume their lower-level functionalities. In other words, higher-level functionalities are more general than the lower-level functionalities intheontology hierarchy. Similarcomponents in different sub-architectures can be identified by using the following relations:

* Equivalence relation: components in different sub-architectures correspondto the same class inthe Component ontology. In other words, components provide thesamefunctionality.

* Subsumption relation: one component in a sub-architecture provides more specific functionality thanacomponent inanother sub-architecture.Inother words,theyappear inthesameparent-child pathinthe Component ontology hierarchy.

Forexample, whentwo sub-architecturesare selectedas showninFig.5,thecomponent'c12'ofthe sub-architecture 1 and the component 'c23' of the sub-architecture 2 canbe merged because 'c12' isequivalentto 'c23', and 'cll' of the sub-architecture 1 and 'c22' of the sub-architecture2canbe merged because 'clI' subsumes'c23'.

D. Concrete architecturegeneration

Since a consolidated architecture is an abstract architecture, componentinstances needtobe selected andasso- ciated to the architecture to be executed. Components are selected basedonexpectedresourceconsumption. The ex- pectedresourceconsumption ofacomponentis describedin the 'resource' property of theComponent ontology. Ex- pected resource consumption ofa component is evaluated by using off-line simulation. The 'positioner' of the SHAGEframework monitorsa resource statusofSBCsand decides components to use among the selected candidate components. The 'positioner' also deploys the selected components to SBCswith considering theresource status of the SBCs and the totalresourceconsumption of the selected components. We will not explain the detail of this component-deployment issueinthispaper.

sub architecture1

XC !=

Iu

Componentontology

Subsumption relation 'IF\

Equivalence relation

Fig5Determination of similarfunctionality

subClasOf

(4)

IV. IMPLEMENTATION

In this section, we explain how sub-architectures are represented formally, and describe the implementation de- tails of the architecture broker and thecomponentbroker.

Sub-architectures are described in Acme, which is a simple, generic architecture description language that can be usedto specify structure andproperties of software architecture [6]. We use Acmebecause itprovides powerful way ofspecifying various properties of architectural ele- ments.

Fig. 6 is an example of sub-architecture description for a navigation function. The navigation sub-architecture consists of 'Coordinator', 'Localizer', 'PathPlanner', 'Map- Builder', and 'MotionControl'. The functionalities of those components are specified in the property construct. This property specifies the URI ofa component-ontology class for itscorresponding functionality.

OWLFiles N DOM! OWLFM"

Fig. 7 Broker architecture

The entire process of task-based architecture generation canbe demonstrated through the visualization unit of the brokersasshowninFig.9.TheGUIconsists ofthree views:

the ontology view (theupper side), architecture view (the lower-left side), and candidate component view (the lower-right side). The ontology viewpresents anaction that is currently focused, and the selected sub-architectures, and their constituent components. The architecture view shows agraphical structure ofa sub-architecture and its architecture description in Acme. The candidate component view shows theresourceproperties of the candidate components for the consolidated architecture.

V. RELATEDWORKS

Fig. 6Anexample of sub-architecture description

Fig. 7 shows the architecture of the architecture and the componentbroker. Whenataskplan is given from the decision layer, the message handler finds necessary actions and then sends them to the architecture brokering engine.

The architecturebrokering engine thenaccessesontologies stored in the repository to search and consolidate sub-architectures. The brokering engines are implemented in Java, and use the Jena library which provides APIs to accessandmanageontology-based models [7].

Finally, the componentbrokering engine searches candidate components for a selected sub-architecture. Infor- mation about the selected sub-architecture and required components is packaged by the service information gen- eratorandsent totheconfigurationmanagerinthe SHAGE framework. The visualization unit graphically presents brokeringstagesand architecture consolidationprocess.Fig.

9shows thescreenshot of the visualization unit.

Theontologiesarecreatedby using theProtegeontology editor [8]. The onologies are described inRDF (Resource Description Framework) as depicted in Fig. 8. RDF is a framework for representing semantic information on the Semantic Web. RDF descriptions of sub-architectures and componentsare storedinarepository system [9].

Ubiquitous computing environment includes similar factors to consider as we do for intelligent service robots.

The Auraproject developed a self-adaptive computing in- frastructure that automates the configuration and recon- figurationofheterogeneous computing environments [10].

Auraprovides users with services that matchrequired ser- vicequalities by doing optimalresourceallocation.

Jie, etal. atthe Microsoft research instituteproposedan approachto share intermediate sensing and computing re- sults amongtasks[11]. Inthisresearch, they experimented with network devices called Microserver that accept users' tasks. Microserver is constrained by CPU speed, memory size, and communication bandwidth. Inthis research, they identified overlapping operations from multiple tasks and shared intermediate resultsamongtasks.

The abovetwo researchesare similarto ourresearch in terms ofatask-based approachtohandleresourcevariabil- ity. However, while they regard applications as a recon- figurable unit, we consider components and sub-architectures asreconfigurationunits.

r _rPo6 ₁_CIMALSSATHr

abu;'&o*Sivii

_1'A.1.._t ^rn₄ao~instanc 2i ¹⁵

. 1is XI ii rdy \IAONINH NMLemsOXISM ba- NM rbotbr:COMPONENTiSDE!SCRtITItON

PATfP'{-SIAM.SteeoIS MtiXF]iswnba)iisedSIAMnl`X[1

to,ilboCMPONEN"r-NAME=SLAM"'

fdfi.1abdi 1Si1vennLQt9 iance 0l5i,>

<rdftype ^td^eiirVm'uoV isionbadMapBi^dir

Lg

A l

Fig. 8 An example of a component description written in RDF

(5)

Fig.9 GUIof the brokers

Inaddition to resource constraints, Volpe, et al. at Cali- fornia Institute of Technology proposed a two-layer architecture for roboticstomake existing components for robots be reused [12]. In this research, they decreased the complexity of component development for robots by using object-oriented design in a function layer and by making ab- stracted components provide extensibility ofsystems. This research aims to enable application developers to efficiently developnewcomponents by using the existing ones.When componentsfor robotsaredeveloped under this environment, it enables robot to select and acquire various existing components.

VI. CONCLUSION AND FUTURE WORK

Inthispaper wedescribedatask-based approachto generate optimal software-architecture for intelligent service robots. Tomake intelligent service robots reliably provide their services with the limitedresources, wehavedeveloped an architecture broker and a component broker. Our approach includes anarchitecture generation mechanism that selectsappropriate sub-architectures andcomponentsfor the actions specified in a task plan. We defined reusable sub-architecturescorrespondingtoeach action ofataskplan, andproposed away to select sub-architectures andcompo- nents to produce concrete architectures. Intelligent service robots, eventhough theirresources arelimited, needtopro- vide various services for theusers. Separatingresource fac- torsfrom the taskplan generation reduces the complexity of taskplan generation dramatically.

However, inadditiontothetopological optimization that we presented in this paper, we are currently working on developingatemporal optimization method. Itwillprovide

the capability ofpreloading necessary components that are needed in a temporal window of a plan. Also, it will help robots decide whencomponents are no longer needed and need to be unloaded. This temporal optimization will be possible byanalyzing the temporal relation between actions ofatask plan.

VII. ACKNOWLEDGMENTS

This research wasperformed for the Intelligent Robotics Development Program, one of the 21st Century Frontier R&D Programs funded by the Ministry ofCommerce, In- dustry andEnergyofKorea.

VIII. REFERENCES

[1] R. Alami,R.Chatila, S. Fleury, M. Ghallab,F. Ingrand,AnArchi- tectureforAutonomy, The International Journal ofRoboticsResearch, Vol. 17,No.4, 315-337.

[2] E. Gat. OnThree-Layer Architectures. InD. Kortenkamp,R. Bon- nasso, and R. Murphy, editors, Artificial Intelligence and Mobile Robots,Boston,MA, 1998.MITPress.

[3] ChuXin Chen and Mohan M.Trivedi,TaskPlanningand Action Co- ordination inIntegrated Sensor-Based Robots, IEEETransactionon SYSTEMS, MAN, AND CYBERNETICS, Vol. 25, No.4, APRIL 1995.

[4] Jayaputera, G.; Loke, S.; Zaslavsky, A., Performance evaluation of dynamically assembledmultiagentsystems, IntelligentAgent Tech- nology, IEEE/WIC/ACM International Conference on, 19-22 Sept.

2005Page(s):451^-454.

[5] DongsunKim, SooyongPark, Youngkyun Jin, Yu-Sik Park, In-Young Ko, Kwanwoo Lee, Junhee Lee, Yeon-Chool Park, Sukhan Lee.

SHAGE: AFramework forself-managedRobot Software, Interna- tional ConferenceonSoftwareEngineering, Proceedingsof the 2006 internationalworkshoponSelf-adaptation and self-managingsystems, Shangai, China.

[6] DavidGarlan, Robert Monroe, DavidWile,Acme:ArchitecturalDe- scription ofComponent-Based Systems, Proceedings of the 1997

(6)

conference of the Centre for Advanced Studies on Collaborative research, Toronto, Ontario, Canada.

[7] Jena Semantic Web Framework, [8] What isProtege?, in f

[9] Hyung-Min Koo, In-Young Ko. A Repository Framework for Self-Growing Robot Software, Proceedings of 12th Asia-Pacific SoftwareEngineering Conference (APSEC'2005), Taiwan,December 2005.

[10] Joao Pedro Sousa, Vahe Poladian, David Garlan, Bradley Schmerl, MaryShaw, Task-based Adaptation for Ubiquitous Computing,IEEE

Transactions on Systems, Man and Cybernetics, Vol. 36, 328-340, May2006.

[11] Jie Liu, Elaine Cheong, andFengZhao, "semantics-basedoptimiza- tion across uncoordinated tasks in networked embedded systems"

Proceedings of the 5th ACM Conference on Embedded Software (EMSOFT 2005), September 18-22, 2005, Jersey City, New Jersey, [12] R.USA.Volpe,etal., "TheCLARAtyArchitecture forRoboticAutonomy."

Proceedings of the 2001 IEEE Aerospace Conference, Big Sky Montana, March 10-17 2001.