From plexil
Jump to: navigation, search


What is PLEXIL?

Plan execution is a cornerstone in autonomy applications, such as robotics, unmanned vehicles and habitats, and systems or simulations involving intelligent software agents. PLEXIL (PLan Execution Interchange Language) is a language for representing plans for automation.

PLEXIL was designed to meet the requirements of flexible, efficient and reliable plan execution in space mission operations. It is compact, semantically clear, and deterministic given the same sequence of events from the external world. At the same time, the language is quite expressive and can represent branches, loops, time- and event- driven activities, concurrent activities, sequences, and temporal constraints. The core syntax of the language is simple and uniform, making plan interpretation simple and efficient, while enabling the application of validation and testing techniques.

Accompanying PLEXIL is an execution engine, or executive, which implements efficiently the PLEXIL language and provides interfaces to controlled systems as well as decision support systems from which plans may be sent. The PLEXIL software suite also includes a graphical plan execution viewer, a static plan checker, and two different plan simulators.

PLEXIL was originally developed as a collaborative effort between researchers at NASA and Carnegie Mellon University, funded by NASA's Mars Technology Program through the Research Institute for Advanced Computer Science (RIACS) in the Universities Space Research Association (USRA). Since then it has continually evolved through application on NASA projects, which have included the control of prototype planetary rovers and habitats, drilling equipment, and demonstration of adjustable automation for International Space Station operations. See the References for more information on the background and applications of PLEXIL.

PLEXIL Overview

This section is a short overview of the PLEXIL language. It describes abstractly the main features of PLEXIL, and explains how one programs in PLEXIL. The next chapter, Plexil Reference, describes in detail the programming constructs of PLEXIL. The Detailed Semantics chapter covers PLEXIL execution in greater depth.


A PLEXIL plan is built from actions. An action specifies something to do, either within the plan itself, or to the external world. Actions are the composable building blocks from which arbitrarily complex behaviors can be specified. There are currently about a dozen different kinds of actions in PLEXIL, and each is a programming construct specifying a certain behavior.

A PLEXIL plan is a tree of actions with a single root action. This tree represents a hierarchical decomposition of tasks. High level tasks are closer to the root action, while leaf actions represent primitive behaviors such as assigning to a variable or sending a command to the external system.

The following diagram exemplifies a simple hierarchical plan. Its representation in PLEXIL would have a similar tree structure.


Now, let's meet the actions. The following UML diagram illustrates the essence of PLEXIL.


Stacked in a column on the right side of the diagram are the high level actions in PLEXIL.

  • The Concurrence action groups sub-actions to be executed in parallel.
  • The Sequence, Unchecked Sequence, and Try actions group sub-actions to be executed in the order listed, in various different ways.
  • The IfThenElse, While, and For actions provide conditional and iterative execution of sub-actions as implied by their names.
  • The OnMessage and OnCommand actions are used in multi-executive applications and specify response policies.

These high level actions are described in detail in the Plexil Reference chapter.


The bottom row of actions in the diagram above constitute a subset of the langauge called Core PLEXIL. These five actions provide all the computational power of PLEXIL. In fact, all the high level actions described above and shown on the right side of the diagram are translated into Core PLEXIL prior to execution. The Core PLEXIL actions are called nodes. Strictly speaking, only nodes are directly executed by the PLEXIL executive. That is, the final plan executed is a tree of nodes.

Historical note: Originally, Core PLEXIL was the entire PLEXIL language. Core PLEXIL was too primitive to write non-trivial plans, so it was extended with higher level constructs, essentially "macros" that translated into Core PLEXIL for execution; this extended language was called Extended PLEXIL. Today, the full language is simply called PLEXIL (or Plexil).

There are six types of nodes in Core PLEXIL. The interior nodes in a plan are List nodes. List nodes have child nodes (or children) which can be of any type. A List node is called the parent node (or parent) of its child nodes. The remaining nodes are leaf nodes in a plan.

  • An empty node can contain only attributes and performs no action.
  • An assignment node performs a local computation, whose value is assigned to a variable.
  • A command node issues commands to the system being operated on.
  • An update node provides information to the planning and decision-support interface.
  • A library call node invoke nodes located in an external library.


