Developing Simple Agents Using Decision-making Modeling and the R-CAST Architecture

 

 

Matt Prindible

The Laboratory for Intelligent Agents

College of Information Sciences and Technology

The Pennsylvania State University

 

Credits:

Initiate: J. Yen

Initial Design: S. Sun, X. Fan, G. Airy, B. Sun

Design Discussion: S. Sun, G. Airy, B. Sun, R. Wang, S. Zhu

Design: S. Sun

Implementation: S. Sun

Design and Implementation Support: M. Davis

Paper: X. Fan, S. Sun, J. Yen, M. McNeese, B. Sun, G. Airy

Tutorial: M. Prindible

 

 

 

 

    What is R-CAST?

    The R-CAST architecture

    The R-CAST cognitive model

    The R-CAST information management model

    Objectives

    Developing a scenario

    Getting started

    Overview

    FactTypes

    Rules

    Facts

    Configuring the AKB

    Agent batch process file

    The AKB user interface

    Commands

    Asserting facts and validating rules

    Status check

    Overview

    The RPD process model

    ExperienceSpace

    Experiences

    Configuring the EB

    The RPD user interface

    Status check

    Overview

    Operators

    The Domain Adapter

    Plans

    Processes

    Choices

    Configuring the PM

    The PM user interface

    Status check

    Final configurations

    Request Whiteboard

    Information Manager

    Identifying syntax errors

    Identifying logic errors

    Runtime

    Status check

    Multi-agent systems and information sharing

 

    Sample experience base file

    Sample process file

    Sample configuration file

Figure 1.1: The R-CAST Decision-making Process Model

Figure 1.2: The R-CAST Cognitive Model

Figure 3.2: FactType Simple Syntax

Figure 3.3: FactType Formal Syntax

Figure 3.6: Facts Simple Syntax

Figure 3.8: Knowledge Base Configuration

Figure 4.1: Flat ExperienceSpace Structure

Figure 4.2: Hierarchical ExperienceSpace Structure

Figure 4.6: Experience Base Configuration

Figure 4.8: The RPD Transition State Flow Chart

Figure 4.9: The RPD User Interface

Figure 5.7: Process Manager Configuration

Figure 5.10: The Process Manager User Interface

Figure 6.1: Request Whiteboard Configuration

Figure 6.2: Information Manager Configuration

Figure 6.3: The Information Manager User Interface

Figure 6.4: Handling Requests Through the Request Whiteboard User Interface

Figure 7.2: Component Configuration

 

 

 

 

 

 

 

 

 

 

Driving to State College on a regular basis presents several unique problems that can change with each and every trip. Gas prices, road construction, and traffic bottlenecks affect travel differently each day. In order to select the best route of travel, all variables must be taken into consideration. With gas prices expected to rise this summer, the shortest route would be the most obvious result. However, with construction on I-99 changing on a day-to-day basis, the ability to get to State College on time and without wasting precious gas while sitting in traffic can be compromised. Taking the back roads to State College has absolutely no road construction, but is considerably longer (in terms of distance). However, on some occasions (when construction is heavy, and/or traffic is backed up in Port Matilda) the back route can be faster. Although all variables are heavily interrelated, each of these variables has a certain precedence over one another. For example, getting to State College on time is more important than saving a marginal amount of money on gasoline, sitting in construction on I-99 for a marginally longer period of time during times of lower gas prices is acceptable, and of course, in the event of a tie, I-99 is accepted because it is the easier route. Based on the current conditions of each variable for each day and past driving experiences, it is up to the agents to assist in a decision on which route to take.

 

 

Before we start, it may be helpful to consider some of the following syntax:

 

 

 

 

 

(FactType laneClosed (?route ?numberOfLanes))

 

FactTypes can also utilize other functions such as template, source, and time (called formal syntax). The template function is used for parsing facts from natural language, or converting facts to natural language. A time value represents the amount of time before a fact expires. This time can also be change for specific instances of the FactType. Sources are used in multi-agent collaboration, a source is used for an agent planning an investigation, or support of evidence.

 

    (source (roadConstructionAgent getLanesClosed))

 

This fact type is now able to assert facts into the knowledge base and query the knowledge base using natural language (covered in ‘The AKB user interface’), investigate and retrieve the information from a plan getLanesClosed from another agent named roadConstructionAgent. This particular FactType has an expiration time of 60 seconds, meaning a new fact must be asserted within this time. However, each instance of FactType laneClosed can have its own, unique expiration time.

 

