INTEGRATION OF AUTONOMOUS SYSTEM COMPONENTS USING THE JAUS ARCHITECTURE

Transcription

1 INTEGRATION OF AUTONOMOUS SYSTEM COMPONENTS USING THE JAUS ARCHITECTURE Shane Hansen Autonomous Solutions, Inc. Phone: (435) Fax: (435) Abstract One of the major factors relating to the commercial success of autonomous vehicles will be ease of component integration. Autonomous vehicles often require multiple components that span languages, interfaces, and hardware. The difficult task of combining these systems requires an effective architecture that allows for integration of autonomous vehicle components independent of technology, hardware, and vehicle platform. Standards such as JAUS (Joint Architecture for Unmanned Systems) provide a template that allows for technology insertion, reuse, and standardization of autonomous vehicle components. This paper focuses on the necessary framework for component integration of multiple heterogeneous autonomous vehicles. Autonomous Solutions Incorporated (ASI) utilizes the JAUS architecture to facilitate the commercialization of autonomous durability test vehicles for facilities such as the Goodyear proving grounds. This implementation is profiled to illustrate the benefits of system architecture for autonomous vehicle components. Keywords: Integration, architecture, autonomous, unmanned vehicle, JAUS Introduction:

2 Integration is the process of integrating, which is to form, coordinate, or blend into a functioning or unified whole. System integration of autonomous vehicle components is a difficult and expensive task. The number of autonomous vehicles and their application domains increase every day. The technologies that enable these vehicles will continue to evolve to meet industry needs. Autonomous vehicles include components such as positioning systems, sensors, actuators, controllers, cameras, and data repositories that all have different interfaces. Many vehicles are built ground up with the needed components in mind. These systems typically hard-code the component interfaces. This produces a problem when a component changes or new components are needed. It becomes necessary to understand and modify every part of the system affected by the component change. This process is time-consuming and costly. The commercialization of autonomous vehicles requires a common architecture to allow components to be added, removed, and modified without affecting the rest of the system. Architecture examples Architectural design commonly employs the activities of system structuring, control modeling, and modular decomposition [1]. System structuring is the division of the system into sub-systems where a sub-system is an independent unit. Control modeling describes the methods in which sub-systems will interact with each other. Modular decomposition sub-divides each subsystem into modules that perform specific tasks. Architectural design may follow a particular style or model; however, most large systems are composites of several models. This paper discusses functional, objectoriented, and real-time design strategies to illustrate how the JAUS architecture extracts the effective parts of each.

3 Function-oriented design has been used on many autonomous vehicle systems. Function-oriented design decomposes the system into a set of interacting functions that share a common system state. Algorithm details are concealed in functions but system state is global. Function-oriented design is efficient because components have direct access to state variables. The disadvantage is that a change to one function can leave the system in an unexpected state. This design strategy works well for transactionprocessing and business applications because their output depends on a single input. Autonomous vehicles have multiple inputs that can transition the vehicle to diverse states. Object-oriented design is based on information hiding. It is different from the functional approach because it views a system as a set of objects, each with their own state, rather than a set of functions that share the system state. Object-oriented systems are easier to maintain because the objects are independent. They can be understood and modified independent of the rest of the system. An object s interface declares all that the rest of the system knows about an object. One disadvantage of object-oriented design is the overhead incurred to access or modify an object. The members of an object are accessed using get and set functions. This allows the object implementation to change without impacting other objects as long as the interface remains constant. The hardest part of object-oriented design is identification of the objects and their operations. As will be shown, JAUS alleviates some of this problem for autonomous vehicles by proposing common components that are used by many unmanned vehicles. Real-time systems design is used for systems whose correct operation depends on both the results produced and the time at which these results are ready. These systems