Each action can specify up to eight conditions, which determine its execution and outcome. There are nominal control conditions that specify when the action should start executing, when it should finish executing, when it should be repeated, and when it can be "skipped". These are referred to collectively as the action's gate conditions.

  • A start condition specifies when the action should start execution.
  • An end condition specifies when the action should finish its execution.
  • A repeat condition specifies when the action should be made eligible for a repeat execution.
  • A skip condition specifies when the action's execution should be bypassed altogether.

Next, there are failure conditions that identify when execution is not successful, and these are referred to collectively as a action's check conditions.

  • A precondition is checked immediately after the start condition becomes true. If this check fails, the action will be aborted and have an outcome of failure. Preconditions are often used to verify that it is "safe" to execute the action.
  • A postcondition is checked after the action has completed execution. If this check fails, the action has an outcome of failure. Postconditions are often used to verify that a action had the intended effect.
  • An invariant condition is checked during action execution, and if it fails at any point, the action will be aborted and have an outcome of failure. Invariant conditions are often used to monitor conditions that are needed for the safe continued execution of the action.

Finally, there is a condition that says when to terminate an action "prematurely" (i.e. before its end condition is satisfied), though intentionally.

  • An exit condition is checked during action execution, and if it is satisfied at any point, the action will be aborted though have an outcome of success. The Exit condition can be used to effect deliberate plan cancellation. Its semantics is almost the same as that of the Invariant condition -- the primary difference is a success outcome rather than failure.

Each condition specifies a logical expression. PLEXIL employs a ternary logic in which logical expressions evaluate to one of True, False, or Unknown.


An action may declare variables, which have lexical scope, i.e. they are accessible to the action and all its descendants, but not siblings or ancestors. Access to variables (for reading or writing) can be restricted by use of interfaces in actions. Interfaces are described in the next chapter.

State, Outcome, and Introspection

An action is always in one of seven states, and always terminates with one of three outcomes. The exact semantics for this behavior in Core PLEXIL is given in the Node State Transition Diagrams. A action can (e.g. in one of its conditions) query the state and outcome of itself, its parent, children, and siblings, but no other actions; it can also query the start and end times of any given state of these actions.

External World

PLEXIL reads the state of the external world or system through lookups, which come in several varieties. PLEXIL can affect the state of the external world or system through commands, which are sent asynchronously.


Time (durations, elapsed time, clock time, etc) is often an essential component in automated and simulated systems. PLEXIL has no native concept of time, per se. Time in PLEXIL is just another external state, and PLEXIL has predefined the state named time for its operations that involve time. The expressions in PLEXIL that imply time, i.e. those that give the start and end times of action states, rely on the time external variable, which at present is a unitless real number.


PLEXIL has a simple resource model, described in detail in Chapter 5. In short, resource requirements for commands (only) can be specified in command actions, and these requirements are checked during execution via a resource arbitration mechanism. Simple models of unary, non-unary, hierarchical, and renewable resources are supported.

Programming in PLEXIL

Standard Plexil

There are several means of programming in PLEXIL. The executable form of PLEXIL is its XML representation. While many external applications have generated PLEXIL code in its XML form, the XML form is not practical for authoring PLEXIL directly.

The standard programming syntax for PLEXIL is described in this manual. It is simply called Plexil, or sometimes standard Plexil. A translator for Plexil, which converts user programs into Core PLEXIL XML, is described in the next chapter.

Note that the terms "PLEXIL" and "Plexil" can refer to the abstract PLEXIL language (actions) and/or to its standard programming syntax.


There is an alternative programming syntax for PLEXIL called Plexilisp, which resembles the Lisp programming language, and utilized the Emacs editor for interactive plan authoring.


As mentioned in the previous section, the executable form of PLEXIL is represented in XML (Extensible Markup Language), a widely used standard for information modeling. Although a PLEXIL user does not normally need to be concerned with XML, it is important to note that the formal specification of PLEXIL's syntax is given at the XML level. Core PLEXIL is specified by XML schemas. More information about PLEXIL XML is given in the chapter titled "PLEXIL, XML, and Emacs".

The PLEXIL Community

We have two mailing lists:

  • plexil-discussion email will be sent to anyone interested in PLEXIL.
  • plexil-support email will be sent only to the PLEXIL developers.

Please feel free to add yourself to plexil-discussion using the Sourceforge mailing lists

Copyright (c) 2006-2014, Universities Space Research Association (USRA). All rights reserved.