Skip to content

JAUS Services

JAUS uses a Service Oriented Architecture in which a JAUS Service defines a capability that could exist within an unmanned system. For example, if a Component supports the PrimitiveDriver Service, that Component is capable of moving the robot using a simple, open-loop control mechanism.

Services are defined using the JAUS Service Interface Definition Language (JSIDL) and are represented by input messages, output messages, internal events, and a protocol behavior (which is the behavior of the service when messages are received or internal events occur).

Individual JAUS Service definitions are found under multiple SAE JAUS Service Set documents such as:

  • AS5710A - JAUS Core Service Set
  • AS6009A - JAUS Mobility Service Set
  • AS6057A - JAUS Manipulator Service Set
  • etc

Information about JSIDL can be found in:

  • AS5684B - JAUS Service Interface Definition Language

Note

See the FAQ for information on obtaining all SAE JAUS documentation.

Client-Server Relationship

JAUS Services function in a server-client relationship such that a Component can act as a server for a Service, as a client of a Service, or both a server and a client. The JAUS Standard documents only define server side behavior, and leaves the client side behavior mostly up to the implementer. As such, when the term "JAUS Service" is used, it is most commonly referring to the server side of the interaction.

Messages

A JAUS Service defines a set of messages that are used to interact with the Service by triggering transitions within the protocol behavior of the Service. In general, there are input messages and output messages which are divided into three categories:

  • Command Messages

    Messages that trigger some change within the Service. These are always input messages to the Service (server) and output messages from the (Service) client.

  • Query Messages

    Messages that trigger a corresponding Report message from the Service. These are always input messages to the Service (server) and output messages from the (Service) client.

  • Inform Messages

    Messages that are sent by the Service to inform other Components of some event or state change. These are always output messages from the Service (server) and input messages from the (Service) client. They can be futher sub-divided into:

    • Report Messages

      Messages that are sent in response to a Query message.

    • Confirm Messages

      Messages that are sent in response to a Command message.

Internal Events

A JAUS Service can also define a set of internal events that trigger transitions within the protocol behavior of the Service similar to messages. However, internal events occur within the Service or Component itself and are not triggered by other Components.

Protocol Behavior

When a message is received or an internal events occurs, a Service must perform some action in order to be useful. The behavior of the Service in response to these events can be modelled as a Finite State Machine (FSM) and can be split into two parts: the protocol behavior, and the application behavior.

The protocol behavior defines how and when the Service should respond to messages and internal events. This includes the state transitions that occur when a message is received, the messages that are sent in response to a message, the internal events that are triggered by a message, or the actions that should be executed.

The application behavior defines the internal behavior of the Service in response to an incoming message or internal event. This behavior is specific to the Service implementation and can vary depending on the context under which the Service exists, such as the type of unmanned system (Air, Ground, Underwater, Surface) being implemented or the hardware what is being interfaced with.

Given that JAUS cannot (and does not seek to) specify the internal behavior required for every context under which a Service can exist, the JAUS Standard documents only define the protocol behavior of a Service and leave the application behavior up to the implementer. However, a Service does define a set of conditions and actions that must be implemented to achieve the intended behavior of the Service.

Actions

The actions defined in the protocol behavior of a Service are the set of operations that a Service must perform to accomplish the specific capability defined by the Service.

For example, the VelocityStateDriver Service is responsible for controlling motion using velocity based commands. If it is added to a Component that controls the movement of a robot, then the Component would be responsible for moving the robot using velocity based commands. As such, there is an action defined within the VelocityStateDriver Service that is responsible for setting the desired velocity. However, how the desired velocity is achieved would depend on the specific robot implementation.

Conditions

The conditions defined in the protocol behavior of a Service are the set of requirements that must be met in order for the Service to perform an action or for a transition to occur.

For example, the VelocityStateDriver Service requires that the message to set the desired velocity must have been sent by the client that currently has control of the containing Component. If the message was not sent by the controllint client then Service will ignore the message.