4 must handle events that happen at regular intervals as well as interrupt driven events. When an interrupt occurs, control flow must be immediately passed to the appropriate handler to guarantee proper results. Autonomous systems utilize real-time systems for closed-loop controllers and for data acquisition. Because real-time systems must meet timing constraints, it is impractical to use other design strategies such as object-oriented design because the information hiding principle results in inefficient components. JAUS architecture The Joint Architecture for Unmanned Systems (JAUS) is an architecture defined for use in the research, development and acquisition of Unmanned Systems [2]. JAUS is a message-based architecture where only components and their messages are defined. The purpose of JAUS is to support the acquisition of Unmanned Systems by providing a mechanism for reducing system life-cycle costs. JAUS uses the Generic Open Architecture (GOA) classification scheme to identify its interface layers [3]. JAUS specifies only the logical layer, or GOA class 4L, for component communication. The messages that a JAUS component supports constitute its interface, thus the information hiding principle of object-oriented design is supported for all components. The JAUS domain model ensures that the reference architecture will support all unmanned systems by adhering to the following constraints: Platform independence JAUS makes no assumption about the underlying vehicle platform. Mission isolation unmanned vehicles may be built to gather information, perform tasks, or alter the environment. JAUS is designed by support any combination of vehicle mission.

5 Hardware independence unmanned vehicles often require custom hardware that is not applicable to other vehicles. Also, new hardware becomes available daily. JAUS specifications are not tied to hardware because this architecture must be free to add, modify, or remove hardware as appropriate. Technology independence this requirement is similar to hardware independence but focuses more on the technical approach. The assumption is that there exists and will exist multiple solutions to a problem and an architecture built around a certain technology may eliminate a superior alternative. These constraints ensure that the JAUS system architecture is both modular and scalable which makes new technology insertion possible. The JAUS system topology is illustrated in figure 1. A system is made up of a logical grouping of sub-systems. A sub-system is a complete unmanned system (i.e. a vehicle). A node is all the hardware and software needed to support a capability within the subsystem. A node typically resides on a singe processor or set of tightly coupled processors. Components are the tasks running on a node. Instances are references to specific components. SYSTEM Subsystem Subsystem Subsystem Node Node Node Node Comp1, Inst1 Comp2, Inst1 Comp2, Inst2 CompN, Inst1 Figure 1. System topology

6 Since configurations are unlimited, JAUS does not specify node or component interface boundaries. Only when data is sent between JAUS components, must the message be formatted as a JAUS message. This is one reason the JAUS architecture remains flexible enough to be used on vastly different types of vehicles. JAUS allows a system designer to use functional design strategy to implement a component and still maintain the information hiding principle of object-oriented design by adhering to a specified component interface. JAUS defines three element types to classify components. They are functional agents, knowledge stores, and device groups [4]. Functional agents are sets of object classes that have a similar purpose such as the primitive driver, which has the responsibility to drive the vehicle. Knowledge stores are groupings of similar types of information. An example knowledge store is the position knowledge store, which houses the current position and velocity of the vehicle. Device groups are groupings of sensors and/or controllers that are used for similar functions. A common vehicle device group is the set of sensors that monitor the vehicles parameters. An example JAUS implementation ASI has built numerous autonomous vehicles. ASI built more than 10 autonomous vehicle systems (vehicle and related interfaces) before adopting JAUS. The hardware and software of these early systems was tightly coupled and difficult to maintain. Each new application required extensive changes to the system architecture, most requiring ground up versions that only slightly mimicked the predecessors. Each vehicle had different requirements as far as use, communication medium, and features. It became obvious that a common architecture was needed that would support new vehicles,

7 preserve the lessons learned from the previous vehicles, and cut the overall cost of the vehicle systems. Figure 2 illustrates a typical ASI autonomous vehicle system as it relates to the JAUS architecture. This diagram is from the company s PGAP (proving grounds automation package) product [5]. The PGAP product is a software, hardware, and electronics suite that can be integrated on any vehicle to allow 24-hour unmanned repeatable tests of a vehicle and its capabilities. This product has greatly benefited from the JAUS architecture because the vehicle framework was designed independent of a target vehicle. Most components used by ASI are defined in the JAUS reference architecture. However, JAUS does not prohibit new components in the architecture. ASI created the planning elements knowledge store and the path planner components to meet advanced customer needs. Forms of these components have been adopted as part of JAUS version 3.0 because of their potential benefit to many autonomous vehicle systems. Subsystem 1 of Figure 2 is the OCU (operator control unit). This subsystem is responsible for all high-level commands to the vehicle. It is also the tool used to view the vehicles status. The MARS (mission assignment and reconnaissance system) component is a graphical user interface to the autonomous vehicle [6]. This powerful tool is used to construct maps, task the vehicle, and gather data. MARS allows a user to record a vehicles position and actions while being driven manually or remote via tele-operation. This information can be viewed or modified and then sent back to the vehicle to repeat any number of times without further human interaction.

