Negotiating Solutions to Multiobjective Optimization Problems

1
Negotiating Solutions to Multi-objective
Optimization Problems

• Yönet A. Eracar
• Ph.D. Proposal Defense

2
Overview

• Motivating example
• Problem statement
• Candidate components of a solution
• Analysis of candidate components
• Proposed solution
• Contributions
• Method verification demonstration
• Plan

3
Fixture Design Experiment
Tester chassis instruments

• Goal to find a mapping between the edge
  connector pins of the unit under test (UUT) and
  the digital channels of the functional board
  tester (FBT) while keeping the cost of the system
  low by using a small number of assets (channels).

UUT and the associated fixture
Teradyne Spectrum 9100 (FBT)
4
Goals and Constraints

• Goals
• Minimize the number of UUT pins that are NOT
  assigned to any channel.
• Minimize the number of total channel cards used
  in the system.
• Constraints
• Each UUT pin will either be connected to a
  channel on the tester or will be disconnected
  from the system.
• Only one UUT pin will be connected to a channel.
• All the requirements of the UUT pin will be
  satisfied by the capabilities exposed by the
  channel that is connected to the UUT pin.
• A tester cannot hold more than 13 channel cards.
• A channel card can not hold more than 48 channels.

5
Fixture sub-system (UML)
1
-mapping
-channel
1
-assignmentList
-mappingList
-mapping
0..
1
-pin
6
Fixture Design Experiment Goals Constraints
(OCL)
package FXTConstraints -- Minimizes the the
number of pins that are NOT connected to any
channels. context FXTObjective1() pre
constraint1 P-gtforAll(p1,p2 p1 ltgt p2 implies
DesignerPC(p1) ltgt DesignerPC(p2)) pre
constraint2 P-gtforAll(p p.Rec()-gtforAll (r
DesignerPC(p).Cap()-gtincludes(f_map(r)))) post
result ONTMinimize ( DesignerPC_inv(c_NULL)
-gtsize() ) -- Minimizes the number of channel
cards used to prevent the cost hike. context
FXTObjective2() pre constraint1 CC-gtsize() lt
N_CC_MAX pre constraint2 ( DesignerPC(P) -
Set c_NULL)-gtsize() lt N_P post result
ONTMinimize( VXIChassisCont(C)-gtsize()
) endpackage
7
Fixture Design Experiment(Phase Transition
Invariants)

• In a simple OZ program, a set of UUT pins are
  assigned to channel cards. In the input data,
  there are 16 UUT pins and each channel card has
  the same number of channels. Two kinds of pin
  requirements are used (1) pins in the same bus
  need to be assigned to the same channel card, and
  (2) two disjoint pins cannot be in the same
  channel card.
• A cluster is a group of pins sharing similar
  requirements, ex bus pins.
• Candidate phase transition invariant
• c average cluster size / channel card size
• Critical region is around c 1.

average cluster size 5
8
Multi-Objective Optimization Problem (MOOP)
Fixture Design Problem is a special case of MOOP
9
Problem Statement

• Multi-objective optimization problems (MOOP)
• Unlikely to find one solution that will optimize
  all objectives (NP-hard).
• Trade-offs among objectives may be necessary
  (less than optimal solutions).
• Satisficing solutions (good-enough-soon-enough
  solutions).
• Such solutions incorporate problem/domain
  specific search algorithms rather than generic
  search algorithms.
• Potential changes in the problem formulation
  require, either
• The development of a new search program, or.
• Built-in mechanisms for adapting to changes.

10
Problem Statement (Cont.)

• How can a satisficing program be automatically
  synthesized from specifications such that it can
• Adapt to parametric changes in the constraints
• Monitor and control its complexity

11
Problem Statement (Cont.)

• Need to answer the following questions to develop
  such a program
• What is the language in which the problem
  specifications can be expressed?
• What algorithms or systems can be used in search
  for solutions to multi-objective optimization
  problems?
• What algorithms should be used to determine the
  aspiration levels for the objective functions in
  the satisficing problems?
