Transcript Kapitel 13

Universität
Karlsruhe (TH)
Flexibility Through
Multiagent Systems:
Solution or Illusion?
Peter C. Lockemann
© 2004 IPD, Prof. Lockemann
SOFSEM04
Scenario: Production and supply chain
Monitoring
Execution
Planning
‹#›
Assembly
planning
Dispoweb
Global planning
and negotiations
Production
KRASHplanning for
MAS
mechanics IntaPSFABMASMAS
MAS
Production
planning for
electronics
intraplant
© 2004 IPD, Prof. Lockemann
Customer
OEM
dispoweb
dispoweb
ATT/SCC
interplant
Tracking
external
SOFSEM04
Scenario: Production and supply chain
‹#›
DISPOWEBPlaning
MAS
IntaPSExe- MAS

cution
Tracing

DISPOWEB- Tracing
MAS
Planing
ATTMAS
SCCMAS

Execution
KRASH-MAS 


ATT-MAS

ATTMAS
Tracing
Execution
FABMAS
DISPOWEBMAS
Planing


Negotiation of the global production schedule
Tracing of processes and propagation of delays
© 2004 IPD, Prof. Lockemann
SOFSEM04
Scenario: Production and supply chain
‹#›
Nr. Activity (Actor)

Negotiate initial plan of production between supply chain partners (DISPOWEB).

Operational assembly planning (KRASH).
Production planning for e.g. mechanical parts (IntaPS).
Production planning for e.g. electronic parts (FABMAS).

Monitoring of orders and related suborders (ATT).
Trigger internal planning systems in case of minor critical events (ATT).
Next  
Trigger re-planning by DISPOWEB agents in case of a severe critical event (ATT).
Next  
Controlling information is forwarded to trusted third party SCC-system
(ATT/SCC).

Internal rescheduling in reaction to a critical event (KRASH, IntaPS, FABMAS).
Next  

Renegotiate plan of production between supply chain partners due to severe critical
event (DISPOWEB). Next  
© 2004 IPD, Prof. Lockemann
SOFSEM04
Scenario: Health care
‹#›
Kliniken & Stationen
Internal Medicine
Surgery Ward
Uni Hohenheim/
Hosp. Sindelf inden
(Referring) Physicians
TU Ilmenau/
Phy sicians Thuringia, OnkoNet
N.N.
Uni Mannheim/
Hosp. Pegnitz, Hosp. Kulmbach
(…/…)
Reception Ward
Uni Hohenheim/
Hosp. Sindelf ingen
Gastro-Enterology
Cancerology
Uni Würzburg/
Univ .-Hosp. Würzburg
TU Ilmenau/
Univ .-Hosp. KIM II Jena
Radiology & Radiotherapy
Conv., CT, MRT
Cardiological Laboratory
Uni Mannheim/
Hosp. Pegnitz & Hosp. Kulmbach
Uni Mannheim/
Hosp. Pegnitz, Hosp. Kulmbach
Transport Serv.
Uni Freiburg/
Univ .-Hosp. Freiburg
Radiotherapy
Uni Würzburg/
Univ .-Hosp. Würzburg
Radiodiagnosis
Uni Freiburg/
Univ .-Hosp. Freiburg
N.N.
(…/…)
Operating Theatre
Surgery Block
Ambulance
TU Ilmenau/
Ambulances Thuringia
Emergency Dept.
TU Berlin/
Hosp. Charité Berlin
Univ Trier/Hosp.
Barmh. Brüder Trier
Dept. of Surgery
Uni Mannheim/
Hosp. Pegnitz & Hosp. Kulmbach
© 2004 IPD, Prof. Lockemann
Op.-Planning
TU Berlin/
Charité Berlin
N.N.
Intensive Care Unit
TU Berlin/
Hosp. Charité Berlin
(…/…)
SOFSEM04
Scenario: Digital libraries
‹#›
customer
user agent
trader
wrapper
order and delivery
provider
HTTP
queries to wrappers and query results
HTTP
HTTP
query registration and result presentation
queries to traders and trader recommendations
provider registration
HTTP
The UniCats environment
© 2004 IPD, Prof. Lockemann
SOFSEM04
Scenario: Traffic prognosis
‹#›
© 2004 IPD, Prof. Lockemann
SOFSEM04
Scenario: Traffic prognosis
‹#›
© 2004 IPD, Prof. Lockemann
SOFSEM04
The optimist
‹#›