For defining the remaining FactTypes in this agent’s environment, and completing its schema, we return to the scenario. Several other candidate FactTypes (including the previous road construction FactType) include a gas price, the added or gained utility from the gas price, conditions of road construction such as a lane being closed or traffic being stopped, and conditions of traffic such as its density. All of the FactTypes for this example can be defined using the previously described simple syntax because this example only requires one agent, and for the time being, we will not be using natural language assertions or queries. At this point in time, our agent’s knowledge base is populated with a generalized description of its environment, or a schema.

 

 

    (< ?gasPrice 2.95)

    (gasPriceUtility low)                                          # Consequent state

 

This particular rule, named determineHighGasPrice contains the logic and conditions necessary for the agent to make decisions about whether or not a certain gas price is high or low. If after comparing the value stored in the variable ?gasPrice of an instance of the FactType gasPrice to a pre-determined value of 2.95 (called the antecedent), the condition is true, the variable ?utility in an instance of gasPriceUtility will be set to ‘low’ (called the consequent state). By combining rules and facts, the agent can generate a series of implied facts. In this particular example, with a gas price of $3.15, an agent can imply that the price of gas is high.

 

 

 

If the FactType was defined using the formal syntax, the Fact should also use the formal syntax. The formal syntax for a Fact closely resembles the formal syntax for its FactType (sans the variables, obviously). This fact now contains a source with a method to get the information (for support of evidence) and an expiration time of 60 cycles.

 

