Understanding SAE JAUS

The Joint Architecture for Unmanned Systems (JAUS) is an international standard that defines communication protocols for unmanned vehicle systems, some of their internal components, and their interaction with operator control stations. JAUS employs a Service Oriented Architecture (SOA) approach to enable distributed command and control of these systems. The standard defines message formatting for transport between system services, as well as sets of standard services, which describe specific functional components for various unmanned systems capabilities.

The JAUS standards are owned and developed by the Society of Automotive Engineers (SAE) under the Aerospace Standards Unmanned Systems Steering Committee (AS-4). All of the standard documents that define JAUS can be purchased online directly from SAE.

The general purpose of JAUS is the same as any other engineering standard. That is to make products (in this case unmanned systems and robotics) from different manufactures uniform and consistent, in order to enable interoperability, interchangeability, and modularity. The net result reduces procurement cost and human effort in systems integration.

The Basics of JAUS

The main goal of JAUS is to structure communication and interoperation of unmanned systems within a network. At the highest level, JAUS systems are made up of a number of Subsystems. A Subsystem typically represents a physical entity in the system network, such as an unmanned vehicle or operator control unit (See Figure 1). The JAUS network is further subdivided into hierarchical layers. At the next level down, Subsystems are divided into Nodes, which represent a physical computing end-point in the system. For example, a Node might be a computer or micro-controller within a Subsystem. Nodes can then host one or more Components, which are commonly applications or threads running on the Node. Finally, Components are made up of one or more Services. A Service is a logical abstraction that provides some useful function for the system, which has a well-defined message interface and protocol.

Figure 1. A JAUS system is made up of subsystems connected to a common data network. Both unmanned vehicles and operator controls are considered subsystems.

Overview of the standard documents

The SAE publishes the JAUS standard as sets of related but separate documents. A brief summary of some of the standard documents is provided in the table below.
 

The JAUS Service Interface Definition Language (JSIDL)

In order to formalize JAUS as a Service Oriented Architecture (SOA) it is necessary to define exactly what a JAUS service is and how it is intended to operate. This is done using JSIDL, which provides a precise XML schema that can be used to design JAUS services. In JSIDL a service is defined simply as a specific set of input and output JAUS messages, along with a protocol state machine that governs how the messages are to be received, processed and sent by that service. As a hypothetical example, an unmanned system may have a sensor service, which may have specific input messages that control how the sensor performs, whether it is on or off, etc. The sensor may also have specific output messages that report the sensed information. Finally, the sensor service may require its messages to be received and sent in a specific order (first you send me a query message and then I send you a response message). This would be defined by a JSIDL protocol state machine, which we will explain in more detail later.

The intent of JSIDL is to reduce or eliminate any human error that can be introduced when interpreting JAUS standard services. The XML syntax allows the specification of a service to be automatically validated. Additionally, the XML syntax can be used to automatically generate software implementation stubs of services and their messages. This ensures that any human error that might be introduced (when coding the implementation of a message for example) is eliminated. The XML syntax of JSIDL is not intended to be transferred by JAUS systems at runtime. It is only used for the specification of services when they are designed and published in standard. It is up to the individual system engineers to determine how they would like to use the published XML. OpenJAUS uses machine validated syntax to design and automatically generate service code. However, the syntax used by OpenJAUS is not JSIDL directly. This will be discussed in the OpenJAUSv4.0 User's Guide when it is released in the near future.

JSIDL specifies how messages are to be structured in a JAUS service. It does not specify the format of specific messages itself. Rather it defines the format of allowable data fields that may exist in a JAUS message. For example, a message may contain one field that is an unsigned integer, or another field that is a floating point number. JSIDL provides the syntax for how those fields should be called out in another JAUS standard document.

A key feature of JSIDL is that it enables the definition of service protocol in the form of state machines. At first the concept of using state machines to specify online communication protocol may sound strange. However, the concept is actually very simple. In short, a service responds to input messages differently depending upon which state it is in. JSIDL provides an XML syntax that JAUS standard documents can use to outline the structure of a service's state machine(s). From this XML specification of a service, a stub implementation can be automatically generated.

The JAUS Core Service Set (JSS Core)

The primary goal of JAUS is to enable online interoperability of unmanned systems and their components. One of the ways this is accomplished is through a core set of common services that enable the components to transport information to each other, setup event based messaging (similar to publish and subscribe models found in other communications systems), perform online discovery of their services, and others. The JAUS Core Service Set (JSS Core) defines these basic services which are required by most higher level components. For example, some of the JAUS mobility services depend the JSS Core Access Control service which enables the mobility services to be commanded by a single exclusive controlling component. This is a critical function when it is necessary to prevent a service from receiving multiple conflicting control signals from different sources. For instance if your unmanned system is capable of moving through a given velocity command, it is important for that command to come from only one source component during operation, otherwise it might receive velocity commands in different directions, which would be impossible to perform.

The following table summarizes the services defined in JSS Core and what they are used for. This is only intended as a brief introduction. The details of how these services are implemented in OpenJAUS will be provided in the OpenJAUS User's Guide when it is released.
 

How to Learn More About JAUS

The OpenJAUS implementation is intended to reduce the burden on unmanned systems developers in regards to having a complete and thorough understanding of the JAUS architecture. Hopefully you will find that a basic understanding of JAUS and a healthy knowledge about the workings and use of OpenJAUS is enough for you to implement your own JAUS-based systems. However, if you require a more in-depth knowledge about JAUS here are some ways you can learn more.

The OpenJAUS company offers on-site training classes that explain in various levels of detail, the workings both the JAUS standards and the OpenJAUS SDK. These classes are designed for different target audiences, from software developers, to systems engineers and managers. See the OpenJAUS website for more information on how you can have these classes taught directly to your organization at your location.

For organizations that are implementing JAUS systems because they are required to do so in contract or for those needing a more complete knowledge of JAUS, we highly recommend purchasing copies of the standard documents directly from SAE. The documents range in price and you will likely need to purchase a set of multiple documents in order to get a complete picture of how the architecture works as a whole. Keep in mind that these are standards documents and they do not provide detailed instructions or direction for implementing your own JAUS software. For that it would be best to use the documents in addition to using the OpenJAUS code itself as a reference for how implementation is accomplished.

Another approach is to read, and discuss JAUS on our forums. We actively answer questions and respond to comments about both OpenJAUS and the JAUS standards in general. There are also other discussion forums which can be accessed through the Unmanned Systems and Robotics Interoperability Center (USARIC) website.

Finally, if you are interested in staying on top of how the JAUS standard is evolving or if you wish to contribute or change the standards in some way, we recommend attending the SAE JAUS steering committee meetings. The meetings are held twice per year (usually in April and October) at different locations around the USA. Attendees must register ahead of time via the SAE website and pay a registration fee. Anyone is welcome to attend and participate in discussions. Voting on standards is reserved for members of the steering committee, and membership is obtained usually through a process of continued attendance, support and contribution to the meetings and standard documents.