LightJason - AgentSpeak(L++)

Based on the project Jason by Jomi F. Hübner and Rafael H. Bordini an 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

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