1. The JAUS Tutorial

2. Problem Statement Subsystems common to all Unmanned Systems (US) are built from scratch for each unique system. Performance gains made by one system cannot be easily leveraged by a different system with a similar requirement. Current tech transfer efforts provide “technology nuggets” that may not be rapidly incorporated into existing systems.

3. The Challenges of a Joint Architecture (JA) To avoid being “locked into” a vendor’s solution. To avoid being “locked out” of technology advancements. To support all classifications of control (teleop, semi-autonomous) and all classifications of systems (combat, combat support, combat service support). To support the evolution of a system from one classification to another. To be usable under current acquisition guidelines.

4. The Purpose of a JA Reduction of Life Cycle Costs Lower maintenance (e.g. software) costs Lower training requirements Reduction of development time Rapid prototype development Rapid system engineering by focusing on new requirements Framework for technology insertion Expand existing systems with new capabilities System Specifier should define behaviors and performance : Performance Specs, Technical Architectures, Open Systems

5. Evolutionary Acquisition $ Cost of Technology $ Time Field systems with today’s reliable & affordable technology JAUS defines current interfaces and message services Insert new technologies as they become reliable & affordable Research & Development expands JAUS to support new capabilities and services through standardized messages and components JAUS standard interfaces designed to be independent of technology JAUS component specifications foster competitive market place for multiple solutions

6. Robotic Evolution Human Decision Robot Autonomy /Intelligence 0% 100% 0% 100% Pure Teleoperation Obstacle Detection Obstacle Avoidance Road Following Feature Identification Target Recognition Route Planning Adaptive Behaviors Situational Awareness Mission Planning

7. Systems Engineering Issues Life cycle costs EMD, production, deployment, operation & support, disposal Schedule Risk Management Technical, schedule, cost Performance-based requirements What to build, not how to build Open systems interfaces (e.g. open standards)

8. Requirements for an Effective JA Open to all of the robotics community Either developed by Government, or Developed by Gov/Industry team with Government sponsorship Required in all solicitations Performance specs, SOWs, SOOs, RFPs, BAAs, etc Continual updates Configuration management Domain Models Architecture

9. Objectives of a JA Hardware Platform Independence Mission Isolation Computer Hardware Independence Technology Independence Operation Independence Hardware Platform Independence Mission Isolation Computer Hardware Independence Technology Independence Operation Independence

10. Current JA Strategy Develop a domain model of the ground-based Warfighter with his functions, knowledge, and interfaces. Define capabilities that the robotic system must perform. Develop a reference architecture that defines a set of components, messages, and standards for node integration. Encourage participation in Working Group. Working Group evolves documents to meet the needs of the unmanned systems community.

11. Domain Model A requirements model of the User “What does the Warfighter do, what does the Warfighter know, and with what does the Warfighter interface?” Encapsulate similar functions into groups called Functional Agents (FA). Encapsulate similar knowledge (e.g. maps) into groups called Knowledge Stores (KS). Encapsulate similar devices into groups called Device Groups. Each FA and KS has a set of capabilities that define its capability with a defined set of services. Written in the language of the User

12. Reference Architecture Defines a system topology consisting of Operational Subsystems, Nodes, and Components. Defines specific components and their interfaces (messages), based on the services and capabilities specified in the domain model. Defines methods for message passing, and standards to support component integration. Designed to support dynamic changes in runtime configuration. Does not presuppose a particular hardware design. Does not presuppose a particular technology. Written in the language of the scientist/engineer.

13. Other Documents Standard Operating Procedures How the JAUS Working Group conducts business. Document Control Plan How the JAUS documents are managed. Strategic Plan Compliance Plan (in draft)

14. Structure of the Working Group JAUS Working Group Jeff Kotora - Chairman Reference Architecture Woody English AFRL SOP Fred Proctor NIST Document Control Daniel Carroll SSC San Diego Domain Model Robert Wade AMCOM Strategic Planning Jeff Kotora Titan/OSD  Facilitate widespread adoption to commercial standards.  There are 60 voting members which represent over 29 organizations. Compliance Plan Robert Wade AMCOM Transport Steve Clift Remotec

