Understanding 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
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 JAUS 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 below.
JAUS Transport Specification (AS5669A)
Specifications for UDP, TCP, and Serial based data transmission of JAUS messages.
Purpose / Description: Standardize the basic format in which JAUS messages will be transported “on the wire” using Ethernet and serial technologies.
JAUS Service Interface Definition Language (AS5684)
Defines the data structures of services, messages and protocol, formalized as an XML schema.
Purpose / Description: Eliminates ambiguity in service and message interpretation, and makes validation / auto generation of code for services possible.
JAUS Human Machine Interface Service Set (AS6040)
Service definitions in JSIDL for HMI interaction that includes drawing, keyboard input, pointing device input, analog and digital user controls.
Purpose / Description: Provide a standard means for human interaction with components in a JAUS network.
JAUS Mobility Service Set (AS6009)
Common mobility services such as global positioning and vehicle platform control defined with JSIDL. Includes message format definitions and protocol written in tables and diagrams.
Purpose / Description: Enable command and control of many different vehicle platforms by defining abstract services that are agnostic to specific vehicle mobility types (ground vehicles, aircraft, etc.)
JAUS Core Service Set (AS5710A)
Low level services such as transport and discovery, defined with JSIDL. Includes message format definitions and protocol written in tables and diagrams.
Purpose / Description: To specify a base set of common services that can be implemented by all JAUS components. This common low level functionality enables basic interoperation.
JAUS Manipulation Service Set (AS6057)
Service definitions in JSIDL for controlling robotic manipulators. Messages are defined generically so they can be applied to many different types of manipulators.
Purpose / Description: Standardizes the command and control of robot manipulators (arms, grippers, pan/tilt, etc.) that may be part on an unmanned system platform.
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.
| Service Name | Purpose | Example Messages |
|---|---|---|
| Transport | Acts as a common gateway for all messages entering an leaving the component. | None |
| Events | Enables other components to request messages from services that inherit from the events service on a fixed periodic or an on-change basis. This is the JAUS equivalent of a publish and subscribe mechanism. | CreateEvent, UpdateEvent, CancelEvent, QueryEvents, RejectEventRequest, Event |
| Access Control | Allows services that inherit from the access control service to be exclusively controlled by a single source component. In turn, the controlled services will only accept commands from their controlling component. This is how JAUS components implement mutual exclusion. | RequestControl, ReleaseControl, QueryControl, QueryAuthority, ReportControl, ConfirmControl |
| Management | Allows client components to control and access information about the internal state of another components function. For example, this allows client components to reset or shutdown a server component. | Shutdown, Standby, Resume, Reset, SetEmergency, ClearEmergency, QueryStatus, ReportStatus |
| Time | Provides an interface for reporting a component’s internal system time to other components. | QueryTime, ReportTime |
| Liveness | Allows client components to establish whether another component is online and responding to message communication. Similar to the concept of a network ping. | QueryHeartbeatPulse, ReportHeartbeatPulse |
| Discovery | Enables components to discover each others presence and allows them to exchange information about which services they implement and support. | RegisterServices, QueryIdentification, QueryConfiguration, ReportIdentification, ReportConfiguration, ReportServiceList |
Want 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.
For more in-depth and personalized help, OpenJAUS LLC offers training and consulting on a case-by-case basis. From full JAUS implementations to on-site training, OpenJAUS specializes in putting JAUS experts to work on our customer’s problems. Leveraging over 20 years of JAUS experience, OpenJAUS LLC can help you solve your JAUS problems today and in the future.