Social organizations are resilient and responsive to ever
changing situations because they include

enough intelligent decision makers

sufficient slack to take decisions.

Then why not mirror these properties to build software
systems that are flexible (resilient and responsive)?

Agents are a most natural metaphor to model complex
social organizations that must be highly adaptive and rely
on flexible and adaptive members.

Such systems are known from AI and referred to as
multiagent systems (MAS).

Hypothesis: If well done, MAS offer the adaptivity and
flexibility needed for the modeled world.
© 2004 IPD, Prof. Lockemann
SOFSEM04
The pessimist
‹#›


Multiagent systems

are distributed

include asynchronous communication

have components with indeterministic behavior.
Therefore, they are inherently difficult to engineer:

It is hard to give a sufficiently precise system specification

and even if there is one, what are the chances to verify or
validate that the system implementation satisfies the
specification?
© 2004 IPD, Prof. Lockemann
SOFSEM04
Where the two may meet
‹#›

Are there situations with compelling reasons for a
multiagent approach?

Can one yet impose constraints to be able to engineer
multiagent systems?
© 2004 IPD, Prof. Lockemann
SOFSEM04
Agenda
‹#›

Are there situations with compelling reasons for a
multiagent approach?
What is an agent after all?
 ... and a multiagent system?
 Useful multiagent software systems: A hypothesis
 Testing the hypothesis
 Mixed results and a refined hypothesis


Can one yet impose constraints to engineer MAS?
A database person’s view
 At least it should be reliable!
 Transactional agents
 Reliable agent cooperation


Conclusions and challenges
© 2004 IPD, Prof. Lockemann
SOFSEM04
What is an agent?
‹#›
Wooldrige and Jennings on agents:
“An agent is a computer system that is situated in some
environment, and that is capable of autonomous action
in its environment in order to meet its design objectives.“
Wooldrige on intelligent agents:
“An intelligent agent is a reactive, proactive, interacting
agent.“
Flexibility
© 2004 IPD, Prof. Lockemann
SOFSEM04
What’s behind the definition
‹#›
A piece of code:
software agent
An open system:
must have an
observable effect
Effective indeterminism
in time and kind
“An agent is a computer
system that is situated in some
environment, and that is
capable of autonomous action
in its environment in order to
meet its design objectives.“
Agents can be many
things to many people
“An intelligent agent is a
reactive, proactive, interacting
agent.“
Stimulators and
responders
© 2004 IPD, Prof. Lockemann
SOFSEM04
Multiagent systems
‹#›
autonomous
situated
reactive
proactive
Individual objectives
interacting
autonomous
situated
reactive
proactive
interacting
Commo
n
objectiv
e
autonomous
situated
reactive
proactive
interacting
© 2004 IPD, Prof. Lockemann
SOFSEM04
Multiagent systems
‹#›
autonomous
situated
reactive
proactive
Individual objectives
interacting
autonomous
situated
reactive
proactive
Can the systems
be engineered?
© 2004 IPD, Prof. Lockemann
interacting
Commo
n
objectiv
e
interacting
autonomous
situated
reactive
proactive
How much flexibility
can we manage?
SOFSEM04
Who needs all that flexibility?
‹#›
Hypothesis:
the database
person’s view
the software
architect’s view
Multiagent systems are useful for an environment where

the range of situations (the problem space) is too large for
enumeration and instead needs a qualitative description,

the problem space can be divided into sets of simpler
tasks, each requiring specialized competence,

the simpler tasks can be dealt with autonomously by
individual agents,

solving the overall situation requires cooperation among
the agents.
the AI
person’s view
© 2004 IPD, Prof. Lockemann
the programmer’s
view
SOFSEM04
Flexibility through multiagent systems
‹#›
autonomous
situated
reactive
proactive
interacting
autonomous
situated
reactive
proactive
interacting
Assignment of
individual
responsibilities
&
cooperative
problem solving
autonomous
situated
reactive
proactive
interacting
© 2004 IPD, Prof. Lockemann
SOFSEM04
Testing the hypothesis: Scenario
‹#›
Product Assembly1
UL01
UF01
Supplier
Buffer1
Product Assembly2
Product Assembly3
UL02
Immidiate
Buffer2
UF02
UG01
Immidiate
Buffer
UA01
UG02
UA02
B1
A1
C2
B2
A2
C3
B3
A3
C4
B4
A4
C5
B5
A5
UB01
Mold
Buffer
Option
C1
UB02
Buffer
Shipping
UC01
UH01
Product Assembly Area
© 2004 IPD, Prof. Lockemann
Supplier
Buffer2
Unit Assembly Area
Mold
Maintenance
UC02
Buffer
Molding Area
SOFSEM04
Benchmark
‹#›
Kanban
A
C
Product assembly
Molding area
B
Buffer
Manual
assembly
High variability within
External
homogeneous product spectrum
supplier
Unit assembly
Flexibility via Kanban production organization:
Order
Supply buffer minimization via pull principle
 Production