15. JAUS Domain Model … RSTA Internal State Sensors Test Equipment Comm. Devices External Training Devices CommandTele-Communication Maintenance TrainingMobility Control Devices Mission Modules Mechanical Payloads LibraryLog Vehicle Status World Model

16. JAUS Domain Model Details Functional Agents (6) Command, Tele-Communication, Mobility, Payloads, Maintenance, and Training Knowledge Stores (4) Vehicle Status, World Map, Library, and Log Simple Systems can remain simple while providing a growth path for more complex functions.

17. Mobility Components Primitive Mobility Vector Mobility Vehicle Centered Mobility Waypoint Mobility Obstacle Detector Obstacle Avoider

18. Remaining DM Capability Descriptions Command Responsibility to make plans, assimilate data, make decisions, assign tasks, handle unexpected events. Vehicle Commands orders a single robot. Squad Commands orders a team of robots. Platoon Commands orders a platoon (e.g. a set of squads) of robots. Tele-Communication Responsibility to manage communications between distinct vehicles and OCUs.

19. Remaining DM Capability Descriptions (continued) Payloads Maintain control and provide status of payloads. RSTA, weapons, NBC detector, back hoe,... Maintenance Responsibility to maintain system, such as BIT/BYTE, and interface with external test equipment. Training Responsibility of providing training support to the operator either internally (e.g. mission rehearsal, tutorials) or, with external training devices (DIS,...)

20. Remaining DM Capability Descriptions (continued) Vehicle Status Responsibility to provide status of the vehicle to the other agents. Vehicle parameters, position, visual and audible data, clock (not real time) and calendar. World Model Responsibility for maintaining repository of objects of interest including friendly and threat units, obstacles, etc., as well as terrain data and features. Shall also maintain plans.

21. Remaining DM Capability Descriptions (continued) Library Responsibility to maintain reference material, procedures, and performance data. Log Responsibility to maintain a log of operational, maintenance, and training data.

22. Reference Architecture

23. Reference Architecture Requirements Consistent with DoD Acquisition Guidelines Performance Specification; what, not how. Open Systems Standards. Augments the Joint Technical Architecture (JTA). Support Domain Wide System Evolution Independent of specific hardware and technology. Path for technology transfer from laboratories and research organizations. Migration of capabilities (inter and intra-system) in support of higher levels of autonomy, and leveraging technological advances across the domain.

24. Reference Architecture Requirements (Continued) Support the Diverse Environments and Missions of the Warfighter. Support for mixing and matching of modular payloads in the field (i.e. Plug-and-Play). Reuse of payloads/subsystems across the domain, where cost, size, weight, power, etc. allow. Safety and Security Consistent behavior for safety operations, i.e. emergency stop. Protect against enemy assuming control of vehicle. Protection of sensitive data and software.

25. Units and Coordinate Reference Frames 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 8350.2, 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-004-1992, Recommended practice for Atmosphere and Space Flight Vehicle Coordinate Systems. Selected portions adapted for ground vehicles.

26. Physical System Topology Node Comp Node Operational Subsystem System... Node... Comp...

27. Physical Topology Description A System is composed of one or more Subsystems. Examples of operational subsystems are an Operator Control Unit or a vehicle. A Subsystem is composed of one or more Processing Nodes. A processing node contains at least one CPU and is synonymous with a GOA Stack. A Processing Node has exactly one Message Routing Service (MRS). A Processing Node contains one or more Components.

28. SAE Generic Open Architecture (GOA) Stack GOA Stack Class 4L Class 3L External Environment Interface System Services Class 3X OS Services XOS Services Class 4D Class 3D Resource Access Services Class 2D Resource Access Services Class 1D Class 2L Physical Resources Physical Resources Class 1L Class 4L Class 2L Class 1L Other Nodes or Operational Subsystems Application SW