• How does the program control and monitor its
  complexity?
• What architecture should be used to implement the
  control of the complexity and program adaptation?

12
Candidate Components of a Solution

• Well-known algorithms, like weighting objectives,
  goal programming, e-constraint method,
  hierarchical optimization, suggest the conversion
  of a multi-objective optimization problem to a
  single-objective optimization problem.
• For such conversion, algorithms listed above
  require information about the problem - not
  available.
• Finding an optimal solution may not be feasible
  with the given resources (e.g. computational
  power, time, cost).
• Optimization fails to describe how decisions are
  made in naturalistic settings.
• Requirements for reliability, functionality,
  robustness in changing and uncertain environments
  can conflict with the performance of the
  optimization algorithms.

13
Candidate Components of a Solution

• Constraint satisfaction problems (CSP)
• CSPs consist of a set of variables (and
  associated domains) and a set of constraints.
• A solution is an assignment of values for each
  variable that will satisfy all the constraints.
• Well-known examples k-colorability and
  k-satisfiability
• General CSP is NP-complete.
• Backtracking and arc-consistency checking are
  well-known solution methods.
• Some preprocessing algorithms to provide
  arc-consistency in CSPs (waltz 1975, Mackworth
  1977, Montanari 1974, Freuder 1978, Dechter 1990)

14
Candidate Components of a Solution

• Other CSP algorithms
• Islands of tractability classes of CSPs, where
  preprocessing algorithms can find a solution,
  e.g.
• Tree-structured problems
• Problems generated by graph-grammars (Rossi
  Montanari 1991)
• Constraint relaxationwhen the CSP is
  over-constrained, some constraints can be relaxed
  to find a solution (e.g. Hierarchical CLP
  Borning 1989).

15
Candidate Components of a Solution

• Weaknesses of CSP algorithms
• Classical CSP model assumes a well-defined and
  stable constraint satisfaction problem. However,
  in real life constraints are dynamic (Rossi and
  Montanari, 1996).
• There is a lack of constraint satisfaction
  systems that provide interaction to support
  modeling and dynamic constraint change.

16
Candidate Components of a Solution

• Phase transitions
• For many NP-complete problems, one or more order
  parameters can be defined and hard instances
  occur around particular critical values of these
  order parameters (Cheeseman, 1991).
• Phase transition regions are widely used to
  evaluate the performance of a given algorithm for
  an NP-hard problem (Selman, 1992).
• It is difficult to determine the order parameters
  for an NP-hard problem.
• Some of the studies on the phase transitions in
  CSPs Prosser 1996, Smith 1996, Gent 1997, Selman
  1996, Hogg 1994.

17
Candidate Components of a Solution
Phase Transition in 3-SAT
This figureplots the probability that a random
3-CNF (Conjunctive Normal Form) formula is
satisfiable against the constraint density c
(ratio of constraints to variables). As the
number of variables goes to infinity the
satisfaction probability approaches a step
function there exists a critical'' value such
that 1. A random formula with cltc3 is almost
surely satisfiable. 2. A random formula with
cgtc3 is almost surely not satisfiable.
c3
This figure plots the average computational
effort to decide satisfiability (for a popular
class of algorithms known as Davis-Putnam ) 
against the constraint density c. When constraint
density is close to a critical point (phase
transition), a peak in the computational cost is
observed, centered at c3.
18
Candidate Components of a Solution

• Herbert Simons satisficing approach
• Search for an optimal solution can be terminated,
  when
• The decision makers aspiration level is met,
  and.
• The cost of further search exceeds the benefits
  of continuing the search.
• Aspiration level represents a dynamic,
  context-dependent criterion, typically acquired
  by experience.

19
Candidate Components of a Solution

• Zilberstein (1998) summarizes the open issues on
  Simons satisficing approach
• What is the relationship between the aspiration
  level and the problem solving technique?
• What is a good enough solution?
• How can a computer measure that?
• Should a satisfactory solution be reached
  directly or by iterative refinement?
