Negotiating Solutions to Multi-objective Optimization Problems

1. Negotiating Solutions to Multi-objective Optimization Problems Yönet A. Eracar Ph.D. Proposal Defense 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 Ph.D. Proposal Defense

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) Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

5. TesterSubsystem::Channel TesterSubsystem::Capability Designer PinChannelAssignment Mapping UUTSubsystem::PinRequirement UUTSubsystem::Pin Fixture sub-system (UML) 1 -mapping 1 -channel -assignmentList -mappingList -mapping 0..* 1 -pin Ph.D. Proposal Defense

6. Fixture Design Experiment Goals & Constraints (OCL) package FXT::Constraints -- Minimizes the the number of pins that are NOT connected to any channels. context FXT::Objective1() pre constraint1: P->forAll(p1,p2 | p1 <> p2 implies Designer::PC(p1) <> Designer::PC(p2)) pre constraint2: P->forAll(p | p.Rec()->forAll (r | Designer::PC(p).Cap()->includes(f_map(r)))) post: result = ONT::Minimize ( Designer::PC_inv(c_NULL)->size() ) -- Minimizes the number of channel cards used to prevent the cost hike. context FXT::Objective2() pre constraint1: CC->size() <= N_CC_MAX pre constraint2: ( Designer::PC(P) - Set{ c_NULL})->size() <= N_P post: result = ONT::Minimize( VXIChassis::Cont(C)->size() ) endpackage Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

8. Multi-Objective Optimization Problem (MOOP) Fixture Design Problem is a special case of MOOP Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

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? Ph.D. Proposal Defense

12. Candidate Components of a Solution • Well-known algorithms, like weighting objectives, goal programming, ε-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. Ph.D. Proposal Defense

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) Ph.D. Proposal Defense

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 relaxation:when the CSP is over-constrained, some constraints can be relaxed to find a solution (e.g. Hierarchical CLP – Borning 1989). Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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 c<c3 is almost surely satisfiable. 2. A random formula with c>c3 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. Ph.D. Proposal Defense

18. Candidate Components of a Solution • Herbert Simon’s satisficing approach: • Search for an optimal solution can be terminated, when: • The decision maker’s 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. Ph.D. Proposal Defense

19. Candidate Components of a Solution • Zilberstein (1998) summarizes the open issues on Simon’s 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? Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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) Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

28. Information Flow User tools and environment vs. our system 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 Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

36. Order Negotiation(Adaptation in Manufacturing agent) Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

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) Ph.D. Proposal Defense

39. Support Slides • OCL parser & CSP code generator • Self-controlling software architecture • Ontology for multi-objective optimization problems Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

41. Ontology for multi-objective optimization package FXT::Constraints -- Minimizes the the number of pins that are NOT connected to any channels. context FXT::Objective1() pre constraint1: P->forAll(p1,p2 | p1 <> p2 implies Designer::PC(p1) <> Designer::PC(p2)) pre constraint2: P->forAll(p | p.Rec()->forAll (r | Designer::PC(p).Cap()->includes(f_map(r)))) post: result = ONT::Minimize ( Designer::PC_inv(c_NULL)->size() ) -- Minimizes the number of channel cards used to prevent the cost hike. context FXT::Objective2() pre constraint1: CC->size() <= N_CC_MAX pre constraint2: ( Designer::PC(P) - Set{ c_NULL})->size() <= N_P post: result = ONT::Minimize( VXIChassis::Cont(C)->size() ) endpackage Ph.D. Proposal Defense

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) Ph.D. Proposal Defense

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 Ph.D. Proposal Defense

44. Negotiation Thread Reconfigurer 1 startTime endTime deadline score goal Other Agent Agent Model Negotiation Thread Agent 1 QoS Module 1 1 * action() 1 1 1 Knowledge Source T * 0..1 1 Model Estimator 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() Ph.D. Proposal Defense

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). Ph.D. Proposal Defense

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. Ph.D. Proposal Defense

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. Ph.D. Proposal Defense