29. Scope of Reference Architecture Component OS Services Component Message Routing Service (MRS) Resource Access Services Physical Resources 4L Component Messages 4L 4D 4D MRS API (Future) 3L Messages Data Formats 4D (JTA) 2L JTA 1L JTA 1D JTA JAUS Xport

30. Node Integration Future Enhancement – Expansion Port (JAUS Xport). Work is currently underway to specify a JAUS expansion port that will define the lower level logical interfaces (i.e. GOA Class 2L and 1L) and physical connections (GOA Class 1D) in order to support a common payload port. This additional specification would support the rapid change out of payloads and other sub- systems in the field. Full Node Integration can be achieved by combining the JAUS component/message set with additional specification by the acquiring agency of the lower levels of the GOA Stack.

31. JAUS Road Map Stage 1 Component and Message Definitions, Data Formats, and Internode Messages Reduce integration effort of a node developed for one system onto a different system Stage 2 Expansion Port for Payloads Adds the additional GOA interfaces (2L, 1L, and 1D) for a common internode communication stack for payloads. Stage 3 Dynamic Registration (Cold) Supports Plug- and-Play of nodes via automatic system configuration at power up Stage 4 Dynamic Registration (Hot) Supports Plug-and- Play of nodes while the system is powered up Stage 5 MRS API Standard interface for software components to the message passing services of the node.

32. Architectural Style “Data Upon Request” style Data flow between nodes is not specified apriori. Data flow is accomplished either by a command message, a query-inform message set, an event setup-notification message set, or by establishing a periodic flow of data via a service connection. Designed to support dynamic changes in data flows during operation, and to support modular system reconfiguration in the field, i.e. interchange of modular payloads. Support for Multiple System Architectures Cyclic, clock-driven designs Event-driven designs Hybrid system designs

33. Inter-Component Communications Two Methods of Data Transfer Messages Aperiodic or periodic data flow Messages are queued Service Connections Periodic data flow Service Connection message is not queued Write to Service Connection overwrites the previous data.

34. Inter-Component Communication Node 2Node 1 MRS Component B Component A Service Connection Write ReadWrite Read Internode Communication Channel Queue # # # # Get Put Service Connection

35. Sequence Diagram of Messages and Service Connection SC_Terminate 105 CommandPosition Vehicle Position 12550 SC_Confirm 102 SC_Suspend 104 SC_Activate 103 Vehicle Position 12550 … Periodic Vehicle Position 12550 … Periodic SC Message Headers Contain Sequence Number Increasing Time Query Vehicle Position 12500 SC_Create 101

36. Components

37. Common Component State Transition Diagram Operational Initialize StandbyReady Power Off ShutdownFailureEmergency Resume Standby Shutdown Reset Emergency Clear Emergency Reset Shutdown [Non-recoverable Error] * see note * The transition from Startup can be to either Ready or Standby. Optional State Required State Reset [Non-recoverable Error]

38. Driving Control Loops Vector Mobility Primitive Mobility Position Wrench Message Actuator Control Vehicle Motion Velocity Feedback Vector Mobility Message

39. Tele-Communication Component Inter-Operational Subsystem Communication Operational Subsystem Operational Subsystem Comp Comp Comp Comp Comp Comp Comm Component Comm HW Comm Component Comm HW Tele-Communication acts as a router for messages between operational sub-systems. It handles the hardware interface to comm devices. It also manages the bandwidth of the comm channels, and enforces tactical comm behaviors.

40. Camera Coordinate Frame For Position and Orientation Z X Y From observer’s view point, camera Z-axis is coincident with the centerline of the lens. Camera rotations follow the right hand convention. Panning to the right is a positive rotation about the camera’s Y-axis. Tilting up is a positive rotation about the camera’s X-axis.

41. Transport Newly established committee examines the electrical interfaces for payload integration. Incorporating JTA standards UDP-TCP UDP/TCP established JAUS socket port #3794 RS232

42. Contact Information www.jauswg.org