330 likes | 434 Views
MICANTS. Jon Doyle Robert Laddaga Vera Ketelboeter (MIT). George Bloor (Boeing) Russ Currer (Idea Services). Gabor Karsai Benoit Dawant Greg Nordstrom Chris vanBuskirk Karlkim Suwanmongkol Patrick Norris Jonathan Sprinkle (Vanderbilt/ISIS). MICANTS Research Goals. How to use
E N D
MICANTS Jon Doyle Robert Laddaga Vera Ketelboeter (MIT) George Bloor (Boeing) Russ Currer (Idea Services) Gabor Karsai Benoit Dawant Greg Nordstrom Chris vanBuskirk Karlkim Suwanmongkol Patrick Norris Jonathan Sprinkle (Vanderbilt/ISIS)
MICANTS Research Goals • How to use • Model-Integrated Computing, and • Agent/Negotiation technology to solve complex resource management problems in (Autonomic) Logistics • To demonstrate the feasibility of the technology through real-life example(s)
Roles • Vanderbilt/ISIS • MIC, implementation, and demonstration • MIT • Concepts, algorithms • Boeing • Modeling, domain knowledge • Idea Services • Domain expertise and scenarios, customer interface http://www.isis.vanderbilt.edu/Projects/micants/micants.htm
Model and analyze negotiation protocols Source of complexity: Coordinating agent behavior with the negotiation protocol(s) Synthesize code for negotiation engine Generator Negotiating Agent Coordination Engine MIC for ANTSSupport for negotiation protocols The MIC solution: The problem: Complex agents that participate in multiple, simultaneous negotiations are hard to write Status: working prototype is in use on the project
Legacy DBase Source of complexity: Coordination of the agent’s data model With legacy database’s schema MIC for ANTSSupport for legacy system integration The MIC solution: The problem: Negotiating agents have to access legacy databases,writing access code is tedious and error-prone. Model legacy database schema and agent ontology Synthesize code for agent database interface Generator Negotiating Agent Legacy DBase Database Interface Status: modeling environment prototype has been built. Note: This approach is beneficial for systems without a data warehouse.
Constraints Constraints Agents/Negotiation Technology CONFLICT manages manages negotiation Mutually acceptable, Negotiated solution satisfies satisfies Objective: “Good enough solutions/soon enough”
Demonstration domainMaintenance logistics (simplified): Unscheduled aircraft repair Current practice:Manual process MMCO (sister squadron) MMCO negotiate discrepancy report Negotiate/barter negotiate Assign mechanic negotiate W/C OIC Flight Schedule Shop Maintenance Schedule
MMCO (sister squadron) MMCO options options options approve approve approve Vision: Agent-supported Maintenance Process MAPLANT MAintenance PLanning AgeNTs Goal:Assistance through offering negotiated options Commander’s Intent negotiate report W/C OIC discrepancy report Assign mechanic Autonomic response negotiate Agents: • “Helpers” for the users • Implement CO’s intent, business rules, and user guidance • Negotiate solutions autonomically • Offer options for approval negotiate Flight Schedule Shop Maintenance Schedule CAUTION: Simplified picture
MAPLANT Prototype • Agents to support users • Schedule generated: mechanics + time • Create schedules based on constraints • Task: starts after, ends before, requires resource (mechanic) • Number of resources + qualifications • Planning window size • Incrementally schedule new tasks and assign mechanics to them based on constraints
Current prototype Agents for the users • Work Center Supervisor’s Agent • Schedules calendar-based MAs • Proposes schedule(s) • Schedule displays (with options) Maintenance Control Chief’s Agent • Receives and logs gripes • Negotiates with MALS and W/C-s • Barters with sister squadron • Shows canni options • Event status display • Event/AC assignments • AC status over time • “What-if”s • Helper “agents” • Aircraft (health status) • Mission (events, flight schedule) • Jobs (maintenance actions) • Workers (maintainers) • MALS
Current prototype Agent operations • Constraint-based scheduling: • Task “start-after”s, “ends-before”-s, and durations • Task precedence • Resource constraints • Alternatives/flex assignments M/C Startup Event Status Board (M/C) • Event times • EVT/AC assignment • A/C status (OK, down, repair) • W/C Startup • Schedules calendar-based MAs • Input: • Job list with time and MOS requirements • Worker pool with qualifications • Output: • Jobs scheduled and assigned to workers • Helper startup • Aircraft (health status) • Mission (events, flight schedule) • Jobs (maintenance actions) • Workers (maintainers)
Current prototype Agent operations • MALS: • Reply with time for part availability M/C receives gripe/diagnosis • Status Board: shows conflicts • Selection: A/C + Gripe • Options: • Standard procedure (MALS) • Barter (with other M/C) • Canni (if possible) • Evaluation: • Comparison of options • Check effects on flight schedule • Changes: • Accept/refuse proposed MA • AC to event assignment • Sister squadron M/C: • Reply with time for part availability • A/C in maintenance: • Reply with time parameters • W/C operation: • Reactive (re-)scheduling • Input: • New job with time and MOS requirements • All “old” jobs • Output: (for approval) • Multiple schedule options for new job
Current prototype Agent operations • W/C “smarts” • Rapid schedule generation • Multiple schedule options • Options are evaluated/ranked • Flexible schedule choices • Tentative scheduling choice, confirmed later M/C “smarts” • Shows/warns about conflicts with flight schedule • Keeps track of current/pending MAs • Displays available options when “repairing” AC/EVT allocations • Detects A/C in repair that can be utilized in canni • Can arrange barter with other M/C’s agent • “What-if” • Effect of the selected MA on the flight schedule • Suggests possible optimizations • Swaps (possibly with other squadron) • “Milking” • Initial data from warehouse: • Aircraft (health status) • Mission (events, flight schedule) • Jobs (maintenance actions) • Workers (maintainers)
ApproachScheduling and negotiation as CSP Explicit management of constraints during negotiation/scheduling Negotiating agent Coordination Engine Messaging “High-performance” encoding techniques Data structures representing domain constraints Domain-specific API to the scheduler Schedule Domain-independent SAT techniques Constraint SAT mapper (encoding) Standard SAT Interface (CNF, etc.) • Complexity management: • Encoding strategy • SAT Standard SAT Problem Solver (Tableau,WSAT,ISAMP)
ApproachEncoding a scheduling as binary SAT • Precedence: pr(i,j) • Starts after: sa(i,r_i) • Ends before: eb(i,d_i) • Coherence: • sa(i,t) -> sa(i,t-1) : starts at or after t-1 • eb(i,t) -> eb(i,t+1): ends at or before t+1 • sa(i,t) -> NOT eb(i,t+P-1): requires time P • sa(I,t) AND pr(i,j) -> sa(j,t+P): conflicting task cannot start until first task finishes • Resource constraints: # {c(i,j)} < Cap SCALING: Polynomial in #Tasks, #Resources, #Slots Based on Crawford/Blake 1993
ApproachAddressing timeliness issues Negotiating agent REAL-TIME RESPONSE: • Monitor situation and progress • If needed, modify process Coordination Engine Messaging SAT Engine Monitoring Evaluation Reconfiguration Reconfigurator Technology for achieving time-bounded results • Flexible negotiation with monitored execution and reconfiguration (MIT) • Schedule generation via constraint-satisfaction: • Explicitly represent current tasks as constraints • Monitor SAT engine execution for timeout • Relax constraints when SAT does not converge • Utilize SAT engine solutions DYNAMICS/STABILITY: • SAT Engine (TBD)
Scalability of the SchedulerFirst and second approach • 10hrs window, 1hr/task, M:mechanics, T:tasks, T = 2M • Memory usage • WSAT engine
Scalability of the SchedulerFirst and second approach • 10hrs window, 1hr/task, M:mechanics, T:tasks, T = 2M • Run time • WSAT engine
Scalability of the SchedulerImproved approach • 10hrs window, 1hr/task, M:mechanics, T:tasks • Memory usage • WSAT engine
Scalability of the SchedulerImproved approach • 10hrs window, 1hr/task, M:mechanics, T:tasks • Run time • WSAT engine
Resource management through automated negotiation Key concept: • Resolving resource conflicts through negotiation Dynamic Negotiation Strategies: “Scripts” for negotiation Plans specify structure of complex negotiations Composing complex strategies from elemental methods Dynamic Negotiation Goals: Changing the objectives on-the-fly Strategic progression changes goals Changing situation changes goals, then strategy • Dynamic Negotiation Preferences: Changing priorities • “Invention” of preferences to cover new situations • Toughening or liberalizing negotiation position Dynamic Negotiation Organization: Changing partners Relation of agent to others depends on strategy, situation, and history Construct “proximity groups” along different relational dimensions Structure strategies to exploit these proximity groups
Resource management through automated negotiation Addressing timeliness issues: Real-time performance Negotiating agent Coordination Engine Messaging Monitor situation and progress If needed, modify negotiation process Monitoring Evaluation Reconfiguration Reconfigurator Technology for achieving time-bounded results • Flexible negotiation plans with monitored execution and reconfiguration • Fast methods for evaluating complex decision functions • Anytime strategies -- incremental, reactive • Problem decomposition/solving/ and solution integration
Negotiation complexity • Complexity-aware negotiation monitors expected difficulty of solution construction • Estimates of negotiation time and result quality build on estimates from base CSP, preference management subsystem, and negotiation strategy structure • Agent adjusts or renegotiates constraints to speed solution construction or failure determination using preferences about constraints
Negotiation for options • Negotiation outcomes represent options to MMCO in decision-support activity • Alternative deals using same preferences or making different modifications of preferences • Simultaneous and serial options from concurrent and sequential negotiation stages
Domain modeling Boeing
The Maintenance Action Form “Life Cycle” Open MAF Closed MAF • At the Marine Corp Base, in Yuma Arizona, a maintenance action form (MAF) is opened when any repair or equipment modification is made to a Harrier. • The MAF can be used to trace many of the intricate details of the maintenance related decisions.
Balance average Life Usage Across Fleet w/ Immediate Mission Goals Balance Scheduled Maintenance w/ Reactive Maintenance Minimize Down Time by Overlapping Maintenance Schedules Balance Night Crew Maintenance w/ Greater Daytime Parts Availability Balance Current Mission Aircraft Count against Aircraft Degradation History Balance Throughput Across Maintenance Shops Balance Pilot Skills The Maintenance Action Form “Life Cycle” Balance Open MAF
Modeling the Decision Support Environment The Maintenance Action Form “Life Cycle”
Modeling the Decision Support Environment The Maintenance Action Form “Life Cycle”
Explicit Business Process Models • Resource Allocation - Allocate: Space, Time, Material, Equipment, People Next Step Implicit Business Process Models • Strategies, Decision Making - Shift Change MAF Triage
Plans • Framework refinements • Time management • Optimization engine • Sophisticated constraint management in scheduler • Complexity experiments/discussions • Interface with complexity contractors • Demonstrations • Interaction with MAG-13 personnel • Initial Assessment Milestone (next Summer) • Integration with ISI’s CAMERA • Plan: staged approach • Leading towards negotiation between the flight and maintenance schedulers