JAUS Architecture Overview

Why did we need JAUS? “Stove-Pipe” Design Subsystems common to all Unmanned Systems (US) were previously built from scratch for each unique system System Dependency Performance gains made by one system could not be easily leveraged by a different system with a similar requirement Vendor Dependency Technology transfer efforts provided “technology nuggets” that could not be rapidly incorporated into existing systems

Why use a “Joint Architecture?” Reduce Vendor Dependency To avoid being “locked into” a vendor’s solution To avoid being “locked out” of technology advancements Reduce Life Cycle Costs Lower maintenance (e.g. software) costs Lower training requirements Reduce development time Rapid prototype development Rapid system engineering by focusing on new requirements Expand existing systems with new capabilities Enable Joint Development Robotic system interoperability

What are the JAUS pillars? Vehicle Platform Independence Mission Isolation Computer Hardware Independence Technology Independence

JAUS Timeline October 1995 Joint Architecture for Unmanned Ground Systems (JAUGS) formed by the Unmanned Ground Vehicles/Systems Joint Project Office February 1998 The Office of Secretary of Defense (OSD) Joint Robotics Program (JRP) officially issued a charter for the JAUGS Working Group (JAUGS WG) The JRP issued a mandate requiring that all of the programs it managed must comply with JAUGS August 2002 The OSD expanded the charter to make the standard compatible with all classes of unmanned systems Renamed Joint Architecture for Unmanned Systems (JAUS) The new charter specifically called for the working group to transition JAUS to a commercial, international standard April 2004 The JAUS WG achieved adoption by the SAE Aerospace Avionics Systems Division (ASD) as the Unmanned Systems Committee (AS-4) Spring 2005 Navy mandates JAUS for all UUV and USV systems See Supplemental Document on Website AIR D3 - JAUS History

JAUS Working Group Domain Model Reference Architecture Part I – Architecture Framework Part II – Message Definition Part III – Message Set Sub-Committees OCU and Payloads (OPC) Transport (Ethernet / RS-232) World Modeling Mission Planning …

SAE AS-4 Working Group Sub-Committees Architecture Framework (AS-4A) Network Environment (AS-4B) Information Modeling and Definition (AS-4C) Task Groups Experimentation Weapons Mission Planning World Modeling …

JAUS System Topology SYSTEM Subsystem 1 Subsystem 2 Subsystem N Node 1 Node 2Node 3 Node N Component 1 Component 2Component 3Component N

JAUS System Topology System Logical grouping of one or more Subsystems Typically grouped to gain some cooperative advantage between the constituent Subsystems Example system might group the following subsystems One or more operator control units (OCU) One or more static sensor installations One or more vehicle Subsystems working towards a common goal

JAUS System Topology Subsystem Independent and distinct unit within a System Address is a value from 1 to 254 Uniquely identifies the Subsystem A System is comprised of Subsystems A robotic vehicle An OCU

JAUS System Topology Node Independent and distinct computing resource within a Subsystem Contains at least one CPU Has exactly one Node Manager Component Address is a value from 1 to 254 Examples include: Actuator Controller Motion Feedback and Control World Model Knowledge Store A Subsystem is comprised of one or more Nodes

JAUS System Topology Component Lowest level of decomposition in architectural hierarchy Cohesive software unit that provides a well-defined service or set of services Generally speaking, a component is an executable task or process Address is a value from 1 to is reserved for the Node Manager A Node is comprised of two or more Components

JAUS Notation and Conventions Joint Technical Architecture (JTA) Department of Defense Joint Technical Architecture, Version 3.1, March 2000 The International System of Units (SI) NIST Special Publication 330, 1991 Edition, The International System of Units (SI). Conventional Terrestrial Reference System World Geodetic System (WGS84), MIL-STD 2401, 11 January, 1994 The National Imagery and Mapping Agency (NIMA) Technical Report , Third Edition DoD World Geodetic System 1984, Its Definitions and Relationships with Local Geodetic Systems, 4 July 1997 Vehicle Coordinate Systems Consistent with ANSI/AIAA R , Recommended practice for Atmosphere and Space Flight Vehicle Coordinate Systems Selected portions adapted for ground vehicles Figure 2.1, Part II Manipulator Link Notation Figures 2.2 – 2.4, Part II

Other Architectures National Institute of Standards and Technology (NIST) 4D/RCS Temporal, Hierarchical Architecture NATO STANAG 4586 Primarily UAV interoperability NIST Autonomy Levels for Unmanned Systems (ALFUS) Establishes standard definitions for the levels of autonomy for unmanned systems Evolution Robotics’ ERSP Proprietary Robotic Development Platform