• How is the performance of a satisficing agent
  evaluated?

20
Candidate Components of a Solution

• Current approaches to satisficing
• Approximate reasoning, e.g.
• Bayesian belief networks,
• Reasoning with approximate theories Roth 1996
  (or knowledge compilation Selman 1996).
• Fuzzy logic.
• Meta-reasoning (Good 1971), e.g.,
• Utilize a metalevel architecture.
• Anytime algorithms (Dean Boddy 1988, Horvitz
  1987)
• Interruptible algorithms.
• Contract algorithms.
• Bounded optimality (Russell 2002).
• The capacity to generate maximally successful
  behavior given the available information and
  computational resources.
• Combination of above.

21
Candidate Components of a Solution

• CSP solution methods and tools
• Constraint-based programming environments
  (SKETCHPAD, CONSTRAINT, ThinkLab)
• Earlier constraint logic programming languages
  (CHIP, CLP(R), prolog II, prolog III)
• Current constraint programming languages
  (Eclipse, prolog IV, HAL, Salsa)
• Concurrent constraint (CC) framework and
  languages (OZ, CIAO, AKL)
• CLP toolkits with GUI to monitor the progress of
  the solver (QOCA, EaCL, Ultraviolet, Mozart)
• Modeling languages (AMPL, GAMS, Claire, CML)

22
Candidate Components of a Solution

• Active software (Laddaga 2000) approach deals
  with three main software development problems
• Escalating complexity of application
  functionality.
• Insufficient robustness of applications.
• The need for autonomy.
• A system that follows this approach
• Responsible for its robustness.
• Manages its own complexity.
• Incorporates the representations of its goals,
  methods, alternatives, and environment.

23
Candidate Components of a Solution

• Available technologies under active software
• Self adaptive software (see issues with self
  adaptive software)
• Dynamic planning systems (Goldman 1997, Musliner
  2000)
• Self-controlling systems (Kokar-Baclawski-Eracar
  1999, Garlan 2001, Badr 2002)
• Self-aware systems (Karsai 1999, Reece 2000,
  Brandozzi 2002)
• Negotiated coordination (see ants and related
  research)
• Tolerant software
• Physically grounded software

24
Self-Controlling Software Architecture
Feedback loop
Environment
Q
Goal
Controller
Plant
QoS
d
Adaptation loop
Controller designer
Evaluator
Reconfiguration loop
Reconfigurer
Information transfer Reconfiguration
Specification database
Component database
25
Analysis of Candidate Solutions

• Conversion of MOOP into single objective
  optimization problem.
• Pros There are existing, successful algorithms.
• Cons Prior information is needed, but not
  available.
• Satisficing solutions
• Pros A good-enough solution is reached at a
  given time.
• Cons Aspiration levels for different objectives
  are not known in our problem. Therefore, we will
  use negotiation and learning to determine the
  aspiration levels.
• MARBLE project
• Pros Distributed, adaptive, treats each
  objective as a separate CSP, uses negotiation,
  and monitors the progress of negotiation.
• Cons Specifically designed for resource
  allocation problems. Does not support declarative
  specification of multi-objective optimization
  problems.

26
Analysis of Candidate Solutions

• ATTEND project
• Pros Monitors performance of negotiation to
  avoid phase transition regions.
• Cons Limited to SAT problems.
• Active software (self-controlling software)
• Pros Provides graceful degradation when
  unexpected changes are encountered.
• Cons Applicable only when the underlying process
  is repetitive. Needs to be proven in practice.

27
Analysis of Candidate Solutions (Cont.)

• Metalevel architecture (we will use two
  metalevels feedbeck and adaptation loops).
• From modeling in CML to execution in CHIP
• Pros CML is a high-level modeling language.
  Rules to translate from CML to CHIP (a CSP
  language) are available.
• Cons Expressiveness of CML (structural aspects
  of a problem) is limited.