control:
© 2004 IPD, Prof. Lockemann
SOFSEM04
Benchmark
‹#›
External
supplier
Kanban
A
C
Product assembly
Molding area
B
Buffer
Manual
assembly
Externally determined
production schedule
Unit assembly
Analytical and simulation-based layout
Order
planning
for a givenSupply
production program
© 2004 IPD, Prof. Lockemann
SOFSEM04
Test and Benchmark
‹#›


Centrally planned Kanban is not flexible enough to deal with

machine failures

short-term deviations from the delivery schedule
Solution options

Passive: Simulate disturbances and adjust layout planning

Reactive: Rescheduling algorithms (known to be suboptimal)

Reactive: Agents
Comparison by simulation
© 2004 IPD, Prof. Lockemann
SOFSEM04
The best performing agent model
‹#›
Order Data
Order Agent
Machine Agent
1: New Order
2: Request
Mixed-model Assembly
Line Balancing Problem
(MALBP):
Reactive MAS Approach
3: Task Announcement
4: Task Announcement Bidding
5: Bid
6: Bid Processing
7: Reporting Results
© 2004 IPD, Prof. Lockemann
SOFSEM04
Experiments by simulation
‹#›
Parameter variations:
 Master data:
Bill of materials
 Operation list fore each product


Transport lot size



Affects the number of suborders for a single order
Production order generated by production planning and
control
Disturbance profile per machine (statistical)
Interval between disruptions
 Disruption duration

Output:
 Throughput:
Average
 Standard deviation

© 2004 IPD, Prof. Lockemann
SOFSEM04
Experiments by simulation
‹#›
Corresponding Standard Deviations
Throughput and Processing Time
Parameterisation
© 2004 IPD, Prof. Lockemann
SOFSEM04
Experiments: Sample Analysis
‹#›
Throughput Time
5
3 Lot Size
1-1,5
0,5-1
1
5 min 30 min 60 min
Suitability of MAS Compared to
Centralized OR Approaches
Depending on Decision Variables
0-0,5
Disruption
Duration
Throughput Time
Improvement by MAS
Standard Deviation
5
Reliability and Predictability
of the Results
3 Lot Size
1-1,5
0,5-1
1
5 min 30 min 60 min
0-0,5
-1-0
Disruption
Duration
Standard Deviation
© 2004 IPD, Prof. Lockemann
SOFSEM04
Empirical This
results
cannot solely be explained
by the original hypothesis



‹#›
Multiagent systems need slack:

If assembly lines run close to capacity, MAS are even inferior.

They performed better if slack was provided by additional
machines or by delaying assembly orders.
Multiagent systems need inhomogeneity:

More assembly lines by themselves have no effect unless the
machines follow very different disturbance profiles.

Different disturbance profiles have even a positive effect if no
machines are added.
Multiagent systems operate best in a dynamic, nondeterministic environment:

MAS are superior when it comes to evening out fluctuations
due to disruptions.
© 2004 IPD, Prof. Lockemann
SOFSEM04
Revisiting the hypothesis
‹#›
Hypothesis:
Multiagent systems are useful for an environment where

the range of situations (the problem space) is too large for
enumeration and instead needs a qualitative description,

the range of decisions (the solution space) is
commensurate in size with the problem space,

the problem space can be divided into sets of simpler
tasks, each requiring specialized competence,

the simpler tasks can be dealt with autonomously by
individual agents,

