LARA Conceptual Components

Memory

Preprocessor

Pre-Processing Concept

Pre-processor

The pre-processing stage consists of several pre-processing components:

  • Mode Selection
  • Collection of behavioural options from the agent's memory
  • Pre-selection of behavioural options
  • Updating of behavioural option's utilities
  • Updating of agent's preferences

For each component exist classes (potentially implemented by the user), and which classes to use is defined in an instance of LaraPreprocessor, which also provides the components (cp. Builder design pattern). Such a pre-processor is assigned to every agent. For efficiency and configuration reasons many agents may share an instance of pre-processor, and to prevent side effects instances are immutable. To adapt a pre-processor configuration, LaraPreprocessorConfigurations are used. Individual components may be assigned to a configuration (possibly different components for different decisions) and a configuration then provides the appropriate pre-processor. The interplay between pre-processor components is accomplished by agent-specific event busses.

LARA Pre-Processing

BO-Preselector

This component checks whether current conditions allow the agent to apply a particular BO that is considered by the LaraBoCollector for investigation.

Usually, only the BO itself knows which conditions are required and can decide about its applicability (e.g. a BO compares environmental conditions to their valid range).

To reflect the agents different perspectives on whether an option is applicable or not, LARA defines certain modes of accuracy that guide the pre-selection of behavioural options:

  • ASK_AGENT: Causes the preprocessor to step back to the agent (this requires the user to implement LaraBOPreselectingAgent).
  • ACCURATE: Most accurate preprocessor handling
  • MODERATE: Moderate preprocessor handling
  • TOLERANT: Tolerant preprocessor handling

The user may add custom modes for accuracy by implementing the interface LaraPreprocessor.Accuracy. Implementations of LaraBOPreselector need to specify whether they consider the mode of accuracy, and in case they do, how they do.

For instance, accuracy could be interpreted in terms of number of parameters that fall out of the application range. Possible variations:

  • Redirect checks to BO (default)
  • Do not check and declare every BO as valid
  • Do generous checks
  • Do pedantic checks

Decision Making

Decisions including preferences (LaraPrefrence) that are relevant to them and the mechanism that is applied to identify the finally chosen BO (LaraDecider) are defined by LaraDecisionConfigurations. The decision configuration is defined once and passed to the agent's decide method whenever that decision shall be performed.

LaraDecisionData objects persist only during the decision process from preprocessor to actual decision making and contain all required data. LaraDeciderFactory objects are registered at the LaraDecisionData, usually during pre-processing, and are responsible for creating the LaraDecider object which executes the decision making. The factories are selected and assigned to the LaraDecisionData object at each time step within the preprocessor's LaraModeSelector.

Related information:

  1. How to Design Your Decision

Decision Trees

Decision trees are also a nice feature to achieve contextualisation: traverse the decision tree according to situational context conditions in the preprocessor and fetch BOs and decision mode accordingly [TODO check whether it is possible to store different Habit BOS in the BO memory for different context of the same decision?]. As an alternative, select decisions according to situational context.

Post-Processor