SRTA: The Soft-Real Time Agent Control Architecture

1. SRTA:The Soft-Real TimeAgent Control Architecture Bryan Horling, Victor Lesser, Regis Vincent, Thomas Wagner presented by Anita Raja

2. Agent Control • Most multi-agent research addresses inter-agent activities • The intra-agent mechanics are just as important… • Control affects the potential level of flexibility and sophistication for entire agent • Generality, efficiency, reliability… • Solid general control architecture provides foundation for further research

3. Motivation • Several existing research artifacts… • Task modeling • Planning and scheduling • Coordination • Previous work done in simulation • New more demanding domain (ANTs) • Real-time • Uncertain • Resource-bound • More realistic conditions • Desire to merge these technologies into a cohesive, functional, reusable entity

4. Soft Real-Time Architecture • Plan and schedule to solve goals • Resource constraints • Task interaction constraints • Deadlines and earliest start times • Merge new goals with existing ones • Adjust interleaved schedules as necessary • Handle unexpected deviations in execution • Address time-related failures • Resolve conflicts from failed actions

5. Soft Real-Time • Hard real-time: formally bound and quantitatively describe performance • Soft real-time is a looser metric • Tasks may still have value if time bounds are exceeded by small amount • Our interest is to be statistically “fast enough” • Can target more uncertain domains • Better handle unexpected events • For motivating domain, tasks should be performed within ±500ms of scheduled time

6. SRTA Context • Operates at the middle agent layer • API formed of two parts… • Function accessors • TÆMS modeling language • Comprised of several components • Co-exists in JAF framework with other components Domain Problem Solver Soft Real Time Architecture JAF Controller

7. TÆMS is a goal decomposition planning language Tasks represent goals or sub-goals Methods are primitive actions that can be performed QAFs dictate how tasks accrue quality Interrelationships specify interactions between nodes TÆMS Task Structures

8. Java Agent Framework • Component-based design, similar to JavaBeans • Individual components are well-encapsulated and potentially ‘autonomous’ • Components organized much like a miniature multi-agent system • Intra-agent interactions in the form of • Direct method invocation • Indirect common data handling • Event delivery and receipt

9. Soft Real-Time Architecture Other Agents Negotiation Problem solver Reasoning Goal Description Update Expectations TÆMS Library TÆMS Structure Learning DTC-Planner Resource Modeler Resource Uses SRTA Linear Plan Schedule Failure Partial Order Scheduler Conflict Resolution Module Multiple Structures Schedule Failure Parallel Schedule Task Merging Parallel Execution Module Results

10. Goal Instantiation • Goals are represented using TÆMS • May be dynamically created, or read from static files • pTÆMS allows for parameterized, template-like structure definitions (spec_method (label Track-Medium) (agent Agent_A) (supertasks Track) (earliest_start_time 500) (deadline 2000) (outcomes (Outcome (density 1.0) (quality_distribution 5.0 0.5 1.0 0.5) (duration_distribution 750.0 1.0) (cost_distribution 0.0 1.0) ) ) ) (spec_commitment (label commitment-1) (type deadline) (from_agent Agent_A) (to_agent Agent_B) (task Track) (earliest_start_time 500) (deadline 2000) )

11. Planning(developed by Tom Wagner) • Goal planning by Design-to-Criteria scheduler • Select the most appropriate set of end-to-end actions from a structure • Considers action and plan duration, quality, cost, interrelationships, constraints • Reasons about mandatory and optional requirements, with respect to desired plan criteria • Differentiated by reasoning over ‘soft’ conditions Slider Criteria/ Importance Model

12. Scheduling • DTC was designed as a single-structure scheduler • Multiple goal structures must be merged, or assumed independent • Merged structures are larger, slower to schedule • Goal independence is an impractical condition • A more flexible approach is needed

13. Partially Ordered Scheduling (developed by Regis Vincent) • Partial ordered scheduler analyses DTC plans • Determines task-based precedence constraints • Resource modeler detects resource constraints • Builds a precedence graph, used for scheduling and rescheduling • Key: Leverage DTC’s existing expertise

14. Resource Modeler • Creates and maintains timeline of expected uses of resources • Distribution based: probabilistic start time, duration and quantity consumed or produced • Used by scheduler to find and bind appropriate times for methods • Used by execution component to monitor resource level expectations

15. Schedule Merging • STRA natively supports multiple concurrent, interdependent goals • PO Scheduler considers prior precedence graphs when scheduling new tasks • Conflicts avoided by “shifting” methods based on graph information • Avoids monolithic rescheduling • …but retains the flexibility to modify prior scheduling results as needed

16. Execution • Method execution is assumed to be in parallel • Constraints (resource, interrelationships, etc.) are validated before method is started • Failed constraints require rescheduling • PO Scheduler precedence graphs are again used for quick shifting where possible • Results are reported to other components and checked for failures

17. Future Work • Provide an end-to-end model of performance bounds • Add anytime character to techniques • Meta-level reasoning system to control level of effort and resource expenditure