1 / 23

Architectural Design of a Distributed Application with Autonomic Quality Requirements

Architectural Design of a Distributed Application with Autonomic Quality Requirements. DEAS St. Louis, USA, May 21 th , 2005 Danny Weyns, Kurt Schelfthout and Tom Holvoet University of Leuven, Belgium. A challenging application AGV transportation system. Traditional approach.

josiah
Download Presentation

Architectural Design of a Distributed Application with Autonomic Quality Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Architectural Design of a Distributed Application with Autonomic Quality Requirements DEAS St. Louis, USA, May 21th, 2005 Danny Weyns, Kurt Schelfthout and Tom Holvoet University of Leuven, Belgium

  2. A challenging applicationAGV transportation system

  3. Traditional approach • Centralized architecture • Server assigns transports to AGVs • Server plans routes etc. • Vehicles are controlled by central server • Low level control AGVs is handled by E’nsor software • Main non-functional properties • Configurability (server is central configuration point) • Predictability (server manages execution of functionality)

  4. Aiming for new quality requirements • AGVs are expected to be flexible and adapt their behavior autonomously with changing circumstances • Exploit opportunities • Switch jobs when driving to a load when a more interesting transport pops up • Anticipate possible difficulties • Prefer jobs near to a battery charging station when battery needs to be charged in the near future • Cope with particular situations • Choose the farthest load in the corridor

  5. Aiming for new quality requirements • System is expected to deal with openness • AGVs leave/enter the system, e.g. for maintenance • Customers intervene during execution of the system We investigate the feasibility of a decentralized architecture aiming to cope with these new quality requirements Joint R&D project between AgentWise research group and Egemin This talk: overview basic architecture of the system

  6. Overview • Situated multiagent systems for the AGV transportation system • A trace through the architectural design • Round-up

  7. Situated multiagent systems • What is a situated multiagent system (MAS)? • Set of autonomous entities (agents) explicitly situated in a shared structure (an environment) • Agents select actions “here and now”, they do not use long term planning (locality in time and space) • Interaction is at the core of problem solving (rather than individual capabilities) Decentralized control Adaptive behavior Collective behavior

  8. A situated MAS for the AGV transportation system • Motivations for situated MAS • Matching quality properties • Situated MAS are a promising approach to build flexible, adaptable, open systems • Matching characteristics • Locality in time and space: order assignment to idle AGV near to load, collision avoidance, etc. • Interaction at the core of problem solving: load manipulation, collision avoidance, etc.

  9. Reference architecture for situated MASs • Reference architecture as a guidance for architectural design • Embodies knowledge and experiences acquired during 4 years of research • Serves as a reusable architectural design artifact • We developed design guidelines for specific modules, e.g., decision making with free-flow architectures

  10. High-level overview of the reference architecture

  11. Overview • Situated multiagent systems for the AGV transportation system • A trace through the architectural design • Round-up

  12. Deployment view of the decentralized architecture

  13. Top level module decomposition: situated MAS

  14. Module view of the environment: layers • Separate functionality, support reuse

  15. Virtual environment is a distributed entity

  16. Physical Environment

  17. Virtual Environment

  18. The virtual environment • Offers a medium to agents to exchange information and coordinate their behavior • Synchronizing state of the virtual environment • Virtual environment as software entity does not exist • Virtual environment is necessary distributed over the AGVs • ObjectPlaces middleware keeps state of local virtual environment synchronized with virtual environments of local AGVs

  19. AGV agents:data repository • Separation of concerns, loose coupling

  20. AGV agents: blackboard with sequential processing • Decision making at different levels of abstraction, separation of concerns • Feedback for flexible decision making

  21. Overview • Situated multiagent systems for the AGV transportation system • A trace through the architectural design • Round-up

  22. The challenge continues • Project status (after 1.2 of 2 years) • 2 real AGVs manipulate loads, drive around and avoid collisions in an industrial test set-up (basics for deadlock prevention) • The same for n AGvs in a simulated setup • Current work • Methodological evaluation of software architecture: ATAM planned June • Order assignment and deadlock avoidance • Next challenges • Explore and validate flexibility, adaptability, scalability • Give guarantees about global behavior

  23. Lessons learned • We learned the real value of our research by applying it in real-world application • We experienced what “application-driven research” is about • The reference architecture serves as an excellent guidance for the architectural design • Stakeholders not involved in the daily development tend to overestimate the agent metaphor

More Related