Services

Development of a Scalable Agent Architecture for Constrained Devices

Description
Thesis to obtain the Diploma Degree at the TU Berlin Development of a Scalable Agent Architecture for Constrained Devices Marcel Patzlaff April 11, 2007 DAI Labor Technische Universität Berlin Fakultät
Categories
Published
of 77
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Transcript
Thesis to obtain the Diploma Degree at the TU Berlin Development of a Scalable Agent Architecture for Constrained Devices Marcel Patzlaff April 11, 2007 DAI Labor Technische Universität Berlin Fakultät IV - Elektrotechnik und Informatik Prof. Dr. Sahin Albayrak Die selbständige und eigenhändige Anfertigung versichere ich an Eides Statt. Berlin, Zusammenfassung In dieser Diplomarbeit wurde ein Rahmenwerk entwickelt welches für eine Vielzahl von Rechnersystemen verwendet werden kann. Es ist eine Agentenarchitektur, die die Entwicklung skalierbarer Agenten unterstützt. Diese Agenten können, mit keinem oder nur geringem Anpassungsaufwand, auf allen unterstützten Geräten ausgeführt werden. Die Implementierungssprache ist hierbei Java weshalb jedes Gerät über dessen virtuelle Maschine verfügen muss. Das Programmiermodel offenbart einige Unterschiede zu anderen Agentenarchitekturen. Der Entwickler implementiert hier keine Agenten-Klasse sondern dessen funktionale Elemente. Die Zusammensetzung und Ausführung sowie die Nebenläufigkeitsangelegenheiten werden dabei dem Rahmenwerk überantwortet. Auch die Agenten-Hüllen sind Bestandteil davon. Diese Bevollmächtigung ermöglicht erst die Skalierbarkeit der Agenten. Das Rahmenwerk wird für alle verschiedenen Gerätearten maßgeschneidert, sodass deren Ressourcen am effizientesten genutzt werden. Die funktionalen Elemente des Agenten werden stattdessen nur einmal implementiert und sind überall lauffähig. Abstract In this thesis a framework was developed that is applicable on a wide range of computing devices. It is an agent architecture that supports the development of scaleable agents. These agents can be executed on all supported devices with none or least adaptation effort. The implementation language used here is Java and thus the presence of a its virtual machine on a device is mandatory. The programming model is slightly different to that of other agent architectures. Here the developer does not implement an agent class directly but its functional elements. The composition and execution as well as the concurrency issues are left to the framework. Also the agent hulls are part of it. This delegation in the firth place ensures the scalability of agents. The framework is tailored to every different device class to exploit the resources most efficiently. The functional elements of the agent instead are implemented only once and are applicable everywhere. Acknowledgements I would like to thank B. Hirsch, A. Heßler for their support and confidence. Furthermore I thank E. Tuguldur for his contest implementation and continuous feedback. The DAI Labor of Technische Universität Berlin provided a comfortable working environment. Special thanks go to my parents who made my study possible. Contents 1 Introduction Motivation Portable Applications Steering and Automation Problem Statement Goals Outline Background Agents Meaning Distributed Artificial Intelligence Middleware Embedded Systems Related Work Native Approach Tiny Microthreading Operating System (TinyOS) TinyLIME Interpreted Approaches Java 2 Platform Micro Edition (J2ME) JControl Lightweight Extensible Agent Platform (LEAP) Extendable Mobile Agent Architecture (EMAA) FarGo-DA Specialised Systems Analysis and Design Implementation Language System Features and Functionalities Modularity Concurrency Control Flow and Lifecycle Management i ii CONTENTS Communication Structuring Use Cases Create Agent Destroy Agent Process Event Reconfigure Agent Send Message Open Communication Link Concept Approach Architecture Overview Environment Agent Reactive Agent Component Container Agent Elements Rules Producers Consumers User Interface Creator Services Components Communication Infrastructure Connections Scalability Optimisation Configuration Additional Tools Configurations Preprocessing Class Generation Test and Evaluation Scenario Implementation Results Performance Memory Consumption Conclusion Summary Future Work List of Figures 3.1 The main architectural components of TinyLIME. Taken from [CGG + 05] An example JADE platform. Taken from [BB01] The Structure of a Complet Reference. Taken from [HBSG99] Architecture for ToothAgent. Taken from [BGF05] Architecture for KORE. Taken from [BCS03] Minimal Lifecycle of an Agent Identified Entities for the Architecture Use Case Diagram: Lifecycle Subsystem Use Case Diagram: Communication Subsystem Main Components of the Architecture Overview of the Architecture Overview of a Reactive Agent Overview of a Component Container. Only additional communication/invocation links are shown Communication Infrastructure - A single environment with two example agents is shown. The left side illustrates the service management part and the right side depicts the message capabilities The Contest s World Model iii iv LIST OF FIGURES Chapter 1 Introduction The first chapter introduces to the topic of this thesis - the development of a scaleable agent architecture. First the profit of such a system is examined. In this context the current market for computing devices of various kinds is considered to identify hardware platforms that might benefit of the proposed architecture. Thereafter the problem is summarised and some basic goals are presented. The last section provides the outline of the thesis with short introductions to the following chapters. 1.1 Motivation Computers have become an essential part of our life and are available in different types for different purposes. These range from stationary workstations and PCs over portable computers like mobile phones and PDAs to embedded systems. The main difference between them are the capabilities and their visibility to potential users. To support users and developers in at least two different cases, an scalable agent architecture is feasible Portable Applications Imagine a personal assistant agent. It manages the time schedule of his owner and gathers news for him. The user profits most from such an agent, if he is able to take it to his portable device. On this device the agent drives his computations down and switch to an reactive mode. So on the way the user can access the assistant s informations while the battery power of his device is preserved. Later on, back at the workplace, the agent should migrate to the desktop machine to switch back to a proactive mode and to continue gathering news. Without the scalability of the agent this is not possible. Of course the operating system (or virtual machine) on the device should support the migration of applications. Handheld computers like PDAs and SmartPhones are appropriate for this scenario. 1 2 CHAPTER 1. INTRODUCTION Steering and Automation The agent programming paradigm is well-fitted to implement steering functionalities for automation purposes. In recent years consumers are supported with technology to automate concerns in their home. For example there are embedded systems with different sensors available to measure heating, lighting and humidity conditions as well as cameras to record intrusions and so forth. These should be controlled automatically for example by autonomous agents. Some systems are powerful enough to host an operating system and applications directly (for example the SunSPOTs 1 ). Others support only a wired or wireless communication interface with which the data can be obtained. Thus a so-called sensor network has to tackle with different types of connectivity and should support a common communication abstraction for steering agents. So here, the focus for the architecture lies on the communication infrastructure and the simplification of agent development. 1.2 Problem Statement In this thesis the attempt is made to develop an architecture that support the implementation of scaleable agents 2. Scalability is an important issue in the development and classification of hardware systems and also of software systems. For this thesis the scalability of software systems is relevant. As stated in [Det01] there are several types of scalability for software systems: Total Dynamic Scalability Software systems can be adjusted to the underlying hardware at runtime. requires the system to be modular and capable of changing modules This Partial Dynamic Scalability Adjustment of software systems requires a restart. Static Scalability Software systems have to be recompiled to be fitted to the target hardware. So the total dynamic scalability is most appealing yet it cannot be realised for every system. One have to keep in mind that the capabilities of a software system depend on the capabilities of the underlying runtime environment. The software system can run natively and thus directly upon the operating system or in a virtual machine like the Java Runtime Environment (JRE) or the Common Language Runtime (CLR). It is more challenging but possible to develop native software that is totally dynamic scaleable. But native software will not run on devices with at least another operating system on them The term agent is somewhat overloaded and spongy. For now you can think of an agent as of a software entity that can communicate, react on events and do some computation. In Chapter 2 the usage for the term agent is specified in more detail. 1.3. GOALS 3 So the use of a virtual machine releases the tie to a specific operating system. But it also poses some restrictions on the scalability of software systems. If a software system cannot determine the available resources or hardware interfaces it cannot adjust itself suitably to new hardware configurations. For partial dynamic scalability the same reason can be applied. So at least the static scalability may be reached for runtime environments that do not support resource probing functionalities. This results in the following sub-problems: Identifying a suitable runtime environment to realise the mentioned architecture. The architecture must provide at least static scalability where no better type can be reached. The architecture must specify the communication infrastructure the agents may rely on. The answer for the first problem may affect the complexity of the solution of the other two. So the complexity is part of the trade-off between availability of the chosen virtual machine and its support for scaling. The details of these problems and the tasks that arise from them are described in their devoted chapters. 1.3 Goals In this thesis an extensible architecture is realised. The goals for this architecture can be summarised as follows: It should connect devices with different capabilities through a common simple communication infrastructure. Agents should be able to exchange messages without the knowledge about the underlying communication protocol and hardware interface. Also this infrastructure have to provide administrative messages only send between hosting environments. Agents should be modularised and the resulting elements should not be directly dependent on each other (for example via static references). This will ensure one kind of scalability as elements can be leaved out if available resources are not sufficient or present. Agent development should be eased so that hardware independent elements can be reused without any modifications on all supported devices. 1.4 Outline This thesis is structured as follows: In Chapter 2 terms related to this thesis will be introduced and described. It eases the 4 CHAPTER 1. INTRODUCTION understanding and concretise the meaning for ambiguous or spongy ones. The numerous similar or related works will be presented in Chapter 3. It is tried there to survey the current state-of-the-art while focussing on the characteristics of the realisations. After these introducing chapters the design of the system is worked out. To do this Chapter 4 analysis the demands on the system and describes the design decisions that leads to an abstract system concept. There the imple- This concept will be used in Chapter 5 to create the object model. mentation steps are described. To prove the functionality the architecture is then tested in Chapter 6 with a concrete scenario. Chapter 7 summarises the approach and provides some ideas for future developments. Chapter 2 Background Many terms, especially those used in computer sciences, are elastic words and usually lead to misunderstandings. To avoid this and to provide a better understanding this chapter introduces definitions of basic terms and concepts. The meanings proposed here are consequently used in this diploma thesis. This chapter starts with the definition of the agent term. It provides a survey of definitions in the literature and formulates the meaning in this thesis. Later on the relation between distributed artificial intelligence and middlewares will be shown. The last section will identify the capabilities of embedded systems and how they relate to this thesis. 2.1 Agents As it is already mentioned in the title of this thesis the term agent have to be explained and its meaning in this work have to be emphasised. First we may take a look on common definitions in the literature. It can be seen [FG97] that in different research or development projects the term agent is used and interpreted in different ways but with more or less intersections. As proposed in [FG97] naming agent properties separately seems to be more convenient. Many agents and agent systems are defined to be at least reactive and autonomous [WJK00, Lug02, RN03]. This seems to be a realistic foundation as most programs are reacting on one or another event and thus showing reactive behaviour. The demand for autonomy ensures that agents can process tasks by their own and are able to supervise their own control structures. Remember that this property does not require the agent to be modifiable. It can also act autonomously with a static set of actions Meaning Agents are a subset of programs with a basic complexity. As it is stated in [FG97] it is not possible to draw a strict border between agents and non-agents. So the core of agenthood is used while ignoring fringe groups. The agent description of Russel and Norvig [RN03] makes use of the concept of sensors and actuators. This concept fits well to describe 5 6 CHAPTER 2. BACKGROUND the interface between the agent and its surrounding environment as it is also borrowed from the description of biological organisms. So the notion of an agent will be used as a characterisation of the realised application or program. The ability to react on input and to generate output and to have some more or less complex internal control flow is expected of those applications. To what extend these functionalities have to be provided is not strictly defined. For this task a hierarchical order of specialised agents like in [FG97] is used but with some different notations. The root category here is the reactive agent which acts autonomous and reactive but not necessarily active or goal-oriented. This type of agent is the smallest possible to be realised with the provided architecture. Further agents will also have at least all the properties of an reactive agent but combined with other properties like goal-orientation, mobility and so forth (see the listing of usual agent properties in [FG97]). 2.2 Distributed Artificial Intelligence Distributed artificial intelligence (DAI) is a subfield in artificial intelligence (AI) research. It can be divided into two subdisciplines [SV00]: distributed problem solving (DPS) and multi agent systems (MAS). The former deals with issues in information management like problem or task decomposition and the synthesis of solutions. Consequently this discipline acts as the theoretical part of DAI where the foundation for communication, coordination and cooperation is built up. MAS on the other hand is the more practical part meaning that the focus is on the realisation of problem solving entities - agents - and the architectures behind them. DAI systems are predestined for areas where single agents are not able to solve problems by themselves due to resource restrictions, lack of knowledge or lack of capabilities [Jen96]. A further field of application might be the research itself - it is possible to build up real-world models and with them try to determine and to understand how biological individuals function [SV00]. The first step to let the agents solve a problem together is to enable them to decompose the problem. Then the resulting sub-problems have to be delegated to appropriate agents or agent groups. After partial solutions are found they have to be combined to form the solution of the initial problem. As mentioned above this management problem can be summarise by the following terms: Coordination Agents have to coordinate their doing so that duplications in computing are avoided or accesses to tight resources are synchronised. Also it makes sense to coordinate the order of computation and to optimise the flow of information. Thus every agent that is included in this common solution process should have something to do. In other words: it has to be avoided that available resources are unused. Cooperation The solution process functions best if all agents pull together. And to ensure this, agents that do not act cooperative have to be identified and their contribution to the 2.3. MIDDLEWARE 7 process should be ignored. It might be also possible to remove these agents out of the system. Communication Communication enables information interchange. Thus it is also the basis for coordinating agents. In heterogeneous multi agent systems a common language should be used so that all participants understand each other. 2.3 Middleware DAI systems are a special case of middleware. Middlewares are meant to be the layer between applications and specific communication infrastructures. These infrastructures consists of hardware interfaces and the operating system that provides access to this hardware through its drivers. So the main task for a middleware is to provide an abstract communication layer which shadows the operating system and hardware. Middleware frameworks come with different complexities and features. Some middlewares are simple abstraction layers to increase portability of applications (i.e ACE [Sch94]) and which are free to be extended as needed. On the other hand there are several other middleware approaches which define beside the abstraction layer also management functionalities like job scheduling and distribution, resource management, and security features (i.e GLOBUS [Fos06]). The common intention of a middleware is, as aforementioned, the abstraction layer between applications which thus reside on a higher level, and platform (hardware and operating system) specific libraries on the low level side. 2.4 Embedded Systems Embedded Systems which are mostly available in consumer electronics are designed to be inconspicuous and do their computations in the background. Whether in mobile phones, washing machines, televisions or cars - embedded systems are spread widely. Their tasks for which they are developed for are at least as different like the devices they are embedded into. So there are systems for driver support in cars which have tight restrictions to handle and process data in realtime. Others are required to comply to standards like bluetooth adapters in mobile phones. To say it in one sentence: embedded systems are used in a wide area of application and driver software for those systems are subjected to different requirements. 8 CHAPTER 2. BACKGROUND Chapter 3 Related Work The first chapter described the tasks for this thesis and proposed goals to reach an adequate solution. Basic definitions of concepts were provided in chapter 2. This chapter concludes the introductory part of this thesis with a detailed look at related work. The chapter is divided into two sections. The first is dedicated to a native approach which is mainly designed for performance and low memory consumption. The second section deals with approaches
Search
Similar documents
View more...
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks