Post on 19-Jan-2016
1
Apr
il 21
, 202
3
Architectural Design of a Architectural Design of a Distributed Application with Distributed Application with
Autonomic Quality RequirementsAutonomic Quality Requirements
DEAS
St. Louis, USA, May 21th, 2005
Danny Weyns, Kurt Schelfthout and Tom Holvoet
University of Leuven, Belgium
2
Apr
il 21
, 202
3
A challenging applicationA challenging applicationAGV transportation systemAGV transportation system
3
Apr
il 21
, 202
3
Traditional approachTraditional approach
• Centralized architectureo Server assigns transports to AGVs
o Server plans routes etc.
o Vehicles are controlled by central server
o Low level control AGVs is handled by E’nsor software
• Main non-functional properties
o Configurability (server is central configuration point)
o Predictability (server manages execution of functionality)
4
Apr
il 21
, 202
3
Aiming for new Aiming for new qualityquality requirements requirements
• AGVs are expected to be flexible and adapt their behavior autonomously with changing circumstances o Exploit opportunities
Switch jobs when driving to a load when a more interesting transport pops up
o Anticipate possible difficulties
Prefer jobs near to a battery charging station when battery needs to be charged in the near future
o Cope with particular situations
Choose the farthest load in the corridor
5
Apr
il 21
, 202
3
Aiming for new Aiming for new qualityquality requirements requirements
• System is expected to deal with openness o AGVs leave/enter the system, e.g. for maintenance
o 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
Apr
il 21
, 202
3
OverviewOverview
• Situated multiagent systems for the AGV transportation system
• A trace through the architectural design
• Round-up
7
Apr
il 21
, 202
3
Situated multiagent systemsSituated multiagent systems
• What is a situated multiagent system (MAS)? o Set of autonomous entities (agents) explicitly situated in a
shared structure (an environment)
o Agents select actions “here and now”, they do not use long term planning (locality in time and space)
o Interaction is at the core of problem solving (rather than individual capabilities)
Decentralized control
Adaptive behavior
Collective behavior
8
Apr
il 21
, 202
3
A situated MAS for the A situated MAS for the AGV transportation systemAGV 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
Apr
il 21
, 202
3 • Reference architecture as a guidance for architectural designo Embodies knowledge and experiences acquired during
4 years of research
o Serves as a reusable architectural design artifact
o We developed design guidelines for specific modules, e.g., decision making with free-flow architectures
Reference architecture for Reference architecture for situated MASssituated MASs
10
Apr
il 21
, 202
3
High-level overview of the reference High-level overview of the reference architecturearchitecture
11
Apr
il 21
, 202
3
OverviewOverview
• Situated multiagent systems for the AGV transportation system
• A trace through the architectural design
• Round-up
12
Apr
il 21
, 202
3
Deployment view of the Deployment view of the decentralized architecturedecentralized architecture
13
Apr
il 21
, 202
3
Top level module decomposition: Top level module decomposition: situated MASsituated MAS
14
Apr
il 21
, 202
3
Module view of the environment: Module view of the environment: layerslayers
Separate functionality, support reuse
15
Apr
il 21
, 202
3
Virtual environment is a Virtual environment is a distributed entitydistributed entity
16
Apr
il 21
, 202
3
Physical EnvironmentPhysical Environment
17
Apr
il 21
, 202
3
Virtual Environment Virtual Environment
4
7 .
.
. .
.
AGV agent
Virtual environment
node
segment
hull projection
load
move cost
magnet strip Physical AGV
18
Apr
il 21
, 202
3
The virtual environmentThe virtual environment
• Offers a medium to agents to exchange information and coordinate their behavior
• Synchronizing state of the virtual environment o 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
Apr
il 21
, 202
3
AGV agents:AGV agents:data repositorydata repository
Separation of concerns, loose coupling
20
Apr
il 21
, 202
3
AGV agents: AGV agents: blackboard with sequential processingblackboard with sequential processing
Decision making at different levels of abstraction, separation of concerns
Feedback for flexible decision making
21
Apr
il 21
, 202
3
OverviewOverview
• Situated multiagent systems for the AGV transportation system
• A trace through the architectural design
• Round-up
22
Apr
il 21
, 202
3
The challenge continuesThe challenge continues
• Project status (after 1.2 of 2 years)o 2 real AGVs manipulate loads, drive around and avoid collisions
in an industrial test set-up (basics for deadlock prevention)
o The same for n AGvs in a simulated setup
• Current worko Methodological evaluation of software architecture: ATAM
planned June
o Order assignment and deadlock avoidance
• Next challenges o Explore and validate flexibility, adaptability, scalability
o Give guarantees about global behavior
23
Apr
il 21
, 202
3
Lessons learnedLessons learned
o We learned the real value of our research by applying it in real-world application
We experienced what “application-driven research” is about
o The reference architecture serves as an excellent guidance for the architectural design
o Stakeholders not involved in the daily development tend to overestimate the agent metaphor