ACS software is independent of the hardware, vehicle type, and communication protocol. It emphasizes a modular, configurable, and scalable approach to autonomy implementation.
ACS employs a suite of commonly used tools used for development and integration of unmanned capabilities. The basic components of ACS are:
- Standardized module architecture
- Modules – software is implemented as modules; for example, majority of the software is broken down as either a device module, perception module, behavior module, or a communications module
- Standard interfaces – all modules have well-defined interfaces that enable easy development of new modules and connections to other modules
- Configuration files – used to easily change module parameters without touching module code
- State machine sequencing of behaviors
- Behavior arbitration – state machines provide behavior arbitration among conflicting behavior outputs and user input
- e.g., follow a waypoint, avoid an obstacle, and maintain comms link
- Device coordination – state machines allow control of multiple devices simultaneously
- e.g., follow a waypoint while tracking an object with a PTZ camera
- XML configuration files – defines for the state machine the sequencing of behaviors and connections between modules based on task goal or user input
- Configurable messaging policy
- Expandable data types
- Connections between modules are configurable
- Configuration files define the communications protocol to use
- Support Local Process, Interprocess, and Networked Data Sharing
- Has built in serialization to remove knowledge of data types from networking software
- Scalable build system
- Can load any combination of modules depending on capabilities desired, mission, vehicle type, etc.
- Modules to include are loaded at run-time
The below block diagram illustrates the modular nature of the ACS and an example of how modules can relate to each other. Here, devices are defined as sensors, actuators, or payloads, perceptions are derived data based on device and other perceptive data, behaviors are actuator commands determined by analyzing the perception data, device data, and the goal of the behavior and/or operator input, and tasks are sequences of behaviors.
The desired modularity has been achieved through standard messaging between modules and processes, as well as the use of an XML-defined state machine. The standard messaging makes it easy to integrate new modules, and the state machine makes it easy to create new tasks, or strings of behaviors, as well as influence what data sources provide goals for the behaviors. The result is rapid development of new unmanned systems capabilities.