28
Proposed Solution
User inputs
Identify Phase Transitions, create the Quality
of Service module that will monitor the
negotiation
Create agents with negotiation capability
Define the structural constraints (UML)
MOOP Program
Define goals and global constraints in OCL
Translate constraints and goals in OCL to CSP
Solver (OZ)
System
29
Proposed Solution (Tools That Will Be Implemented)

• An ontology for multi-objective optimization
• A parser that converts constraints expressed in
  OCL to an intermediate XML form (OCLML)
• A code generator that generates CSP code from
  OCLML and structural constraints expressed in XMI

30
Proposed Solution (Tools That Will Be Implemented
Cont.)

• Templates for creating software agents
• An instantiation of the self-controlling software
  architecture (SCSA) with support for negotiation
• Phase transition invariants and related critical
  regions for the experimental domains

31
Contributions

• Using phase transition invariants as indications
  of complexity of multi-objective optimization
  problems
• Objective based agentification of multi-objective
  optimization problems
• Self-controlling software architecture (SCSA) as
  a way of controlling the complexity of CSP

32
Contributions (Cont.)

• Ontology based support of specification of
  multi-objective optimization problems
• Proof-of-concept of automatic CSP code generation
  for multi-objective optimization problems

33
Method Verification Demonstration

• Two experimental systems will be implemented and
  tested - a fixture design scenario and an order
  negotiation scenario.
• Problem formulations (specified using the UML/OCL
  representation) will be automatically translated
  to OZ (a CSP language) and then used by the
  system to find satisficing solutions.
• The goal will be to provide a proof-of-concept of
  developing a self-controlling satisficing program
  that
• Is applicable to various multi-objective
  optimization problems,
• Has the ability to control its own complexity,
  and.
• Can adapt to parametric changes in the
  constraints.
• In both scenarios, the system will be tested on
  both hard and easy regions in order to show its
  ability to control its own complexity.

34
Method Verification Demonstration (Cont.)

• The phase transition phenomenon will be
  investigated, i.e., a model for phase transition
  (complexity as a function of the parameter
  characterizing the amount of change) will be
  developed and then used by the proposed system.
• The adaptability of the system will be tested by
  changing parameters in the constraints during the
  system operation. The definition of a parameter
  to measure the adaptability will be part of this
  research.
• Another aspect of the evaluation of the system is
  the quality of solutions to multi-objective
  optimization problems it finds. Towards this aim
  the solutions will be compared to known benchmark
  approaches.

35
Order Negotiation Experiment

• The second experimental system is an order
  negotiation system for a marketing or sales
  department of a manufacturing company.
• The objective of the manufacturer agents is to
  fill the orders coming from the customers
  according to the profitability and the
  constraints forced by the labor and raw material
  levels.
• The objective of the customer agents is to
  minimize the purchase price of a product.

36
Order Negotiation(Adaptation in Manufacturing
agent)
37
Plan Completed Tasks

• Formalization of a software agent in UML
• Implementation of the OCL parser
• Design of the schema for OCLML
• Design of the negotiation algorithm
• Formalization of the fixture design experiment
• Formalization of the order negotiation experiment
• Specify the ontology for expressing goals and
  constraints
• Express the goals and constraints of fixture
  design experiment in OCL

38
Plan Remaining Tasks Schedule

• Implement the generic code generator (weeks 1
  and 2 of Nov)
• Implement the translation rules file for OZ (by
  the 2nd week of Dec)
• Implement the template code for agents in OZ
  (by the end of Dec)
• Implement the QoS module for agents in OZ (by
  the 1st week of Jan)
• Identify the phase transition invariants and
  regions for Fixture Design experiment (by the 2nd
  week of Jan)
• Implement the benchmark program for Fixture
  Design experiment (by the end of Jan)
• Execute and analyze the Fixture Design
  experiment (week 1 of Feb)
• Express the goals and constraints of Order
  Negotiation experiment in OCL (week 2 of Feb)
• Identify the phase transition invariants and
  regions for Order Negotiation experiment (week 3
  of Feb)