solving the overall situation requires cooperation among
the agents.
© 2004 IPD, Prof. Lockemann
SOFSEM04
Practical implementation
‹#›
FIPA-OS Implementation
eMPlant Simulation Model
DB
Communication Platform
using Event Mechanisms
© 2004 IPD, Prof. Lockemann
SOFSEM04
A database persons’ view
‹#›
Hypothesis:
Take a descriptive approach!
Multiagent
systems
After all, SQL
does are
it! useful for an environment where
your objectives,
let the
determine
way
State
the range
of situations
(thesystem
problem
space) isthe
toobest
large
for
how
to achieve and
them!
enumeration
instead needs a qualitative description,
need
software
engineering
for MAS.
We
the
range
of decisions
(the solution
space) is
Disciplines
that could
help:
commensurate
in size
with the problem space,
 Model-driven programming
 the problem space can be divided into sets of simpler
 Service-oriented
tasks,
each requiringprogramming
specialized competence,
 Component-orientation
 the simpler tasks can be dealt with autonomously by
Agent
platforms
are available.
individual
agents,
But then, agents and MAS should not be indeterministic
 solving the overall situation requires cooperation among
beyond
their own control, such as own disturbances!
the agents.
© 2004 IPD, Prof. Lockemann
SOFSEM04
Mastering the complexity
‹#›
autonomous
situated
reactive
proactive
interacting
autonomous
situated
reactive
proactive
interacting
No uncontrolled
disturbances!
autonomous
situated
reactive
proactive
interacting
© 2004 IPD, Prof. Lockemann
SOFSEM04
Transactions
‹#›
autonomous
situated
reactive
proactive
Transactional agents
interacting
autonomous
situated
reactive
proactive
Agent may be involved ininteracting
interacting
autonomous
situated
reactive
proactive
Transactional conversations
concurrent conversations!
© 2004 IPD, Prof. Lockemann
SOFSEM04
INTERRAP BDI agent architecture
‹#›
Agent knowledge base
Cooperative planning layer
Cooperation Model
SG
PS
Mental Model
SG
PS
Local planning layer
World Model
SG
PS
Behavior based layer
World Interface
SG: Situation recognition and Goal activation
PS: Planning, Scheduling and execution
information access
control flow
© 2004 IPD, Prof. Lockemann
SOFSEM04
Corresponding transaction model
‹#›
Recovery
Open nested transactions
action node
control node
synchronization node
parallel execution
sequential execution
alternate execution
Conversation
© 2004 IPD, Prof. Lockemann
SOFSEM04
Evolutionary transactions
‹#›
Agent knowledge base
Cooperative planning layer
Cooperation Model
SG
PS
Mental Model
SG
PS
Local planning layer
World Model
SG
PS
Behavior based layer
World Interface
...
© 2004 IPD, Prof. Lockemann
SOFSEM04
Agent cooperation by synchronization
‹#›
agent 1
transaction
© 2004 IPD, Prof. Lockemann
agent 2
transaction
SOFSEM04
Agent cooperation by synchronization
‹#›
Independent start
prevents termination
of slave before
termination of master
Task Delegation
M1
Master
M11
M111
M12
M112 M121
M13
...
M131
...
Slave
S0
M1111
...
S2
S1
M112 waits for S1
to regain control
S11
M11 wakes up S11
© 2004 IPD, Prof. Lockemann
S121
S12
S122
compensate in
slave if M112 fails
S123
SOFSEM04
Experiments with an orthogonal architecture
‹#›
common goal
domain agent
domain agent
cooperation
local actions
local actions
distributed plan
transactional
agent
transactional
agent
local
TA tree
coordination
local
TA tree
action execution
action execution
Isolation
robustness
service
action
(DB transaction)
database
database
© 2004 IPD, Prof. Lockemann
SOFSEM04
Not a nice solution because …
‹#›
Cooperation protocol directly built
into individual agent transaction
agent 1
transaction
Need for a shared database
for conflict resolution
© 2004 IPD, Prof. Lockemann
agent 2
transaction
Asynchronous communication
via ECA rules that must be
coordinated with database,
e.g. via active database
SOFSEM04
Transactional conversations
‹#›
agent 1
transaction
agent 2
transaction
conversation
distributed transaction
© 2004 IPD, Prof. Lockemann
SOFSEM04
Modeling of conversations
‹#›
initiator
participant
initiator
ready
cfp_
sent
cfp
refuse
not-understood
propose
reject-proposal
prop_
refused
not_
under
stood
prop_
sent
prop_
refused
abort
prop_
acceptd
accept-proposal
failure
participant
inform-done
inform-ref
© 2004 IPD, Prof. Lockemann
deal_
reached
SOFSEM04
Transactional conversations
‹#›
Transaction manager (CORBA OTS)
DB I
TA Task
User Task
Agent A
MAS Platform I
© 2004 IPD, Prof. Lockemann
DB II
FIPA conformant
conversation
TA Task
User Task
Drawback: Conversations
must be attached to the
leaf nodes
Agent B
MAS Platform II
SOFSEM04
The next idea
‹#›
agent 1
transaction
agent 2
transaction
conversation
Message-oriented middleware (MOM)
with messages based on speech acts
© 2004 IPD, Prof. Lockemann
SOFSEM04
Conclusions: Flexibility
‹#›