(Fact laneClosed (I99 1)

    (source (highwayObservationAgent howManyLanes))

    (time 60)

 

Along with defining facts directly in the knowledge base, facts can also be asserted into the knowledge base through the user interface. Asserting facts through the user interface does not only make the agent a little more dynamic, but it also serves as a method to validate a knowledge base.

 

 

 

 

java -jar r-cast.jar Travel_Opt_Agent.conf

 

 

 

 

 

 

 

For example, in the sample application for this tutorial, if the user wanted to check to see that the rules defining the utility lost from road construction, the user would begin by asserting the facts necessary to fire the rule. In this case, the facts trafficStopped, and laneClosed must be asserted.

After asserting these facts into the database and after selecting roadConstruction from the FactType Selector, the IDR Fact Instance Level shows that now the road construction in I99 is high based on the asserted facts, and based on how the rule was originally intended to function, this rule is valid.

 

 

A flat experience base structure such as the one above can have a very small depth, but the breadth of experiences can be very large. Recognition in this particular model relies heavily on retrieving due to the unorganized nature of the experiences and therefore closely resembles a method of case based reasoning.

A hierarchical, or structured experience base (as seen above) can have a very large depth, but at its most efficient structure, the breadth of experiences can be very small. This particular model is very organized and recognition relies more on indexing, and therefore more closely resembles a decision tree.

 

 

The agent begins its experience recognition in situational analysis. At this stage, the agent decides whether or not it can recognize a past experience, or if it must plan an investigation for the missing information (feature matching). If the agent recognizes a situation, or its investigation is complete, the agent performs a mental simulation of the planned course of action (the plan written for each experience --covered in the process manager). During mental simulation, the agent applies the rules that constrain it to its environment from the knowledge base, along with the expectancies, goals, and results from the last experience and determine whether or not that particular course of action will work. Assuming the course of action is valid and accepted, the agent will implement the course of action. Lastly, after the course of action is completed and the agent is satisfied, the new experience will be added to the agent’s experience base. The agent will now be able to use this experience for quicker recognition or support for the next time.

 

 

 

In this particular ExperienceSpace, the expectancy (after this ExperienceSpace has been cued) is that the condition in the agent’s active knowledge base is that goToSC will have a value ‘yes.’ In this particular instance and in most others, if the expectancy and the anomaly are both triggered, there is an inherent flaw in the agent’s knowledge base. However, if the expectancy is not triggered and an anomaly occurs, another course of action should be investigated. In this example, there would be no need for the agent to determine the most economical route of travel if there is no need to travel. Finally, as in the ExperienceSpace structures modeled above, each ExperienceSpace can be broken down into a reference to another ExperienceSpace or an experience. In this example, the ExperienceSpace is broken down into two possible experiences triggered by the cue goToSC yes.

 

 

 

In this example, several cues such as a high level of road construction on I-80 (roadConstruction I80 high), and a dense amount of traffic on I80 (traffic I80 high) trigger the agent to use this particular experience (takeRouteI99) when these conditions in the agent’s environment exist. If the agent recognizes and matches this experience with the current condition of its environment, the agent will proceed to monitor the expectancies and anomalies while it simulates the course of action to reach its goal. In this case, the agent will expect that if the course of action taken in this experience is implemented, that it will end up in State College (in StateCollege), the agent will avoid the course of action if for some reason it ends up somewhere else (in somewhereElse). Assuming there is no anomaly, the agent will simulate the course of action and if the result is successful (the goal has been satisfied), the agent will implement the course of action.

 

 

 

Also, in addition to these values in the decision making module section of the configuration file, the agent’s overall configuration must also include the decision making implementation (along with the knowledge base implementation).

 

 

The second visualization within the RPD user interface is the attention monitor, and its function is to represent the cognitive load and which experiences have the attention of the agent. In a situation more complex than the one in this sample agent, the visualization dynamically changes as the agent attempts to recognize prior experiences based upon the current conditions of the agent’s environment. The visualization attempts to keep what the agent is most concentrated on toward the center of the monitor.

 

 

 

(operator print)

 

Operators can also include a set of preconditions and effects as parameters for an operation. Like an experience, the operator can have one or many preconditions, in the case of many preconditions, they are evaluated conjunctively. During evaluation, if the precondition is not satisfied, the process will enter the wait state (as seen in the figure above). Effects are conditions that should be produced after the operation is complete. In the case of another example (not directly related to the one in this tutorial), a counting operator, there are necessary preconditions and effects.

 

 

 

(operator count (?number)

    (precondition (nextNumber ?number ?next))

    (effect (not(currentNumber ?number)(currentNumber ?next))

)

 

 

 

public void action(String command, Vector args) {

    if (command.equalsIgnoreCase(“print”)) {

        System.out.println(pretyString(args));

     }

}

 

Most likely, in other examples, the use of a series of else if statements will allow other operator instructions to be defined. Instructions can also contain calls to other classes for use of more complex operations. For example, in order to utilize the speech synthesizer within R-CAST, the instruction creates a new instance of SpeechSynthesizer(pretyString(args)) and calls the speak( ) function within the class.

 

public void action(String command, Vector args) {

    if (command.equalsIgnoreCase(“print”)) {

        System.out.println(pretyString(args));

         } else if (command.equalsIgnoreCase(“speak)) {

                  if (config.ifSpeak( )) {

            new SpeechSynthesizer(pretyString(args)).speak( );

                  }

         }

}

 

 

In order to use the domain adapter, the agent’s configuration file must be modified to include its implementation. This is a required component of the agent and the following values must be added to the agent’s configuration file.

 

 

 

(plan takeRoute (?route)

     (effect  (in StateCollege))

     (process

          (print take ?route))

)

 

Missing from this particular plan from this example is the fail condition and termination condition. Plans can also contain instructions to launch a contingency plan in the event that the fail condition is met. In the following code snippet, the contingency plan if the fail condition is met calls another plan called planCountBack.

 

    (failcondition (< ?to ?from))

    (contingency (planCountBack))

    (termcondition (currentNumber ?to))

    (process

        (planCountCurrent)

    )

)

 

 

 

 

(process

     (choice bigOrSmall

          ((prefcondition (> ?number 7))

          (prefcondition (< ?number 3))

               (print small))

          ((default) (print normal))

     )

)

 

In this example, the value of the variable ?number is evaluated based on two preferred conditions. Within each condition is an action which can be either a plan or an operator. In the event that the value of ?number does not meet any of the other conditions, (?number is 3, 4, 5, 6, or 7) the default action is executed which can also be either a plan or an operator.

 

 

 

Also, in addition to these values in the process manager of the configuration file, the agent’s overall configuration must also include the process manager implementation (along with the knowledge base implementation and experience base implementation).

 

 

 

 

 

 

 

 

 

 

 

 

anticipateProcessFailCondition = true

anticipateRPDCue = true

anticipateRPDExpectancy = true

 

In the event that there is missing information, the Information Manager handles the scheduling and completion of investigations. Requests for an investigation are handled by the Request Whiteboard. It is important to note that in order for the Information Manager to complete its investigation there must be a way for the agent to pull information, either through directly asserting facts into the agents knowledge base, or executing a plan to gather information. These requests and investigations can be seen by using both the Request Whiteboard and the Information Manager user interfaces.

 

 

 

A request for an investigation is handled through the Request Whiteboard (as seen in the previous figure). A request named ‘Investigate Information’ has been requested by the RPD module for facts about roadConstruction (I80 ?utility). This particular request is being handled by the information manager.

 

 

 

 

 

 

 

 

agentComponents = kbImpl decisionImpl processImpl domainImpl imImpl

 

 

 

 

#

#    Agent Knowledge Base File for Agent "Travel_Opt_Agent"

#

 

#    The Fact Types

    

    (FactType gasPrice (?gasPrice))

    (FactType gasPriceUtility (?utility))

 

    (FactType roadConstruction (?route ?utility))

    (FactType laneClosed (?route ?numberOfLanes))

    (FactType trafficStopped (?route ?howLong))

    

    (FactType traffic (?route ?utility))

    (FactType trafficStatus (?route ?density))

 

    (FactType goToSC (?yesOrNo))

    (FactType in (?where))

 

#    The Rules

 

    (Rule "determineHighGasPrice"

        (gasPrice ?gasPrice)

        (>= ?gasPrice 2.95)

        ->

        (gasPriceUtility high)

    )

 

    (Rule "determineLowGasPrice"

        (gasPrice ?gasPrice)

        (< ?gasPrice 2.95)

        ->

        (gasPriceUtility low)

    )

 

    (Rule "determineHeavyRoadConstruction"

        (laneClosed ?route ?numberOfLanes)

        (>= ?numberOfLanes 1)

        (trafficStopped ?route ?howLong)

        (>= ?howLong 10)

        ->

        (roadConstruction ?route high)

    )

    

    (Rule "determineModerateRoadConstruction"

        (laneClosed ?route ?numberOfLanes)

        (eq ?numberOfLanes 1)

        (trafficStopped ?route ?howLong)

        (< ?howLong 10)

        ->

        (roadConstruction ?route moderate)

    )

 

    (Rule "determineLowRoadConstruction"

        (laneClosed ?route ?numberOfLanes)

        (< ?numberOfLanes 1)

        (trafficStopped ?route ?howLong)

        (< ?howLong 10)

        ->

        (roadConstruction ?route low)

    )

 

    (Rule "determineDenseTraffic"

        (trafficStatus ?route ?density)

        (>= ?density 6)

        ->

        (traffic ?route high)

    )

 

    (Rule "determineLightTraffic"

        (trafficStatus ?route ?density)

        (<= ?density 5)

        ->

        (traffic ?route low)

    )

 

#    The Facts

 

    (Fact gasPrice (2.79))

    (Fact laneClosed (I99 0))

    (Fact laneClosed (I80 2))

    (Fact trafficStopped (I99 3))

    (Fact trafficStopped (I80 20))

    (Fact trafficStatus (I99 1))

    (Fact trafficStatus (I80 7))

 

 

#

#    Agent Experience Base File for Agent "Travel_Opt_Agent"

#

 

#    Experience Space

 

    (ExperienceSpace goToSC

        (Cue (goToSC yes))

        (Expectancy (goToSC yes))

        (Anomaly (goToSC no))

        (Experience (takeRouteI99)(takeRouteI80)

        )

    )

 

#    Experiences

 

    (Experience takeRouteI99

          (Cue (roadConstruction I80 high)(traffic I80 high))

          (Expectancy (in StateCollege))

          (Anomaly (in somewhere))

          (Goal (in StateCollege))

          (Action (takeRoute I99))

          (Result success)

    )

 

 

 

    (Experience takeRouteI80

          (Cue (roadConstruction I99 high)(traffic I99 high)(gasPriceUtility low))

          (Expectancy (in StateCollege))

          (Anomaly (in somewhere))

          (Goal (in StateCollege))

          (Action (takeRoute I80))

          (Result success)

 

 

#

#    Agent Process File for Agent "Travel_Opt_Agent"

#

 

#    Operators

    

    (operator print)

 

#    Plans

    

    (plan takeRoute (?route)

        (effect    (in StateCollege))

        (process

            (print take ?route))

 

 

#

#    Agent Configuration File for Agent "Travel_Opt_Agent"

#

 

#    About the Agent's Overall Configuration (the agent name, must be unique for each agent)

    

    agentName = Travel_Opt_Agent

    agentIcon = agent.gif

 

    # The components of the agents

    agentComponents = kbImpl decisionImpl processImpl domainImpl imImpl

    # comImpl taskImpl recommendImpl resourceImpl

 

    # To show GUI, or not? If false, no GUI will be shown even if you decide to use a component GUI

    useGUI = true

 

    # The relative speed, will affect all component’s speed(cycleSpeed * processClock)

    cycleSpeed = 1.0

 

    # Initial status of agent, stopped if choose "true"

    isStoped = false

    displayedMessage = Count Inform

 

#    About Request Whiteboard (The whiteboard is a built-in component and it is a must)

 

    # The thread cycle time for the whiteboard, in 1/1000 sec

    whiteboardClock = 1000

 

    # Use whiteboard GUI or not?

    whiteboardGUI = true

 

#    About the Domain Adapter

 

    # The domain implementation must be selected when using a process manager

    domainImpl = edu.psu.domainadapter.ExampleDomainAdapter

 

    # Use domain GUI or not, ExampleDomainAdapter doesn't have a GUI

    domainGUI = false

 

#    About the Knowledge Base

    

    # The Knowledge Base implementation

    kbImpl = edu.psu.activeknowledgebase.AKB

 

    # The .kb file for this agent

    kbFile = Travel_Opt_Agent.kb

 

    # The thread cycle time for the KB, in 1/1000 sec

    kbClock = 1000

 

    # Show the KB GUI or not

    kbGUI = true

 

    # If you want to hear a voice when query for a natural reply

    kbSpeakNatrualReply = false

 

#    About the Process Manager

 

    # The implementation of the Process Manager

    processImpl = edu.psu.process.ProcessManager

 

    # The .process specification file

    processFile = Travel_Opt_Agent.process

 

    # The initial process that the agent should execute, null for none

    processInitialProcess = null

 

    # The clock cycle for Process Manager, in 1/1000 sec

    processClock = 2000

 

    # If or not to show the Process Monitor

    processGUI = true

 

    # If you want to enable voice for speak operator

    operatorSpeak = false

 

    # true, process will terminate at end; false, the process will repeat at the end

    # false, then you should define termination conditions to terminate processes

    processTerminateIfEnd = true

 

    # true, a terminated process will be removed from the process set

    # false, if you want to keep dead process (cost more memory)

    processRemoveIfInactive = true

 

    # If the simulation should be in a new (cloned) KB, or in the agent's current KB agent should simulate in a new KB

    simulationNewKB = true

 

    # If precondition is tested, will the result affect the execution of the simulation? true, the result will not affect; false, the failed

    # precondition will stop the simulation

    simulationRelaxPrecond = true

 

    # If the precondition is going to be tested in simulation

    simulationTestPrecond = true

 

    # How many levels will simulation decompose a process

    simulationDepth = 1

 

#    Recogntion Primed Decision Making

 

    # The RPD implementation

    decisionImpl = edu.psu.rpd.RecognitionPrimedDecision

 

    # The cycle for decision as in 1/1000 sec

    decisionClock = 1000

 

    # To show the decision monitor or not

    decisionGUI = true

 

    # The experience specification file

    ebFile = Travel_Opt_Agent.eb

 

    # The root experience

    rpdRoot = goToSC

 

    # Activate retain state or not

    rpdRetainState = false

 

    # Activate evaluate state or not

    rpdEvaluateState = false

 

    # Activate recognition state when decision is done

    rpdRepeatRecognition = false

 

    # How much the degree of similarity should the cues be matched

    recognitionThreshold = 0.6

 

    # How much fail experiences weight compared with success experience

    weightFailExperience = 0.5

 

    # How much anomalies should weight, compared with expectancy

    weightAnomaly = 1.0

 

    # How may decision cycles an agent should wait till reevaluate a anomalied experience space

    anomalyTimeout = 3

 

#    The Information Manager

 

    # The implementation of the Information Manager

    imImpl = edu.psu.irp.InformationManager

 

    # The default investigation strategy

    defaultStrategyImpl = edu.psu.irp.strategy.InqueryOrientedInvestigationStrategy

 

    # The cycle time for the IM, in 1/1000 sec

    imClock = 1000

 

    # To display the IM GUI or not

    imGUI = true

 

    # The default supply mode

    defaultSupplyMode = edu.psu.irp.mode.AskReply

 

    # The default time condition, when information is needed

    defaultRequirementTime = 500

 

    # If to anticipate a precondition

    anticipateProcessPrecondition = true

 

    # If to anticipate a termination condition

    anticipateProcessTermcondition = true

 

    # If to anticipate a fail condition

    anticipateProcessFailcondition = true

 

    # If to anticipate cues

    anticipateRPDCue = true

 

    # If to anticipate an expectancy

    anticipateRPDExpectancy = true

 

    # If to anticipate an anomaly

    anticipateRPDAnormaly = true

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The Laboratory for Intelligent Agents  |  324 Information Sciences and Technology Building  |  University Park, PA 16802