• Implement the benchmark program for Order
  Negotiation experiment (by the 1st week of Mar)
• Execute and analyze the Order Negotiation
  experiment (week 2 of Mar)
• Analyze and specify the methodology used in the
  determination of phase transition invariants (by
  the 2nd week of Apr)
• Complete writing the thesis (by the end of Apr)

39
Support Slides

• OCL parser CSP code generator
• Self-controlling software architecture
• Ontology for multi-objective optimization
  problems

40
OCL Parser Code Generator
UML models in XMI
Constraint Code Generator
Graphical UML Tool
CSP solver language
OCL Parser
OCL in intermediate XML form (OCXML)
Goals and Constraint in OCL
Text Editor
Translation Rules
Ontology
XML Editor
41
Ontology for multi-objective optimization
package FXTConstraints -- Minimizes the the
number of pins that are NOT connected to any
channels. context FXTObjective1() pre
constraint1 P-gtforAll(p1,p2 p1 ltgt p2 implies
DesignerPC(p1) ltgt DesignerPC(p2)) pre
constraint2 P-gtforAll(p p.Rec()-gtforAll (r
DesignerPC(p).Cap()-gtincludes(f_map(r)))) post
result ONTMinimize ( DesignerPC_inv(c_NULL)
-gtsize() ) -- Minimizes the number of channel
cards used to prevent the cost hike. context
FXTObjective2() pre constraint1 CC-gtsize() lt
N_CC_MAX pre constraint2 ( DesignerPC(P) -
Set c_NULL)-gtsize() lt N_P post result
ONTMinimize( VXIChassisCont(C)-gtsize()
) endpackage
42
ANTs and Related Research

• Research projects under the Autonomous
  Negotiating Teams (ANTs) program
• CAMERA (ISI / USC)
• ATTEND
• MARBLES (Frank 2001)
• DealMaker (Szekely 1999)
• MICANTS (Vanderbilt University)
• MAPLANT (van Buskirk 2002)
• ADEPT (Jennings 1996, Jennings 1998)

43
Issues with self-adaptive software

• Evaluation of the functionality and the
  performance at run-time
• Dynamism and software architecture
  representations for self-adaptive software
• Degrading run-time performance while evaluating
  the outcomes of computations
• The effort to develop software capable of
  evaluating and reconfiguring itself
• The lack of adequate metrics for the degree of
  robustness and adaptation

44
Agent Model
Other Agent
Negotiation Thread
Agent
1
QoS Module
1
1

action()
1
1
1
Knowledge Source
T

0..1
Model Estimator
1
0..1
Knowledge Source Template
1
1
action()
1
alpha beta tactic cumulativeScore
action()
1
1
1
CSP Solver (Plant)
0..1
0..1
Controller
Controller Designer
action()
action()
action()
45
Glossary (C)

• k-Conjunctive Normal Form (k-CNF) A boolean
  formula that is an AND of clauses, each of which
  is an OR of exactly k distinct literals. E.g. A
  3-CNF formula.
• k-satisfiability It is a logical formula  in
  CNF-form over n variables. Given such a logical
  formula, the problem is to decide whether there
  exists a combination of truth values for the n
  variables that makes all the clauses of  true (we
  say that such a formula is satisfiable).

46
Glossary (K)

• k-colorability Given facts about vertex(v),
  arc(v,u), and available colors col(c), the
  problem is to find an assignment of colors to
  vertices of a graph such that vertices connected
  with an arc do not have the same color.

47
Glossary (N)

• NP-complete A problem which is both NP
  (verifiable in nondeterministic polynomial time)
  and NP-hard (any other NP-problem can be
  translated into this problem). Examples of
  NP-hard problems include the Hamiltonian cycle
  and traveling salesman problems.
• NP-hard A problem is NP-hard if an algorithm for
  solving it can be translated into one for solving
  any other NP-problem (nondeterministic polynomial
  time) problem. NP-hard therefore means "at least
  as hard as any NP-problem," although it might, in
  fact, be harder.