LightJason - AgentSpeak(L++)
LightJason - AgentSpeak(L++)

Based on the project Jason by Jomi F. Hübner and Rafael H. Bordini a Java 9 implementation has been build-up with parallel execution calls. The version defines an additional AgentSpeak(L) grammar based on AntLR for simulating a multi-agent system with a fuzzy-based logical calculus and grammar features like lambda expressions. Agent execution based on a mathematical structure to describe an optimizing process by a finite-state-machine

Requirements

Development

Base Definitions

Belief

  • Beliefs implicitly describe the current state of the agent
  • Beliefs will be updated before the cycle is run (beliefbase uses an update mechanism)
  • Beliefs must be exists iif an expression is computed (beliefs can be exist on the fly)
  • Belief addition triggers a plan with the definition +belief
  • Belief retraction triggers a plan with the definition -belief
  • Belief modification with -+ does not exists anymore
  • Variables within a belief literal will be unified before the belief is added to the beliefbase

Action

  • Actions will be run immediately
  • Actions can fail (fuzzy-logic false) or succeed (fuzzy-logic true)
  • There is no difference between internal and external actions
  • Actions with @-prefix wil be executed in parallel (each inner action will be run in parallel)

Plan

  • Plans are sequences of actions, rules and/or achievement / test goals
  • Plans has got an optional context, that defines a constraint for execution (default is fuzzy-logic true and matches always)
  • Plans fail iif the defuzzyfication returns fuzzy-logic false
  • Plans returns a boolean value which defines fail (fuzzy-logic false) and success (fuzzy-logic true)
  • Plans run items in sequential order on default
  • If the plan calls an achievement goal addition, the goal will be added for the next cycle
  • An achievement goal deletion does not exists anymore

Internals Constants

  • The plan has got additional constant variables, that are added in the context condition (values are calculated before plan execution is started)
    • PlanFail stores the number of fail runs and PlanFailRatio normalized value in [0,1]
    • PlanSuccessful stores the number of successful runs and PlanSuccessfulRatio normalized value in [0,1]
    • PlanRuns number of runs of the plan (fail + successful runs)

Fuzziness

  • Fuzzy value must be in [0,1]
  • Each action in a fuzzy-plan returns also a fuzzy value to define the fuzziness
  • The plan or rule result returns fuzzy-logic true / false and the aggregated fuzzy value

Rule

  • Rules are similar to plans without the context condition
  • Rules cannot be triggered by a goal, so they must be called from a plan
  • Rules will be executed with the prefix $
  • Rules run immediatly
  • Rules run sequentially on default
  • Rules returns a fuzzy-logic result for success or fail
  • Variables will be passed, so if a rules succeed the value of the variable will be passed back to the calling plan

Rule / Plan Annotation

  • Annotations can modify a plan / rule behaviour to change runtime semantic
  • The following annotation can be used
    • @Constant( AnyValue, 5 ) creates the given constant variable
    • @Atomic the plan / rule cannot be fail, it returns always true (only the actions can fail)
    • @Parallel all items will be run in parallel

Goal

  • Semantically a goal marks a certain state of the world an agent wishes to bring about [AgentSpeak, p.40]
  • Achievement goals triggers an achievement goal addition which leads to the execution of a corresponding plan
  • On agent start, there can exists one initial goal only (like the main function in Java or C/C++)
  • Each agent can track more than one goal at the same time otherwise the agent idles (the suspending state is not used)
  • Goals are triggered by external events which will match by the goal name
  • Goals will be resolved into plans with equal name (and allowed context), the plan is the intantiiation of the goal
  • Goals are run in parallel independed from other goals
  • A goal is a sequence of plans which must all finished completly
  • A goal is part of exactly one intention
  • If a goal can match a desire (the goal is near to the desire) it can add an event to match the desire belief
  • If the agent is in sleeping / hibernate state and the wakeup method is called, it triggers the wakeup-goal

Test Goals

  • A test goal is an atom with the definition ?literal
  • The test return true iif a plan with an equal literal is within the current execution context (current running)

Intention

  • An intention is the convex hull of its goals
  • The intention is set of of goals, which must exist simultaneously
  • Intentions cannot be in conflict with other intentions, so there dies not exists any overlaping

Desire

  • A Desire is a vertex of the edge of all intentions
  • Desires are defined by a set of beliefs
  • Desires can be in conflict with other desires, represented that the desires have got a large distance (much as possible)
  • The desire is successfully reached, iif all beliefs are existing anytime

Variable

  • Variables are written with an upper-case letter at begin
  • Thread-safe variables for parallel runtime start with @ (at-sign) followed by an upper-case letter
  • Variables can store a literal or string to call a rule or plan e.g. !X(3,2) calls a plan or $X(2,1) calls a rule

Action / Term Annotation

  • In LightJason one can specify HOW actions and terms will be executed / unified.
  • Concept of action-term-annotations allows to annotate actions, and terms to perform
    • unification (>>)
    • parallel execution (@), see Variables and lambda expressions.
    • ...
  • If more than one action-term-annotation is needs to be added, they have to be ordered according to the rule: First HOW, then WHAT, e.g. @>> (parallel unification)
  • To annotate multiple actions/terms brackets (,) can be used. See the following examples
  • Examples
    • @>>( foo(X), X > 1 ) && Value > 0.5 (unify foo(X) and X > 1 in parallel and if this results in a true statement check whether Value > 0.5)
    • >>foo(X) && X > 1 && Value > 0.5 (unify foo(X), then test the following terms sequentially)

Graphical Representation

Structure