8 Figure 2. Autonomous Solutions PGAP vehicle architecture

9 All of the PGAP components were designed within the JAUS architecture. This has allowed the components to evolve with additional features and safety measures without requiring other components to change. For example, MARS has added a tool called the path builder that allows the user to draw a path for the vehicle composed of lines and arcs. This tool preserves the vehicles kinematic constraints when building a path so that the vehicle can follow the path autonomously. This complicated feature was added to MARS without affecting the other components in the system. It simply utilizes the other components interfaces to accomplish a new task. The path planner is another component of the OCU subsystem that has undergone many changes without imposing side effects and sweeping changes on the rest of the system. One of the earliest path planner tasks was to create an efficient path for the vehicle to transition it from its current position and heading to a desired position and heading without intersecting with any of the obstacles in the map. The path planner has expanded its interface to allow MARS to request a vehicle coverage path over an area for applications such as mowing a lawn or minesweeping. MARS and the path planner communicate to each other through the message routing system. All messages between components are passed to the subsystem message router. The message router determines if the target of the message is on the local subsystem or on a remote subsystem. If the message is intended for a remote subsystem then the message is handed to the communicator and sent to the communicator of the destination subsystem. This message routing scheme removes each component from the details of the communication hierarchy. For example, Figure 2 illustrates two possible communication mediums. In this diagram MARS and the path planner communicate

10 with the message router over a TCP/IP socket. On subsystem 2 the message router and the communicator communicate by function calls. JAUS is not tied to any type of communication method; it merely specifies the messages that should be sent. The PGAP vehicle implementations use serial radios, wireless Ethernet, function calls, CAN, and other communication mediums all within the JAUS architecture. The VCU (vehicle control unit) subsystem in Figure 2 contains many components that are defined in the JAUS domain model. One component that is common to almost all unmanned vehicles is the vehicle position knowledge store. This component maintains the latest position reading for the vehicle. This knowledge store can be queried by any component desiring the vehicles current position. The current position is also sent periodically to registered components using service connections. A service connection is a protocol that JAUS uses to facilitate periodic data transfer. JAUS also uses event notifications to send data to components that have previously registered for the events. This allows components like PEKS to notify another component when it pops an element from its queue. The components in the functional agents box of Figure 2 are those components that are responsible for acting on the vehicles hardware. Having used JAUS on many vehicles, ASI has found it helpful to inherit vehicle specific components from many of the functional agents. For example, all ASI vehicles have a generic wrench generator component that calls overloaded functions based on the vehicle being used. This allows the same code base to be used on all ASI vehicles. This has huge development advantages because the code base is thoroughly tested and bug fixes get propagated to all vehicles. Component implementations continue to change as they are made more

11 efficient and more features are added to the system but the overall structure has remained untouched thanks to the JAUS framework. Conclusion The absence of a common architecture for autonomous vehicles has resulted in many one-off systems that are difficult to maintain and cannot be reused for other platforms. JAUS is a framework for autonomous vehicles that defines components and the message passing protocol. JAUS is independent of platform, mission, or hardware. JAUS overcomes the difficult part of object-oriented design by specifying those components that are common to autonomous vehicles. The interface definitions of JAUS emphasize the information hiding principle that allows component implementations to change without imposing side effects on the rest of the system. System designers are free to use functional and real-time design strategies when implementing components and subsystems as long as the messages sent between components is formatted in a JAUS message. Commercialization of autonomous vehicles is greatly benefited by the JAUS architecture. Companies such as Autonomous Solutions Inc. have benefited from the JAUS architecture by developing reusable components that are being utilized on many different vehicles. References 1. Software Engineering, Ian Sommerville, Addison-Wesley The Joint Architecture For Unmanned Systems (JAUS), Reference Architecture Volume II, version 3.0, September 13, 2002.

12 3. Generic Open Architecture (GOA) Framework, Society of Automotive Engineers (SAE) AS4893, January The Joint Architecture For Unmanned Systems (JAUS), Domain Model Volume I, Version PGAP, 1 June User Interface Considerations For The Control And Tasking Of Multiple Autonomous For Facilities Like The Goodyear Proving Grounds, Paul J. Lewis, Joseph F. Harrison, Sarah A. Gray, Autonomous Solutions, 2003.