MAS are very costly to engineer:

System-level behavior is close to impossible to predict
analytically, requires large simulative or experimental effort.

The added cost does not even pay off in the majority of
cases!

The expenses seem only justified for applications with



large problem and solution spaces,

where the problem space is or appears non-deterministic.
A natural application seems health care.
Candidate technical applications are those with a high level
of disruptions.
© 2004 IPD, Prof. Lockemann
SOFSEM04
Conclusions: Flexibility
‹#›

Approach: Transactional properties

Requires an expensive and extensive infrastructure of
database manager and transaction manager.

Heavy-weight nodes needed for agents.

Distributed transactions (a foe of autonomy!) and active
database mechanisms (e.g., trigggers) needed.
© 2004 IPD, Prof. Lockemann
SOFSEM04
Challenges: Industrial strength
‹#›




Transactional synchronization:

Evolutionary transactions to deal with reaction.

Transactions with built-in cooperation.

Non-orthogonal individual and cooperative behavior.
Transactional conversations:

Difficult to attach to agent transactions.

Rigid, must have ACID properties.
Message-oriented middleware:

Still an unknown area for agents.

Long term: A combination of transactional agents and
message-oriented middleware with higher-level guarantees.
Contribute to standards!
© 2004 IPD, Prof. Lockemann
SOFSEM04
Conversation Policy XML (cpXML)
‹#›
•
Origin:
•
•
•
•
V 1.0 (August 2002)
•
Specification: XML Schema, Standards
document, papers, tutorial
Roles
State
InitialState
Coverage:
Sequencing and timing of messages
Tools
•
•
•
ConversationPolicy
Status:
•
•
IBM (Conversation Support for
Webservices)
Reference implementation for
WebSphere
JCA extension by Conversation Manager
and Conversation Adapter
Role
SendMessageTransition
TimeoutTransition
LoadChild
ChildReturnTransition
Remarks
•
Compatible to BPEL4WS
•
CPs exchangeable
© 2004 IPD, Prof. Lockemann
SOFSEM04
FIPA-Standard
‹#›
Applications
•Nomadic Application Support
•Agent Software Integration
Agent Message Transport
•Msg Transport Service
•Messaging Interoperability
ACL Representations
•ACL Msg Representation in
•Bit Efficient
•String
•XML
Envelope Representations
•Agent Msg Transport Envelope
Representation in
•XML
•Bit Efficient
Transport Protocols
•Agent Msg Transport Protocol for
•IIOP
•WAP
•HTTP
© 2004 IPD, Prof. Lockemann
•Message Buffering
•QoS
•Network Mgmt
•Personal Assistant, Personal Travel
Assistant
•Audio-visual Entertainment and
Broadcasting
Abstract Architecture
•Abstract Architecture
•Domains and Policies
Foundation of
Interoperable
Agents
Agent Communication
•Ontology Service
•ACL Message Structure
Interaction Protocols
•IP Library Spec
•Request, Request-When
•Query
•Subscribe
•Propose
•Contract Net, Iterated ~
•English, Dutch Auction
•Brokering, Recruiting
Agent Management
Communicative Acts
•Agent Mgmt Spec
•CA Library Spec
Content Languages
•Content Lang. Spec
•SL, CCL, KIF, RDF
SOFSEM04
Augmenting FIPA
‹#›
Order agent
Machine agent
Data Warehouse
„Agent“
Standard system DW
Agent
Directory
Management
Facilitator
System
„Yellow Pages“
„White Pages“
Standard system
...
...
Task
Standard system
Scheduling
Task
Task
Task
Data
Warehouse
Software
Robustness service
FIPA-OS
© 2004 IPD, Prof. Lockemann
SOFSEM04