Skip to content
LightJason - AgentSpeak(L++) for Java
Branch: developing
Clone or download
Latest commit 87bc023 Apr 18, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
src
.gitignore
.gitmodules
CNAME add cname Jul 13, 2018
bdi.png
circle.yml
code_of_conduct.md
contributing.md
issue_template.md
license.md reduce complexity Nov 2, 2015
pom.xml
readme.md fix shield Mar 30, 2019

readme.md

LightJason - AgentSpeak(L++)

Circle CI Coverage Status Maven Central

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

Structure

You can’t perform that action at this time.