A reference model architecture is the core of 4D/RCS. The 4D/RCS reference model architecture is characterized by a generic control node that is applied to all the hierarchical control levels. The node features specific functions, interfaces, information structures, and processing paradigms that enable intelligent behavior. The 4D/RCS hierarchical levels are scalable to facilitate systems of any degree of complexity.
Figure 1 shows a high level block diagram of a 4D/RCS reference model architecture for a notional Future Combat System (FCS) battalion. 4D/RCS prescribes a hierarchical control principle that decomposed high level commands into actions that employ physical actuators and sensors. Characteristics such as timing and node functionality may differ in various implementations.
Figure 1: A high level block diagram of a typical 4D/RCS reference model architecture. Commands flow down the hierarchy, and status feedback and sensory information flows up. Large amounts of communication may occur between nodes at the same level, particularly within the same subtree of the command tree. UAV = Unmanned Air Vehicle, UARV = Unmanned Armed Reconnissance Vehicle, UGS = Unattended Ground Sensors
At the Servo level, commands to actuator groups are decomposed into control signals to individual actuators. In the example shown in Figure 1, outputs to actuators are generated every 5 milliseconds (ms). Plans that look ahead 50 ms are regenerated for each actuator every 5 ms. Plans of individual actuators are synchronized so that coordinated motion can be achieved for multiple actuators within an actuator group.
At the Primitive level, multiple actuator groups are coordinated and dynamical interactions between actuator groups are taken into account. Plans look ahead 500 ms and are recomputed every 50 ms.
At the Subsystem level, all the components within an entire subsystem are coordinated, and planning takes into consideration issues such as obstacle avoidance and gaze control. Plans look ahead 5 seconds (s) and replanning occurs every 500 ms.
At the Vehicle level, all the subsystems within an entire vehicle are coordinated to generate tactical behaviors. Plans look ahead 1 min and replanning occurs every 5 s.
At the Section level, multiple vehicles are coordinated to generate joint tactical behaviors. Plans look ahead about 10 minutes (min) and replanning occurs about every minute.
At the Platoon level, multiple sections containing a total of 10 or more vehicles of different types are coordinated to generate platoon tactics. Plans look ahead about an hour (hr) and replanning occurs about every 5 min.
At the Company level, multiple platoons containing a total of 40 or more vehicles of different types are coordinated to generate company tactics. Plans look ahead about 5 hr and replanning occurs about every 25 min.
At the Battalion level, multiple companies containing a total of 160 or more vehicles of different types are coordinated to generate battalion tactics. Plans look ahead about 24 hr and replanning occurs at least every 2 hours.
At all levels, task commands are decomposed into jobs for lower level units and coordinated schedules for subordinates are generated. At all levels, communication between peers enables coordinated actions. At all levels, feedback from lower levels is used to cycle subtasks and to compensate for deviations from the planned situations.
Df. A task command is a command to a BG process to do a task, or to modify an ongoing task.
Each node within the hierarchy shown in Figure 1 functions as a goal-driven, model-based, closed-loop controller. Each node is capable of accepting and decomposing task commands with goals into actions that accomplish task goals despite unexpected conditions and dynamic perturbations in the world. At the heart of the control loop through each node is a rich, dynamic world model that provides the node with an internal model of the external world. This is illustrated in Figure 2. In each node, the world model provides a site for data fusion, acts as a buffer between perception and behavior, and supports both sensory processing and behavior generation.
Figure 2. The fundamental structure of a 4D/RCS control loop. An internal world model of the external world provides support to both perception and behavior. Sensors measure properties of the external world. Perception extracts the information necessary to keep the world model current and accurate from the sensory data stream. Behavior uses the world model to decompose goals into appropriate action.
In support of behavior generation, the world model provides knowledge of the environment with range and resolution in space and time that is appropriate to task decomposition and control decisions that are the responsibility of that node. The world model also provides simulation and modeling for planning and reasoning about the future. For example, the world model can simulate results of hypothesized actions that can be evaluated and compared with the current state of the world. This enables behavior generation to plan and control actions that are most likely to achieve the given goal at minimum cost and maximum benefit.
Df. Task decomposition is a process by which a task given to a BG process at one level is decomposed into a set of sequences of subtasks to be given to a set of subordinate BG processes at the next lower level.
Df. Planning is a process of generating and/or selecting a plan to accomplish a task or job.
Df. A state is the dynamic condition of an entity or a process at a point in time.
In support of sensory processing, the world model provides predictions that can be matched with observations for recursive estimation and Kalman filtering [Kalman 02]. The world model also provides hypotheses for gestalt grouping and segmentation. Thus, each node in the 4D/RCS hierarchy is an intelligent system that accepts goals from above and generates commands for subordinates so as to achieve those goals.
The centrality of the world model to each control loop is a principal distinguishing feature between 4D/RCS and behaviorist (i.e., purely reactive) architectures [Brooks 91, 86]. Behaviorist architectures rely solely on sensory feedback from the world. They do not fuse information from multiple sensors over time, nor do they integrate sensory feedback with a priori knowledge. All behavior is a reaction to immediate sensory feedback. In contrast, the 4D/RCS world model integrates all available knowledge into an internal representation that is far richer and more complete than is available from immediate sensory feedback alone. This enables more sophisticated behavior than can be achieved from purely reactive systems.
The character and structure of the world model also distinguishes 4D/RCS from conventional artificial intelligence (AI) architectures. Most AI world models are purely symbolic. In 4D/RCS, the world model is much more than a symbolic abstraction of the world. It is, rather, a combination of instantaneous signal values from sensors, state variables, images, and maps that are linked to symbolic representations of entities, events, objects, classes, situations, and relationships in a composite of immediate experience, short-term memory, and long-term memory.
Df. A map is a two-dimensional array of attributes and entities that are scaled to, and registered with, known locations in the world.
A high level diagram of the internal structure of the world model and value judgment system is illustrated in Figure 3. Within the knowledge database2, iconic information in the form of images and maps are linked to each other and to symbolic information in the form of entities and events. Situations and relationships between and entities, events, images, and maps are represented by pointers. Pointers that link symbolic data structures to each other form syntactic, semantic, causal, and situational networks. Pointers that link symbolic data structures to regions in images and maps provide symbol grounding and enable the world model to project its understanding of reality onto the physical world. A world modeling process maintains the knowledge database and uses information stored in the knowledge database to generate predictions for sensory processing and simulations for behavior generation. Predictions are compared with observations and errors are used to generate updates for the knowledge database. Simulations of tentative plans are evaluated by value judgment to select the "best" plan for execution.
Df. A plan is a set of subtasks and subgoals that form a path from the starting state to the goal state.
As suggested in Figure 3, the 4D/RCS control loop contains four functional elements: sensory processing, world modeling, value judgment, and behavior generation.
Df. Functional elements are the fundamental computational processes from which the system is composed.
Figure 3. The basic internal structure of a 4D/RCS control loop. Sensory processing performs the functions of windowing, grouping, computation, estimation, and classification on input from sensors. World modeling maintains knowledge in the form of images, maps, entities, and events with states, attributes, and values. Relationships between images, maps, entities, and events are defined by pointers. These relationships include class membership, ontologies, situations, and inheritance. Value judgment provides criteria for decision making. Behavior generation is responsible for planning and execution of behaviors.
Df. Sensory Processing is a set of processes that operate on sensor signals to detect, measure, and classify entities and events and derive useful information about the world.
Sensory processing performs the operations of windowing, grouping, computation, filtering, and classification, or recognition at many different levels. Sensory processing computes observed features and attributes, and compares them with predictions from internal models. Correlation between sensed observations and internally generated expectations are used to detect events and recognize entities and situations. Differences between sensed observations and internally generated predictions are used to update internal models. Perception results when the internal world model matches the external world.
Sensory processing accepts signals from sensors that measure properties of the external world or conditions internal to the system itself. In general, sensors do not directly measure the state of the world. Sensors only measure phenomena that result from the state of the world. Signals generated by sensors may be affected by control actions that cause the sensors to move through the world. Sensor signals are also corrupted by noise. The set of equations that describe how sensor signals depend on the state of the world, the control action, and sensor noise is called a measurement model.
A measurement model is typically of the form
where:y = signals from sensors
x = state of the world
u = control action
h = sensor noise
H = a function that relates sensor signals to world state, control action, and noiseA linearized form of the measurement model is typically of the form:
y = Cx + Du + h
C is a matrix that defines how sensor signals depend on the world state
D is a matrix that defines how sensor signals depend on the control action
Df. World modeling is a set of processes that construct and maintain a world model
Df. A world model is an internal representation of the world.
World modeling is a process that performs four principal functions:
1. It maintains a knowledge database of images, maps, objects, agents, situations, relationships, and knowledge of task skills and laws of nature and relationships among them.
2. It maintains a best estimate of the state of the world to be used as the basis for predicting sensory feedback and planning future actions.
3. It predicts (possibly with several hypotheses) sensory observations based on the estimated state of the world. Predicted signals can be used by sensory processing to configure filters, masks, windows, and templates for correlation, model matching, and recursive estimation.
4. It simulates results of possible future plans based on the estimated state of the world and planned actions. Simulated results are evaluated by the value judgment system in order to select the best plan for execution.
The world model includes a knowledge database and set of world modeling processes. The world model includes models of portions of the environment, images, maps, models of entities, events, and agents, rules, task knowledge, abstract data structures, and pointers that represent relationships, and a system model that includes the intelligent system itself. The world model knowledge database is dynamic, multiresolutional, and distributed over the 4D/RCS nodes. It is maintained in each node by a local world modeling process.
Df. A system model is a set of differential equations (for a continuous system) or difference equations (for a discrete system) that predict how a system will respond to a given input.
A system model is typically of the form
where:x' = the state of the system
x= the rate of change in the system state
u = the control action
g = system noise
f = a function that defines how the system state changes over time in response to control actionsA linearized form of the above system model is of the form
x' = Ax + Bu + g
A is a matrix that defines how the system state evolves over time without control action.
B is a matrix that defines how the control action affects the system state.Df. A knowledge database contains the data structures and the static and dynamic information that together with world modeling processes form the intelligent system's world model.
The knowledge database has three parts:
(1) immediate experience consisting of iconic representations in the form of current values of sensor signals, camera images, maps, etc. Immediate experience also consists of entities, events, pointers, and observed, estimated, and predicted attributes and state variables.
Df. Iconic knowledge is 2D array data in which the dimensions of the array correspond to dimensions in an image. The value of each element of the array may be boolean data or real number data representing a physical attribute such as light intensity, color, or terrain elevation.(2) short-term memory consisting of symbolic representations in the form of a list of entities that are the subject of current attention, pointers that define relationships and class membership, and queues of recent events at various levels of temporal resolution.
(3) long-term memory consisting of symbolic representations of all the objects, events, classes, relationships, and rules that are known to the intelligent system.
Df. Value judgment is a process that computes value, determines importance, assesses reliability, and generates reward and punishment.
Value judgment evaluates perceived and planned situations, thereby enabling behavior generation to select goals and set priorities. It computes what is important (for attention), and what is rewarding or punishing (for learning). Value judgment assigns priorities and computes the level of resources to be allocated to tasks. It assigns values to recognized objects and events, and computes confidence factors for observed, estimated, and predicted attributes and states.
Df. Behavior generation is planning and control of actions designed to achieve behavioral goals.
Df. A behavioral goal is a desired state that a behavior is designed to achieve or maintain
Behavior generation plans and executes tasks in order to successfully accomplish mission goals. Behavior generation uses task knowledge, skills, and abilities along with knowledge in the world model to plan and control appropriate behavior in the pursuit of goals. Behavior generation accepts task commands with goals and priorities, formulates and/or selects plans, and controls action. Behavior generation develops or selects plans by using a priori task knowledge and value judgment functions combined with real-time information provided by world modeling to find the best assignment of tools and resources to agents, and to find the best schedule of actions (i.e., the most efficient plan to get from an anticipated starting state to a goal state). Behavior generation controls action by both feed forward actions and by feedback error compensation. Goals, feedback, and feed forward signals are combined in a control law.
Df. A control law is a set of equations that computes control action given predicted state, desired state, and feed forward action.
A control law is typically of the form
u = control action
uff = feed forward control action (from a plan or inverse model)
xd = desired world state (from a command)
x* = predicted world state (from the world model)A linearized form of a control law is
u = uff + G(x* - xd)
where:
G = a matrix that defines the feedback compensation applied to the difference
between the desired and predicted state of the world
In simple cases, feed forward actions can be computed by applying a desired
goal to an inverse model of the system. However, for complex systems, the world
model typically has no inverse, and feed forward actions can only be discovered
through planning. Planning typically involves a heuristic search through the
space of possible actions using a world model to predict the results of those
actions. A value judgment process is then invoked to evaluate potential plans
and choose the best plan for execution.
In the 4D/RCS reference architecture, behavior generation, world modeling, sensory processing, value judgment, and the knowledge database are organized into RCS_NODEs.
Df. A RCS_NODE is an organizational unit of a 4D/RCS system that processes sensory information, computes values, maintains a world model, generates predictions, formulates plans, and executes tasks.
Figure 4 illustrates the relationships within a single RCS_NODE of the 4D/RCS architecture. The interconnections between sensory processing, world modeling, and behavior generation close a reactive feedback control loop between sensory measurements and commanded action. The interconnections between behavior generation, world modeling, and value judgment enable deliberative planning and reasoning about future actions. The interconnections between sensory processing, world modeling, and value judgment enable knowledge acquisition, situation evaluation, and learning. Within sensory processing, observed input from sensors and lower level nodes is compared with predictions generated by world modeling. Differences between observations and predictions is used by world modeling to update the knowledge database. This can implement recursive estimation processes such as Kalman filtering. Within behavior generation, goals from higher levels are compared with the state of the world as estimated in the knowledge database. Behavior generation typically involve planning and execution functions. Differences between goals and estimated states are used to generate action. Information in the knowledge database of each node can be exchanged with peer nodes for purposes of synchronization and information sharing. Any or all of the processes within a node may communicate with an Operator Interface.
A RCS_NODE is analogous to Koestler's concept of a "holon" [Koestler 67]. Each RCS_NODE looks upward to a higher level node from which it takes commands, for which it provides sensory information, and to which it reports status. Each RCS_NODE also looks downward to one or more lower level nodes to which it issues commands, and from which it accepts sensory information and status. Each RCS_NODE may also communicate with peer nodes with which it exchanges information. A RCS_NODE is often abbreviated as a node in this document.
3.7 An Organization of RCS_NODEs
A collection of RCS_NODES can be used to construct a distributed hierarchical reference model architecture such as shown in Figure 5. Each node in the 4D/RCS architecture corresponds to a functional unit in a military command and control hierarchy. Depending on where the generic node resides in the hierarchy, it might serve as an intelligent controller for an actuator, a subsystem, a vehicle, a section, a platoon, a company, battalion, or higher level organizational unit. Each generic node (or a set of processes within a node) might either be implemented as an intelligent supervised-autonomy controller or be performed by a human or management unit at any level in the military command and control structure.
Df. Intelligent supervised-autonomy controllers are controllers capable of accepting commands from human supervisors and executing those commands with little or no further input from humans in unstructured and often hostile environments.
An intelligent, supervised-autonomy controller is intelligent in that it is capable of executing its assigned mission with or without direct communication from a human supervisor. It is supervised in that it responds to commands from superiors with discipline in response to established rules of engagement as would any well disciplined human soldier. It is autonomous in that it is capable of formulating plans and coordinating with other intelligent agents in the execution of mission assignments. Environments in which UGVs with supervised-autonomy controllers are required to operate include urban warfare zones, rural battlefields, mountains, woods, farmlands, or desert terrain, as well as all kinds of weather during day or night.
Figure 5. A 4D/RCS reference model architecture for an individual vehicle. Processing nodes, RCS_NODES, are organized such that the behavior generation (BG) processes form a command tree. Information in the knowledge database (KD) is shared between world modeling (WM) processes in nodes above, below, and at the same level within the same subtree. KD structures are not shown in this figure. On the right, are examples of the functional characteristics of the behavior generation (BG) processes at each level. On the left, are examples of the scale of maps generated by the sensory processing (SP) processes and populated by the WM in the KD knowledge database at each level. Sensory data paths flowing up the hierarchy typically form a graph, not a tree. Value judgment (VJ) processes are hidden behind WM processes. A control loop may be closed at every node. An operator interface may provide input to, and obtain output from, processes in every node.
In Figure 5, each node consists of a behavior generation (BG), world modeling (WM), and sensory processing (SP), and knowledge database (KD) (not shown in Figure 5). Most nodes also contain a value judgment (VJ) process (hidden behind the WM process in Figure 5). Each of the nodes can therefore function as an intelligent controller. An operator interface may access processes in all nodes at all levels.
Figure 5 illustrates a vehicle system with four subsystems: mobility, communication, and two mission packages. Each of the four subsystems has one or more mechanisms. Each of the mechanisms have one or more actuators and sensors. For example, the mobility subsystem may consist of a navigation and driving controller with several subordinate controllers for steering, braking, throttle, and gear shift, plus ignition, lights, horn, and turn signals, each of which has one or more actuators and sensors. The communication subsystem might consist of a message encoding subsystem, a protocol syntax generator, and communications bus interface, plus antenna pointing and band selection actuators. The vehicle control system should be able to incorporate a variety of modular mission packages, each of which may contain a number of sensors and actuators. For example, a weapons mission package might have loading, aiming, and firing subsystems each with a number of sensors and actuators. A reconnaissance, surveillance, and target acquisition (RSTA) mission package might consist of mechanisms that use cameras, LADARs, FLIRs, radar, and acoustic sensors to detect and track objects, surfaces, edges and points, and compute trajectories for laser range finders, or pan, tilt, and focus actuators.
The operator interface (OI) provides the capability for the operator to interact with the system at any time at a number of different levels - to adjust parameters, to change speed, to select or verify targets, or to authorize the use of weapons. The OI provides a means to insert commands, change missions, halt the system, alter priorities, perform identification friend-or-foe (IFF), or monitor any of the system functions. The OI can send commands or requests to any BG process, or display information from any SP, WM, or VJ process. It can display any of the state variables in the KD at a rate and latency dictated by the communications bandwidth. Using the OI, a human operator can view situational maps with topographic features and both friendly and enemy forces indicated with overlays. The operator may use the OI to generate graphics images of motion paths, or display control programs (plans) in advance, or while they are being executed. The OI may also provide a mechanism to run diagnostic programs in the case of system malfunctions.
In Figure 5, three levels of control are shown above the node representing the individual vehicle. These three additional levels represent a surrogate chain of commands that, in principle, exists above the individual vehicle. Because each vehicle is semi-autonomous, it carries a copy of the control nodes that otherwise would exist in its superiors if those superiors were tightly coupled in an integrated control structure. Individual vehicles are physically separated, and may only occasionally be in contact with each other or with their superiors through a low bandwidth and often unreliable communication channel. It is necessary for each vehicle to carry a surrogate chain of commands that performs the functions of its superiors in the command chain.
The surrogate chain of commands serves four functions. First, it provides each vehicle with an estimate of what its superiors would command it to do if they were in direct communication. Second, it enables any vehicle to assume the duties of any of its superiors in the event this should become necessary. Third, it provides a natural interface for human commanders at the section, platoon, or company level to interface with the vehicle at a level relevant to the task being addressed. Fourth, it enables each vehicle to dedicate a separate node to handle each of the higher level tasks. In this example, the surrogate chain of commands consists of three levels with three different planning horizons (ten minutes, one hour, and five hours). These three levels deal with external objects and maps at three different scales and ranges. There, of course, may be more than three levels above the vehicle.
In Figure 5, the horizontal curved lines between WM processes represent the sharing of state information in the knowledge database between nodes within subtrees in order to synchronize related tasks. The vertical lines between WM processes represent the sharing of knowledge required to populate maps and abstract data structures, and to perform recursive estimation of state variables at various levels in the world model.
The functionality of each level in the 4D/RCS reference model hierarchy is defined by the functionality, characteristic timing, bandwidth, and algorithms chosen by BG processes for decomposing tasks and goals at each level. Typically these are design choices that depend on the dynamics of the processes being controlled. The numbers shown on the right in Figure 5 represent planning horizons appropriate for a vehicle. For other types of systems, different numerical values would be derived from design parameters. The scale of the maps on the left in Figure 5 indicates the range of the maps at that level in the world model. The number of pixels in the maps is typically constant; thus the resolution of the maps decreases at each higher level.
The complexity inherent in intelligent systems can be managed through partition into hierarchical levels. Intelligent systems are inherently complex. Hierarchical leveling is a common method for organizing complex systems that has been used in many different types of organizations throughout history for effectiveness and efficiency of command and control. In a hierarchical control system, higher level nodes have broader scope and longer time horizons with less concern for detail. Lower level nodes have narrower scope and shorter time horizons with more focus on detail. At no level does a node have to cope with both broad scope and high level of detail. This limits the responsibility and load for all the nodes at all levels and enables the design of systems of arbitrary complexity, without computational overload in any node and any level.
4D/RCS uses the principle of hierarchical leveling to facilitate software reuse. All the nodes in the 4D/RCS architecture have many features in common. These include basic read, write, decision-making, communications, timing, record keeping, and debugging features. Generic nodes that provide these common features can be used to define organizational units at all levels. Each specific node can then be customized for its specific functional responsibilities by embedding level- and node-specific algorithms and knowledge. In the 4D/RCS reference architecture, behavior generation processes at the upper levels in the hierarchy are customized to generate long-range strategic plans consisting of major milestones, while lower level behavior generation processes successively decompose the long-range plans into short-range tactical plans with detailed activity goals. Sensory processing functions are customized at lower levels to operate on data over local neighborhoods and short time intervals, while at higher levels they integrate data over long time intervals and large spatial regions. At low levels, the knowledge database is filled with short-term, short-range, fine-grained information, while at higher levels it is filled with knowledge that is broad in scope and generalized over large regions of space and time. At every level, feedback loops are closed to provide reactive behavior, with high-bandwidth fast-response loops at lower levels, and slower more deliberative behavior at higher levels.
Hierarchical leveling enables optimal use of iconic memory in the representation of time and space. At each level, state variables, images, and maps are maintained to the resolution in space and time that is appropriate to that level. At each successively lower level in the hierarchy, as detail is geometrically increased, the range of computation is geometrically decreased. Also, as temporal resolution is increased, the span of interest decreases. This produces a ratio that remains relatively constant throughout the hierarchy. As a result, at each level, behavior generation functions make plans of roughly the same number of steps. At higher levels, the space of planning options is larger and world modeling simulations are more complex, but there is more time available between replanning intervals for planning processes to search for an acceptable or optimal plan. Thus, hierarchical leveling keeps the amount of computing resources needed for behavior generation in each node within manageable limits.
Also at each level, entities with a lower level of abstraction are grouped to form entities with a higher level of abstraction. The effect is to geometrically increase the scope and encapsulate the detail of entities and events observed in the world. Thus, at each level, sensory processing functions are responsible for entities that contain roughly the same number of sub-entities.
At each level, events with a lower level of abstraction are grouped to form
events with a higher level of abstraction along the time line. Thus, short term
memory events at lower levels are much more detailed than short-term memory
events at higher levels, but the historical record in short-term memory at lower
levels covers a shorter time frame than short-term memory at higher levels.
Correspondingly, plans at higher levels are longer term and less detailed than
plans at lower levels.
This kind of leveling is typical of the military command and control hierarchy.
At the top, strategic objectives are chosen and priorities defined that influence
the selection of goals and the prioritization of tasks throughout the entire
hierarchy. The details of execution are left to subordinates.
At intermediate levels, tasks with goals and priorities are received from the
level above, and sub tasks with sub goals and attention priorities are output
to the level below. In the intelligent vehicle environment, intermediate level
tasks might be of the form: <go to position at map coordinates x,y>, <advance
in formation along line z>, <engage enemy units at time t>, etc. The
details of execution are left to subordinates.
At each level in the 4D/RCS hierarchy, higher-level, more global tasks are decomposed and focused into concurrent strings of more narrow and finer resolution tasks. The effect of each hierarchical level is thus to geometrically refine the detail of the task and limit the view of the world, so as to keep computational loads within limits that can be handled by individual intelligent agents, such as 4D/RCS nodes or ordinary human beings.
In 4D/RCS systems, complexity of the real world environment can also be managed through focusing attention. Intelligent systems must operate in a real world environment that is rich with detail. The real world environment contains an infinite variety of real objects, such as the ground, rocks, grass, sand, mud, trees, bushes, buildings, posts, ravines, rivers, roads, enemy and friendly positions, vehicles, weapons, and people. The background may contain millions of leaves, twigs, and grains of sand. The environment also contains elements of nature, such as wind, rain, snow, sunlight, and darkness. All of these objects and elements have states and may cause, or be part of, events and situations. The environment also contains a practically infinite regression of detail, and the world itself extends indefinitely far in every direction.
Yet, the computational resources available to any intelligent system are finite.
No matter how fast and powerful computers become, the amount of computational
resources that can be embedded in any practical system will be limited. Therefore,
it is imperative that the intelligent system focus the available computing resources
on what is important, and ignore what is irrelevant. In each situation, the
intelligent system should know what it does not know, and know whether is it
important to find out. Of what it does know, it must distinguish the relevant
from the irrelevant. And what is relevant, it must prioritize in order of importance
Fortunately, at any point in time and space, most of the detail in the environment
is irrelevant to the immediate task of the intelligent system. Therefore, the
key to building practical intelligent systems lies in understanding how to focus
the available computing resources on what is important and ignore what is irrelevant.
3.9.1 Knowing What is Important
The problem of distinguishing what is important from what is irrelevant must be addressed from two perspectives: top down and bottom up.
Top down: what is important is defined by behavioral goals. The intelligent system is driven by high-level goals and priorities to focus attention on objects specified by the task, using resources identified by task knowledge as necessary for successfully accomplishing given goals. Top down goals and high-level perceptions generate expectations of what objects and events might be encountered during the evolution of the task and which are important to achieving the goal.
Bottom up: what is important is the unexpected, unexplained, unusual,
or out-of-limits. At each level, sensory processing functions detect errors
between what is expected and what is observed. Error signals are processed at
lower levels first. Control laws in lower level behavior generation processes
generate corrective actions designed to correct the errors and bring the process
back to the plan. However, if low level reactive control laws are incapable
of correcting the differences between expectations and observations, errors
filter up to higher levels where plans may be revised and goals restructured.
The lower levels are thus the first to compute attributes of signals or images
that indicate problems or emergency conditions, such as limits being exceeded
on position, velocity, acceleration, vibration, pressure, force, current, voltage,
or temperature. The lower levels of control are also the first to act to correct,
or compensate for errors.
In either top down or bottom up, hierarchical leveling provides a mechanism
for focusing the computational resources of the lower levels on particular regions
of time and space. Higher level nodes with broad perspective and long planning
horizon determine what is important, while the lower levels detect anomalies
and attend to details of correcting errors and following plans. In each node
at each level, computing resources are focused on issues relevant to the decisions
that must be made within the scope of control and time horizon of that node.
The region in space and time that is most relevant to the behavioral choices of an intelligent system is the region around the "here and now." An intelligent system exists at the center of its own egosphere. The relevance of entities and events in the world are usually inversely proportional to their distance from the origin of this egosphere (i.e., here). The intelligent system also exists at the point in time labeled "now" (i.e., t = 0). The relevance of events is usually inversely proportional to their time from "now."
3.9.2 Focusing on What is Important
Focusing of attention can be accomplished through masking, windowing, and filtering based on object and feature hypotheses and task goals. It can also be accomplished by pointing high resolution regions of sensors at objects-of-attention. For example in the human eye, the visual field is sampled at high resolution in the foveal region, and lower resolution in the periphery. Similarly, tactile sensors are closely spaced to produce high resolution in the fingertips, lips, and tongue with much lower resolution in other regions of the skin. The foveal area of the eyes and the high resolution tactile sensory regions of the fingers and lips are behaviorally positioned so as to apply the maximum number of sensors to objects of attention. High resolution sensors are scanned over the world to explore the regions of highest interest to the goals of the task. The result is to make the largest possible number of high resolution measurements of the most important entities and events in the environment and to ignore or sample at lower resolution those entities and events that are considered unimportant.
Thus, at each level in the 4D/RCS sensory processing hierarchy, attention is used to mask, filter, and window sensory data and to focus computational resources on objects and events that are important to the mission goal. This keeps the computational load of processing sensory data within manageable limits at all levels of the hierarchy.
3.10 A Notional 4D/RCS Concept for FCS
To illustrate the types of issues that can be addressed using the 4D/RCS architecture, an example is given below of an eight-level hierarchy for a FCS battalion based on a merger of two notional concepts. One is the notional FCS Organization Concept developed by the FY2000 Summer Study for the Army Science Board based on a Ft. Knox Mounted Maneuver Battle Lab experimental force design. [Army 00] The second notional concept is the Lead Systems Integrator concept expressed in the Boeing Broad Industry Announcement. [Boeing 02] The specific numbers and functions described in this example are illustrative only. Exact numbers will be determined by future FCS design studies.
Level 8 - Battalion
A notional FCS battalion might be an organization consisting of a headquarters unit, two fighting vehicle companies, two infantry vehicle companies, a reconnaissance platoon, a net fires platoon, and a support company. A computational node at level 8 of the 4D/RCS architecture corresponds to a battalion headquarters unit housed within two 16 ton (142.3 kN) command, control, and communications (C3) vehicles that enable C3 on the move for the battalion. The battalion C3 vehicles each include a driver, a commander, and a 4-soldier workstation.
Incoming orders to the battalion headquarters are decomposed, by staff or on-board computers according to the FCS configuration at the time, into assignments for each of the subordinate units within the battalion. Resources and assets are allocated to each subordinate unit, and a schedule is generated for each unit to maneuver and carry out assigned operations. Together, these assignments, allocations, and schedules comprise a battalion level plan. The plan may be devised by the battalion commander alone, or in consultation with his company commanders. The battalion level planning process may consider the objectives and constraints of the incoming orders, the best time and place to engage the enemy, the exposure of each unit's movements to enemy observation, and the traversability of roads and cross-country routes. The battalion commander typically defines the rules of engagement for the units under his command and works with his company commanders to develop a schedule that meets the objectives of the mission orders given to the battalion. In the 4D/RCS battalion node, plans are computed for a period of about 24 hours (h) and recomputed at least once every 2 h (or more frequently if necessary).
In the battalion node, the 4D/RCS world modeling process maintains a knowledge database that contains maps that describe the terrain and location of friendly and enemy forces (to the extent that they are known), and roads, bridges, towns, and obstacles such as mountains, rivers, and woods. Overlaid on the maps are icons that represent objects and organizational units in the environment. These icons have links to symbolic data structures that describe attributes of objects such as class, size, composition, strength, state of readiness, movement, and estimated intent. The battalion level knowledge database may be updated from intelligence reports as well as from sensors on organic ground and air platforms. Maps used for planning typically have a range of at least 100 km x 100 km (i.e. larger than the typical area of concern to the battalion) with a resolution of about 30 m, which corresponds to digital terrain elevation data (DTED) level 2.
Sensory processing in the battalion HQ node integrates information about the movement of forces, the level of supplies, and the operational status of all the units in the battalion, plus intelligence about enemy units in the area of concern to the battalion. This information is used to update maps and data in the knowledge database so as to keep it accurate and current. The battalion node also contains value judgment functions that enable the battalion commander to evaluate the cost, risk, and benefit of various tactical options.
Operator interfaces allow human operators and commanders to visualize information such as the deployment and movement of forces, the availability of ammunition, and the overall situation within the scope of attention of the battalion commander. The commander can intervene at any time to change priorities, alter tactics, or redirect the allocation of resources.
Output from the battalion level consists of commands to the company level. New commands typically consist of tasks expected to require about 5 h to complete. These may be issued at any time. Company commanders attached to the battalion are expected to convey commands to their respective units, monitor how well their company is following the battalion plan, and make adjustments as necessary to keep on plan.
Level 7 - Company
A FCS company is a unit typically consisting of three platoons that may include fighting vehicles, armored personnel carriers, artillery, and logistics. For example, a fighting vehicle company may consist of two fighter platoons, one infantry platoon, and two mortar vehicles. Each infantry company consists of two infantry platoons, and one fighter platoon, and two mortar vehicles. Each support company consists of several resupply vehicles, one or more recovery vehicles to provide towing and recovery assistance, one or more medical vehicles, and one or more mobility/counter-mobility vehicles to breach or lay mine fields.
A computational node at level 7 of the 4D/RCS architecture corresponds to a company headquarters unit housed in two 16 ton C3 vehicles. The company C3 vehicles each consist of a driver, a commander, and a 4-soldier operator interface workstation. Each company headquarters unit plans activities and allocates resources for the units attached to the company. Incoming orders to the company are decomposed by the company headquarters into assignments for the subordinate units that belong to the company. Resources and assets are allocated to each unit, and a schedule is generated for each unit to maneuver and carry out assigned operations. Together, these assignments, allocations, and schedules comprise a company-level plan. The plan may be devised by the company commander alone, or in consultation with his platoon leaders. The company level planning process may consider the objectives of the incoming orders, the best time and place to engage the enemy, the exposure of each unit's movements to enemy observation, and the traversability of roads and cross-country routes. The company commander typically defines the rules of engagement for the units under his command and works with his unit leaders to develop a schedule that meets the objectives of the orders given to the company. In the 4D/RCS company node, plans are computed for a period of about 5 h and recomputed at least once every 30 min (or more frequently if necessary).
In the company node, the 4D/RCS world modeling process maintains a knowledge database that contains maps that describe the terrain and location of friendly and enemy forces (to the extent that they are known), and roads, bridges, towns, and obstacles such as mountains, rivers, and woods. Overlaid on the maps are icons that point to symbolic data structures that describe attributes such as strength, state of readiness, movement, and estimated intent. The level knowledge database may be updated from intelligence reports as well as from sensors on organic ground and air platforms. Maps used for planning typically have a range of 30 km x 30 km (i.e. larger than the typical area of concern to the company) with a resolution of about 30 m.
Sensory processing in the company node integrates information about the movement of forces, the level of supplies, and the operational status of all the units in the company, plus intelligence about enemy units in the area of concern to the company. This information is used to update maps and symbolic data structures in the knowledge database so as to keep it accurate and current. The company node also contains value judgment functions that enable the company commander to evaluate the cost, risk, and benefit of various tactical options.
An operator interface allows human operators (either on-site or remotely) to visualize information such as the deployment and movement of forces, the availability of ammunition, and the overall situation within the scope of attention of the company commander. The operator can intervene to change priorities, alter tactics, or redirect the allocation of resources.
Output from the company level consists of input commands to the platoon level. New commands typically consist of tasks expected to require about 1 h to complete. These may be issued at any time. Platoon leaders are expected to convey commands to their respective units, monitor how well their platoon is following the company plan, and make adjustments as necessary to keep on plan.
Level 6 - Platoon
A FCS platoon attached to a fighting company or infantry company may consist of a headquarters unit housed in a 16 ton C3 vehicle with a human driver, commander, and a 4 soldier workstation. The remainder of the platoon consists of six or more vehicles of the following type in some combination:
A RSTA platoon attached to FCS battalion may consist of a headquarters unit
housed in a 16 ton C3 vehicle with a driver and a commander. Also in the command
vehicle would be a RSTA suite with a 2 soldier workstation, a 5 meter mast,
FLIRs, day/night TV, 10 km laser range finder, Ka band radar, and 360 degree
all elevation pan/tilt. The remainder of the RSTA platoon would consist of:
A Net Fires platoon attached to a FCS battalion may consist of a headquarters
unit housed in a 16 ton C3 vehicle with a driver and commander. Also in the
C3 vehicle would be a 4 soldier workstation. The remainder of the Net Fires
platoon would consist of four 6 or 16 ton missile launchers with BLOS precision
guided missiles and loitering munitions with 40 km to 150 km range.
A Support platoon attached to a FCS support division may consist of a headquarters
unit housed in a 16 ton C3 vehicle with a human driver, a commander, and a 4
soldier workstation. The remainder of the platoon consists of:
A 4D/RCS node at the Platoon level corresponds to a platoon headquarters unit. The platoon commander and section leaders plan activities and allocate resources for the sections in the platoon. Platoon orders are decomposed into job assignments for each section. Resources are allocated, and a schedule of activities is generated for each section. Tactical maneuvers are planned relative to major terrain features and other sections within the platoon. Inter-section formations are selected on the basis of tactical goals, stealth requirements, and other priorities. At the platoon level, plans are computed for a period of about 1 h into the future, and replanning is done about every 5 min, or more often if necessary. Section waypoints about 10 min apart are computed.
The surrogate platoon node in each vehicle performs the functions of the platoon headquarters unit when the vehicle is not in direct communication with the chain of commands. It plans activities for the vehicle on a platoon level time scale and estimates what vehicle level maneuvers should be executed in order to follow that plan. Movements are planned relative to major terrain features and other vehicles within the platoon.
At the platoon level, the 4D/RCS world model contains maps with a range of about 10 km and resolution of about 30 m that describe the location of objectives and the routing between them. These maps are overlaid with icons with pointers to a symbolic database that contains names and attributes of targets, and the weapons and ammunition necessary to attack them.
Sensory processing integrates intelligence about the location and status of friendly and enemy forces. Value judgment evaluates tactical options for achieving section objectives. An operator interface allows human operators to visualize the status of operations and the movement of vehicles within the section formation. Operators can intervene to change priorities and reorder the plan of operations.
Output from the platoon level consists of input commands to the section level. New commands typically consist of tasks expected to require about 10 min to complete. These may be issued at any time. Section commanders (i.e., platoon level executors) are expected to convey commands to their respective units, monitor how well their section is following the platoon plan, and make adjustments as necessary to keep on plan.
Level 5 - Section
A section is a unit that consists of a group of individual scout vehicles such as HMMWVs and UGVs. A 4D/RCS node at the section level corresponds to a section leader and vehicle commanders within the section. The section leader assigns duties to the vehicles in his section and coordinates the scheduling of cooperative activities between vehicles within a section. Orders are decomposed into assignments for each vehicle, and a schedule is developed for each vehicle to maneuver within assigned corridors taking advantage of local terrain features and avoiding obstacles. Plans are developed to conduct coordinated maneuvers and to perform reconnaissance, surveillance, or target acquisition functions. At the section level, plans are computed for about 10 min into the future, and replanning is done about every 1 min, or more often if necessary. Vehicle waypoints about 1 min apart are computed.
At the section level, the 4D/RCS world model symbolic database contains names, coordinates, and other attributes of other vehicles within the section, other sections, and potential enemy targets. Maps with a range of about 2 km and a resolution of about 30 m are typical. Maps at the section level describe the location of vehicles, targets, landmarks, and local terrain features such as buildings, roads, woods, fields, streams, fences, ponds, etc. Sensory processing determines the position of landmarks and terrain features, and tracks the motion of groups of vehicles and targets. Value judgment evaluates plans and computes cost, risk, and payoff of various alternatives. An operator interface allows human operators to visualize the status of the battlefield within the scope of the section, or to intervene to change priorities and reorder the sequence of operations or selection of targets. Vehicle commanders issue commands to their respective vehicles, monitor how well plans are being followed, and make adjustments as necessary to keep on plan. Output commands to individual vehicles to engage targets or maneuver relative to landmarks or other vehicles may be issued at any time, but on average are planned for tasks that last about 1 min.
Surrogate section, platoon, and battalion nodes in each UGV perform the functions of higher level command echelons when the UGV is not in direct communication with its chain of commands. Each surrogate node plans activities for the UGV on a time scale commensurate with planning activities in the respective higher level echelons, and estimates what vehicle level maneuvers should be executed in order to follow those plans.
Level 4 - Individual Vehicle
The vehicle is a unit that consists of a group of subsystems, such as mobility, attention, communication, and mission package. A manned scout vehicle may have a driver, vehicle commander, and a lookout. Thus, a 4D/RCS node at the vehicle level corresponds to a vehicle commander plus subsystem planners and executors. The vehicle commander assigns jobs to subsystems and schedules the activities of all the subsystems within the vehicle. A schedule of waypoints is developed by the mobility subsystem to avoid obstacles, maintain position relative to nearby vehicles, and achieve desired vehicle heading and speed along the desired path on roads or cross-country. A schedule of tracking activities is generated for the attention subsystem to track obstacles, other vehicles, and targets. A schedule of activities is generated for the mission package and the communication subsystems. Waypoints and task activities about 5 s apart out to a planning horizon of 1 min are replanned every 5 s, or more often if necessary.
At the vehicle level, the world model symbolic database contains names (identifiers) and attributes of objects, such as: the size, shape, and surface characteristics of roads, ground cover, or objects such as rocks, trees, bushes, mud, and water. Maps are generated from on-board sensors with a range of about 500 m and resolution of 4 meters. These maps are registered and overlaid with 30 meter resolution map data from Section level maps. Maps represent object positions (relative to the vehicle) and dimensions of road surfaces, buildings, trees, craters, and ditches. Sensory processing measures object dimensions and distances, and computes relative motion. Value judgment evaluates trajectory planning and sensor dwell time sequences. An operator interface allows a human operator to visualize the status of operations of the vehicle, and to intervene to change priorities or steer the vehicle through difficult situations. Subsystem controller executors sequence commands to subsystems, monitor how well plans are being followed and modify parameters as necessary to keep on plan. Output commands to subsystems may be issued at any time, but typically are planned to change only about once every 5 s.
Level 3 - Subsystem Level
Each subsystem node is a unit consisting of a controller for a group of related Primitive level sub-subsystems. A 4D/RCS node at the Subsystem Level assigns jobs to each of its Primitive sub-subsystems and coordinates the activities among them. A schedule of Primitive mobility waypoints and Primitive mobility actions is developed to avoid obstacles. A schedule of pointing commands is generated for aiming cameras and sensors. A schedule of messages is generated for communications, and a schedule of actions is developed for operating the mission package sub-subsystems. The Primitive mobility way points are about 500 ms apart out to a planning horizon of about 5 s in the future. A new plan is generated about every 500 ms.
At the Subsystem level, the world model symbolic database contains names and attributes of environmental features such as: road edges, holes, obstacles, ditches, and targets. Vehicle centered maps with a range of 50 meters and resolution of 40 cm are generated using data from range sensors. These maps represent the shape and location of terrain features and obstacle boundaries. Sensory processing computes surface properties such as dimensions, area, orientation, texture, and motion. Value judgment supports planning of steering and aiming computations, and evaluates sensor data quality. An operator interface allows a human operator to visualize the state of the vehicle, or to intervene to change mode or interrupt the sequence of operations. Subsystem executors compute at a 5 Hz clock rate. They sequence commands to primitive systems, monitor how well plans are being followed, and modify parameters as necessary to keep on plan. Output commands to Primitive sub-subsystems may be issued at any 200 ms interval, but typically are planned to change on average about once every 500 ms.
Level 2 - Primitive Level
Each node at the Primitive level is a unit consisting of a group of controllers that plan and execute velocities and accelerations to optimize dynamic performance of components such as steering, braking, acceleration, gear shift, camera pointing, and weapon loading and pointing, while taking into consideration dynamical interaction between mass, stiffness, force, and time. Communication messages are encoded into words and strings of symbols. Velocity and acceleration set points are planned every 50 ms out to a planning horizon of 500 ms.
The world model symbolic database contains names and attributes of state variables and features such as target trajectories and edges of objects. Maps are generated from camera data. Five-meter maps have a resolution of about 4 cm. Driving plans can be represented by predicted tire tracks on the map, and visual attention plans by predicted fixation points in the visual field.
Sensory processing computes linear image features such as occluding edges, boundaries, and vertices and detects strings of events. Value judgment cost functions support dynamic trajectory optimization. An operator interface allows a human operator to visualize the state of each controller, and to intervene to change mode, to override velocities, or to teleoperate the vehicle. Primitive level executors keep track of how well plans are being followed, and modify parameters as necessary to keep within tolerance. Primitive executors compute at a 20 Hz clock rate. Output commands are issued to the Servo level to adjust set points for vehicle steering, velocity, and acceleration or for pointing sensors or weapons platforms. Output commands are issued every 50 ms.
Level 1 - Servo Level
Each node at the servo level is a unit consisting of a group of controllers that plan and execute actuator motions and forces, and generate discrete outputs. Communication message bit streams are produced. The servo level transforms commands from component to actuator coordinates and computes motion or torque commands for each actuator. Desired forces, velocities, and discrete outputs are planned for 5 ms intervals out to a planning horizon of 50 ms.
The world model symbolic database contains values of state variables such as actuator positions, velocities, and forces, pressure sensor readings, position of switches, and gear shift settings. Sensory processing detects events and scales and filters data from individual sensors that measure position, velocity, force, torque, and pressure. Sensory processing also computes pixel attributes in images such as spatial and temporal gradients, stereo disparity, range, color, and image flow. An operator interface allows a human operator to visualize the state of the machine, or to intervene to change mode, set switches, or jog individual actuators. Executors cause servo actuators and motors to follow planned trajectories. Position, velocity, or force servoing may be implemented, and in various combinations. Servo executors compute at a 200 Hz clock rate. Motion output commands to power amplifiers specify desired actuator torque or power every 5 ms. Discrete output commands produce switch closures and activate relays and solenoids.
The above example illustrates how the 4D/RCS multilevel hierarchical architecture
assigns different responsibilities and duties to various levels of the hierarchy
with different range and resolution in time and space at each level. At each
level, sensory data is processed, entities are recognized, world model representations
are maintained, and tasks are decomposed into parallel and sequential subtasks,
to be performed by cooperating sets of agents. At each level, feedback from
sensors reactively closes a control loop allowing each unit at each level to
respond and react to unexpected events.
At each level, there is a characteristic range and resolution in space and time,
a characteristic bandwidth and response time, and a characteristic planning
horizon and level of detail in plans. The 4D/RCS architecture thus organizes
the planning of behavior, the control of action, and the focusing of computational
resources such that RCS_NODEs at each level have a limited amount of responsibility
and a manageable level of complexity.
There are three ways to visualize a 4D/RCS hierarchy. These are illustrated in Figure 6.
Figure 6. Three views of the 4D/RCS architecture. The organizational hierarchy shows the RCS_NODES arranged as a hierarchy of organizational units. The computational hierarchy shows the internal structure of the nodes in single chain of commands. The behavioral hierarchy shows the time history of commands that flow in a chain of commands over a period of time.
Figure 7 is a computational hierarchy view of the first five levels in the chain of commands containing the Autonomous Mobility Subsystem in the 4D/RCS architecture developed for Demo III. On the right of Figure 7, Behavior Generation (consisting of Planner and Executor) decompose high level mission commands into low level actions. The text inside the Planner at each level indicates the planning horizon at that level.
Figure 7. Five levels of the 4D/RCS architecture for Demo III. On the right are Planner and Executor modules. In the center are maps for representing terrain features, road, bridges, vehicles, friendly/enemy positions, and the cost and risk of traversing various regions. On the left are Sensory Processing functions, symbolic representations of entities and events, and segmented images with labeled regions. The coordinate transforms in the middle use range information to assign labeled regions in the entity image hierarchy on the left to locations on planning maps on the right. This causes the entity class hierarchy on the left to be orthogonal to the BG process hierarchy on the right.
The Executor at each level executes the plan generated by the Planner. Meanwhile, the Planner is replanning based on an updated world state. Each planner has a world model simulator that is appropriate for the problems encountered within the node at its level. The Planners and Executors operate asynchronously. At each level, the Planner generates a new plan and the Executor outputs new commands to subordinates on the order of ten times within each planning horizon. At each lower level, the planning horizons shrink by a factor of about ten. The relative timing relationships between levels are designed to facilitate control stability and smooth transitions among hierarchical control levels. The timing numbers in Figure 7 are illustrative only. The actual rates may differ in different applications.
In the center of Figure 7, each map has a range and resolution that is appropriate for path planning at its level. At each level, there are symbolic data structures and segmented images with labeled regions that describe entities, events, and situations that are relevant to decisions that must be made at that level. On the left is a sensory processing hierarchy that extracts information from the sensory data stream that is needed to keep the world model knowledge database current and accurate.
At the bottom of Figure 7 are actuators that act on the world and sensors that measure phenomena in the world. The Demo III XUVs are designed to accommodate a variety of sensors that include a LADAR, stereo CCD cameras, stereo FLIRs, a color CCD, vegetation penetrating radar, GPS (Global Positioning System), an inertial navigation package, actuator feedback sensors, and a variety of internal sensors for measuring parameters such as engine temperature, speed, vibration, oil pressure, and fuel level. The XUVs also may carry a Reconnaissance, Surveillance, and Target Acquisition (RSTA) package that includes long-range cameras and FLIRs, a laser range finder, and an acoustic package.
In Figure 7, the bottom (Servo) level has no map representation. The Servo level deals with actuator dynamics and reacts to sensory feedback from actuator sensors. The Primitive level map has range of 5 m with resolution of 4 cm. This enables the vehicle to make small path corrections to avoid bumps and ruts during the 500 ms planning horizon of the Primitive level. The Primitive level also uses accelerometer data to control vehicle dynamics and prevent roll-over during high speed driving. The Subsystem level map has range of 50 m with resolution of 40 cm. This map is used to plan about 5 s into the future to find a path that avoids obstacles and provides a smooth and efficient ride. The Vehicle level map has a range of 500 m with resolution of 4 m. This map is used to plan paths about 1 min into the future taking into account terrain features such as roads, bushes, gullies, or tree lines. The Section level map has a range of 2 km with resolution of about 30 m. This map is used to plan about 10 min into the future to accomplish tactical behaviors. Higher level maps (not shown in Figure 7) can be used to plan platoon, company, and battalion missions lasting about 1 h, 5 h, and 24 h respectively. These are derived from military maps and intelligence provided by the digital battlefield database.
At all levels, 4D/RCS planners are designed to generate new plans well before current plans become obsolete. Thus, action always takes place in the context of a recent plan, and feedback through the executors closes reactive control loops using recently selected control parameters. To meet the demands of dynamic battlefield environments, the 4D/RCS architecture specifies that replanning should occur within about one-tenth of the planning horizon at each level.
Executors are designed to react to sensory feedback even faster than the replanning interval. The Executors monitor feedback from the lower levels on every control cycle. Whenever an Executor senses an error between its output CommandGoal and the predicted state (status from the subordinate BG Planner) at the GoalTime, it may react by modifying the commanded action so as to cope with that error. This closes a feedback loop through the Executor at that level within a specified reaction latency.
3.12 The Inter-Node Interactions within a Hierarchy
Sensory processing and behavior generation are both hierarchical processes, and both are embedded in the nodes that form the 4D/RCS organizational hierarchy. However, the SP and BG hierarchies are quite different in nature and are not directly coupled. Behavior generation is a hierarchy based on the decomposition of tasks and the assignment of tasks to operational units. Sensory processing is a hierarchy based on the grouping of signals and pixels into entities and events. In 4D/RCS, the hierarchies of sensory processing and behavior generation are separated by a hierarchy of world modeling processes. The WM hierarchy provides a buffer between the SP and BG hierarchies with interfaces to both.
The WM interface with the SP hierarchy is designed to compare observations with predictions. This requires that WM predictions be at the same level of abstraction and in the same coordinate frame as SP observations at each level. On the other side, the WM interface with the BG hierarchy is designed to support task decomposition and planning. This requires that WM representations be at the same level of range and resolution in space and time, and be in the same coordinate system as the tasks being decomposed at each level. Figure 7 illustrates how the world modeling processes can be designed to fulfill both these requirements.
Note that in Figure 7, the left side of the world modeling hierarchy maintains a hierarchy of entity images that are linked to a hierarchy of symbolic frames. These represent a hierarchy of entities with increasing degree of aggregation (i.e., pixels, list entities, surface entities, object entities, etc.) Yet the right side of the world modeling hierarchy maintains a hierarchy of maps with increasing range and decreasing resolution. It is in the middle of the world modeling hierarchy that a coordinate transformation process converts from image coordinates to map coordinates. As a result, entities at any level in the image domain may transform into maps at any level in the planning domain. For example, an entity near the bottom of an image (short range) might be transformed into a Primitive level map, whereas another pixel in the same image near the horizon (long range) might transform into a Vehicle or Section level map. Thus, where an entity in the image ends up in the map depends not on its level in the SP hierarchy of entities, but on its distance from the camera. For example, a pixel or list entity in the image may end up in a Vehicle or Section level map, whereas an object or group entity in the image may end up in a Primitive or Subsystem level map. This flow of information between levels in the WM is represented in the 4D/RCS diagram of Figure 4 by the double-headed arrow marked "To Higher and Lower Level World Modeling" and in Figure 5 by the vertical pathways between WM processes.
A command vocabulary is the set of named actions or tasks that a 4D/RCS behavior generation (BG) process can perform. Each BG process at each level of the control hierarchy has its own unique command vocabulary. Examples of the command vocabularies at various levels of the Demo III hierarchy are:
Section Level Commands
¨ Init
¨ E-stop
¨ Pause/Resume (task T)
¨ Abort
¨ RetroTraverse (to point P)
¨ CooperativeSearch (of area A)
¨ PerformRouteReconnaissance (along route R)
¨ PerformAreaReconnaissance (of area A)
¨ ConductScreen(for unit U)
¨ PerformObstacleRestrictedRecon(over area A)
¨ ReconnoiterBuiltUpArea(area A)
¨ ConductTacticalMovement(to point P)
¨ ConductTacticalRoadMarch(along route R)
¨ EstablishObservationPost(at point P)
Section level commands are expressed in UTM WGS84 world coordinates. Parameters may include goal positions to be occupied, desired paths to be traversed, required regions to be observed. Parameters may also include specifications for performance such as speed, time of completion, required precision, and choice of formation (e.g., line, wedge, vee, and column, staggered). Mode parameters may include level of aggressiveness, priority, probability of enemy contact, and acceptable risk or cost. Constraint parameters may specify corridor boundaries and speed limit. Condition parameters may specify what is required to begin or continue. Typical intervals between Section level commands are 10 minutes.
Vehicle Level Commands
¨ Init
¨ E-stop
¨ Pause/Resume (task T)
¨ Abort
¨ RetroTraverse(to x, y by t)
¨ SendImage(between x1, y1 and x2, y2)
¨ ReportStatus
¨ NavigateToGoalPoint(at x, y by t)
¨ PerformRoadMarch(to x, y by t)
¨ OccupyOverwatchPosition(at x, y by t)
¨ OccupyObservation/ListeningPost(at x, y by t)
¨ DetectBarriersToMovement(between x1, y1 and x2, y2)
¨ ReconnoiterArea(between x1, y1 and x2, y2)
¨ ReconnoiterRoute(from x1, y1 to x2, y2 by t)
¨ LocateBypassOfArea(between x1, y1 and x2, y2)
¨ ReconnoiterTerrain(between x1, y1 and x2, y2)
¨ ReconnoiterDefilesOnRoute(from x1, y1 to x2, y2 by t)
¨ ReconnoiterLateralRoutesAlongRoute(from x1, y1 to x2, y2 by t)
¨ ReconnoiterApproachToRoute(from x1, y1 to x2, y2 by t)
¨ IdentifyVehicles&Personnel(between az1 and az2)
¨ IdentifyThreatVehicles(between az1 and az2)
¨ MoveToMaintainContact(with target)
¨ Hide&MaintainContact(with target)
¨ HideFromEnemy(between bearing1 and bearing2)
Vehicle level commands are expressed in vehicle-centered, North-oriented, world coordinates. Parameters typically specify where, when, how fast, and how important the task is. Typical interval between Vehicle level commands is 50 s.
Autonomous Mobility Subsystem Level Commands
¨ Init
¨ E-stop
¨ Pause/Resume
¨ Abort
¨ RetroTraverse(to position, velocity, heading by t)
¨ TurnAround(position, velocity, heading by t)
¨ BackUp(to position, velocity, heading by t)
¨ GoWithinCorridorTo(position, velocity, heading, right boundary, left boundary by t)
¨ GoToRoad(position at velocity or by t)
¨ GoOnRoadTo(position at velocity in lane by t)
¨ GoBesideRoadTo(position at velocity, offset until t)
¨ GoStealthyTo(position, velocity, heading by t)
¨ GoToHillCrest(position, heading by t)
¨ LeaveHillCrest(position, heading by t)
¨ GoToFeature(feature, position, heading by t)
¨ DashTo(position, velocity, heading at t)
¨ Hide(position, heading by t)
¨ HullDown(position, heading)
¨ StopAt(phase line by t)
¨ ScanTreeLine(bearing, elevation, length)
¨ ConductSecurityHalt(position, heading at t)
Subsystem level commands are expressed in vehicle-centered, vehicle-oriented, world coordinates. Parameters may specify position, velocity, heading, and timing requirements. Typical interval between Subsystem level commands is 5 s.
Primitive Level - Primitive Driver Commands
¨ Init
¨ E-stop
¨ Pause/Resume
¨ Abort
¨ GoTo(position, velocity, heading by t)
¨ FollowLeadVehicle(at distance)
Primitive Level - Gaze Commands
¨ Init
¨ E-stop
¨ Pause/Resume
¨ Abort
¨ FixatePoint(at range, bearing, elevation)
¨ TrackObject(at range, bearing, velocity at t)
¨ ScanTrajectory(from range1, bearing1, elevation1 to range2, bearing2, elevation2)
Primitive level commands are expressed in vehicle-centered, vehicle-oriented, coordinates. Typical interval between Primitive level commands is 500 ms.
Servo Level - Drive Commands
¨ Init
¨ E-stop
¨ Pause/Resume
¨ Abort
¨ GoTo(range, bearing, speed, heading by t)
Servo Level - Look Commands
¨ Init
¨ E-stop
¨ Pause/Resume
¨ Abort
¨ GoTo(range, bearing, speed by t)
Servo level commands are expressed in vehicle-centered, vehicle-oriented, coordinates. The interval between Servo commands is 50 ms.
Actuator Commands
¨ Init
¨ E-stop
¨ Abort
¨ GoTo(position at t)
¨ GoAt(velocity at t)
¨ ExertForce(amount at t)
Actuator commands are expressed in actuator coordinates. The interval between actuator commands is 5 ms.
3.14 Command and Plan Structure
In each BG module, commands are decomposed into approximately a ten step plan for each of its subordinate BG modules. For each plan, an Executor cycles through the plan issuing commands to the appropriate subordinate BG modules. Commands into each BG module consist of at least six elements:
(1) ActionCommand (ac1) describes the action to be performed and may include a set of modifiers such as priorities, mode, path constraints, acceptable cost, and required conditions.
(2) GoalCommand (gc1) describes the desired state (or goal state) to be achieved by the action. Mobility system's state typically includes the position, heading, velocity, and turning rate of the system being controlled. The goal may include the name of a target or object that is to be acted upon. It also may include a set of modifiers such as tolerance.
(3) GoalTime (gt1) defines the timing constraint on achieving the goal plus modifiers such as tolerance.
(4) NextActionCommand (ac2) describes the planned next action to be performed plus modifiers.
(5) NextGoalCommand (gc2) describes the planned next goal state to be achieved plus modifiers.
(6) NextGoalTime (gt2) describes the timing constraint on achieving the next goal plus modifiers.
If we designate levels in the hierarchy by a superscript and a node index within each level by a subscript, then input to each behavior generation (BG) process is a command data structure of the form:
¨ ac1ji = ActionCommand plus modifiers for BG module i at level j
¨ gc1ji = GoalCommand state plus modifiers for BG module i at level j
¨ gt1ji = GoalTime plus modifiers for when gc1ji should be achieved
¨ ac2ji = NextActionCommanded plus modifiers for BG module i at level j
¨ gc2ji = NextGoalCommand state plus modifiers for BG module i at level j
¨ gt2ji = NextGoalTime plus modifiers for when gc2ji should be achieved
Figure 8 shows the command and plan structure for the first five levels of a Demo III XUV. Note that plans exist concurrently at all levels, and the data structures containing the plans form buffers between the planners and executors. This allows planners and executors to run asynchronously, and planners can be constantly replanning at all levels simultaneously and independently from execution.
Figure 8. The command and plan structure for Demo III. Note that the plan for each BG module is generated by, and resides in, the BG module above it. For example, the AM Plan for the Autonomous Mobility BG is generated by the Vehicle level planner. The AM plan resides in the Vehicle level BG module and is transformed into commands for the Autonomous Mobility BG by the Vehicle level AM Executor.
Section (level 5)
Commands to Section level BG processes have the form:
Section1 Command Structure
ActionCommand = ac151 GoalCommand = gc151 GoalTime = gt151 ˜ t + 10 min
NextActionCommand = ac251 NextGoalCommand = gc251 NextGoalTime = gt251 ˜
t + 20 min
where ˜ means equals approximately
The planner in each section level BG process decomposes commands into plans for each of its vehicle BG processes. Each subordinate plan is designed to have about ten steps. For example, a section with two vehicles would have a plan for two vehicles of the form:
| Vehicle1 Plan | Vehicle2 Plan | Typical Goal Times | |
|---|---|---|---|
| ap141, gp141, gt141 | ap142, gp142,gt142 | gt14i ˜ t+1 min | |
| ap241, gp241, gt241 | ap242, gp242,gt242 | gt24i ˜ t+2 min | |
| ap341, gp341, gt341 | ap342, gp342,gt342 | gt34i ˜ t+3 min | |
| ap441, gp441, gt441 | ap442, gp442,gt442 | gt44i ˜ t+4 min | |
| ap541, gp541, gt541 | ap542, gp542,gt542 | gt54i ˜ t+5 min | |
| ap641, gp641, gt641 | ap642, gp642,gt642 | gt64i ˜ t+6 min | |
| ap741, gp741, gt741 | ap742, gp742,gt742 | gt74i ˜ t+7 min | |
| ap841, gp841, gt841 | ap842, gp842,gt842 | gt84i ˜ t+8 min | |
| ap941, gp941, gt941 | ap942, gp942,gt942 | gt94i˜ t+9 min | |
| ap1041, gp1041, gt1041 | ap1042, gp1042,gt1042 | gt104i ˜ t+10 min |
Where:
apkji = action planned for BG module i at level j for plan step k
gpkji = goal planned for BG module i at level j for plan step k
gtkji = goal time planned for BG module i at level j for plan step k
t = time at which the command is scheduled to begin
The GoalTimes shown here illustrate only an approximation, an order of magnitude. Plan steps need not be equally spaced in time or space. There also might be more or fewer than ten steps in a plan.
Vehicle (level 4)
Commands to Vehicle level BG processes would have the form:
Vehicle1 Command Structure
ActionCommand = ac141 GoalCommand = gc141 GoalTime = gt141 ˜ t + 1 min
NextActionCommand = ac241 NextGoalCommand = gc241 NextGoalTime = gt241 ˜
t + 2 min
A vehicle with three subsystems would have a plan for each subsystem of the form:
| Autonomous Mobility Plan | RSTA Plan | Communications Plan | Goal Times | |
|---|---|---|---|---|
| ap131, gp131, gt131 | ap132, gp132, gt132 | ap133, gp133, gt133 | ap13i ˜ t+5 sec | |
| ap231, gp231, gt231 | ap232, gp232, gt232 | ap233, gp233, gt233 | ap23i ˜ t+10 sec | |
| ap331, gp331, gt331 | ap332, gp332, gt332 | ap333, gp333, gt333 | ap33i ˜ t+15 sec | |
| ap431, gp431, gt431 | ap432, gp432, gt432 | ap433, gp433, gt433 | ap43i ˜ t+20 sec | |
| ap531, gp531, gt531 | ap532, gp532, gt532 | ap533, gp533, gt533 | ap53i ˜ t+25 sec | |
| ap631, gp631, gt631 | ap632, gp632, gt632 | ap633, gp633, gt633 | ap63i ˜ t+30 sec< | |
| ap731, gp731, gt731 | ap732, gp732, gt732 | ap733, gp733, gt733 | ap73i ˜ t+35 sec | |
| ap831, gp831, gt831 | ap832, gp832, gt832 | ap833, gp833, gt833 | ap83i ˜ t+40 sec | |
| ap931, gp931, gt931 | ap932, gp932, gt932 | ap933, gp933, gt933 | ap93i ˜ t+50 sec | |
| ap1031, gp1031, gt1031 | ap1032, gp1032, gt1032 | ap1033, gp1033, gt1033 | ap103i ˜ t+60 sec |
Subsystem (level 3)
Commands to Subsystem level BG processes would have the form:
Autonomous Mobility Command Structure
ActionCommand = ac131 GoalCommand = gc131 GoalTime = gt131 ˜ t + 5 sec
NextActionCommand = ac231 NextGoalCommand = gc231 NextGoalTime = gt231 ˜
t + 10 sec
A mobility subsystem with Primitive level Driver and Gaze unit controllers would have the form:
| Driver Plan | Gaze Plan | Typical Goal Times |
|---|---|---|
| ap121, gp121, gt121 | ap122, gp122, gt122 | gt12i ˜ t+0.5 sec |
| ap221, gp221, gt221 | ap222, gp222, gt222 | gt22i ˜ t+1.0 sec |
| ap321, gp321, gt321 | ap322, gp322, gt322 | gt32i ˜ t+1.5 sec |
| ap421, gp421, gt421 | ap422, gp422, gt422 | gt42i ˜ t+2.0 sec |
| ap521, gp521, gt521 | ap522, gp522, gt522 | gt52i ˜ t+2.5 sec |
| ap621, gp621, gt621 | ap622, gp622, gt622 | gt62i ˜ t+3.0 sec |
| ap721, gp721, gt721 | ap722, gp722, gt722 | gt72i ˜ t+3.5 sec |
| ap821, gp821, gt821 | ap822, gp822, gt822 | gt82i ˜ t+4.0 sec |
| ap921, gp921, gt921 | ap922, gp922, gt922 | gt92i ˜ t+4.5 sec |
| ap1021, gp1021, gt1021 | ap1022, gp1022, gt1022 | gt102i ˜ t+5.0 sec |
Primitive (level 2)
Commands to Primitive level BG processes would have the form:
Driver Command Structure
ActionCommand = ac121 GoalCommand = gc121 GoalTime = gt121 ˜ t + 0.5 sec
NextActionCommand = ac221 NextGoalCommand = gc221 NextGoalTime = gt121 ˜
t + 1.0 sec
Primitive level plans for the Servo level BG units would have the form:
| Velocity Plan | Goal Times | |
|---|---|---|
| ap111, gp111, gt111 | gt11i = t+50 ms | |
| ap211, gp211, gt211 | gt21i = t+100 ms | |
| ap311, gp311, gt311 | gt31i = t+150 ms | |
| ap411, gp411, gt411 | gt41i = t+200 ms | |
| ap511, gp511, gt511 | gt51i = t+250 ms | |
| ap611, gp611, gt611 | gt61i = t+300 ms | |
| ap711, gp711, gt711 | gt71i = t+350 ms | |
| ap811, gp811, gt811 | gt81i = t+400 ms | |
| ap911, gp911, gt911 | gt91i = t+450 ms | |
| ap1011, gp1011, gt1011 | gt101i = t+500 ms |
Note that time intervals in plans become uniform at the Primitive level and below.
Servo (level 1)
Commands to Servo level BG controllers would have the form:
Velocity Command Structure
ActionCommand = ac111 GoalCommand = gc111 GoalTime = gt111 = t + 50 ms
NextActionCommand = ac211 NextGoalCommand = gc211 NextGoalTime = gt211 = t +
100 ms
Servo level plans for each Actuator would have the form:
| Wheel Motors | Front Steer Motor | Rear Steer Motor | Goal Times | |
|---|---|---|---|---|
| ap101, gp101, gt101 | ap102, gp102, gt102 | ap103, gp103, gt103 | ap10i = t+5 ms | |
| ap201, gp201, gt201 | ap202, gp202, gt202 | ap203, gp203, gt203 | ap20i = t+10 ms | |
| ap301, gp301, gt301 | ap302, gp302, gt302 | ap303, gp303, gt303 | ap30i = t+15 ms | |
| ap401, gp401, gt401 | ap402, gp402, gt402 | ap403, gp403, gt403 | ap40i = t+20 ms | |
| ap501, gp501, gt501 | ap502, gp502, gt502 | ap503, gp503, gt503 | ap50i = t+25 ms | |
| ap601, gp601, gt601 | ap602, gp602, gt602 | ap603, gp603, gt603 | ap60i = t+30 ms | |
| ap701, gp701, gt701 | ap702, gp702, gt702 | ap703, gp703, gt703 | ap70i = t+35 ms | |
| ap801, gp801, gt801 | ap802, gp802, gt802 | ap803, gp803, gt803 | ap80i = t+40 ms | |
| ap901, gp901, gt901 | ap902, gp902, gt902 | ap903, gp903, gt903 | ap90i = t+45 ms | |
| ap1001, gp1001, gt1001 | ap1002, gp1002, gt1002 | ap1003, gp1003 , gt1003 | ap100i = t+50 ms |
Actuators (level 0)
Commands to Actuators would have the form:
Actuator i
ActionCommand0i = ac10i GoalCommand = gc10i GoalTime = gt10i = t + 5 ms
Where:
ac10i = ap10i + kfb(gc10i - x1*0i)
x1*0i = predicted state of i-th actuator at next sample
gc10i = gp10i
kfb = feedback gain
Example Data Structures
An example of a C++ class data structure for a command from the Vehicle level to the Subsystem Autonomous Mobility level might be:
/* GoToHillCrest *****************************************/
class GO_TO_HILL_CREST_CMD : public RCS_CMD_MSG
{
public:
GO_TO_HILL_CREST_CMD(); // Constructor
void update(CMS *); // update function.
// action modifiers
int stealthiness; // 1 to 100% stealthy
double speedLimit; // in meters/sec
// GoalCommand
double x_goal; // desired x position on a map about 50 meters away
double y_goal; // desired y position on a map about 50 meters away
char speedAtGoal; // desired speed in m/s at GoalCommand (0 if stop at goal)
double headingAtGoal; // desired heading at GoalCommand
// goal modifiers
double timeToGetToGoal; // ~ 5 seconds for a vehicle level command
double timeTolerance; // ± seconds
double goalTolerance; // close enough radius to goal
};
An example of a status message from the Autonomous Mobility Subsystem level
Planner to the Vehicle level Executor might be:
/* Status feedback *****************************************/
class AM_VEHICLE-STATUS : public RCS_STAT_MSG
{
public:
AM_VEHICLE-STATUS (); // Constructor
void update(CMS *); // update function.
boolean ExitIfPastGoal; // task done flag
// predicted state yd* at command GoalTime = gt131
double x_predictedAtGoalTime;
double y_predictedAtGoalTime;
double speed_predictedAtGoalTime;
double heading_predictedAtGoalTime;
// estimated time to reach GoalCommand
double estimatedTimeToGoal;
// predicted state at planning horizon (i.e., at last subgoal yd1021)
double x_predictedAtPlanHorizon;
double y_predictedAtPlanHorizon;
double speed_predictedAtPlanHorizon;
double heading_predictedAtPlanHorizon;
};
Multiple levels of deliberative planning make it possible for plans to be recomputed frequently enough that they never become obsolete. Planners generate new plans well before current plans are fully executed. Typically, replanning is completed by the time the first subgoal is achieved in the current plan (e.g., replanning at level 3 occurs about every 500 milliseconds). Executors react to sensory feedback even faster5(e.g., reaction at level 3 occurs within 100 milliseconds.)
To achieve this rate of replanning, it is necessary to limit the amount of data in the world model that needs to be refreshed between each planning cycle. Multilevel representation of space limits the number of resolution elements required in maps and the amount of detail in symbolic data structures at each level. Multilevel representation of time limits the number of events and temporal detail required at each level. The world model in any node is rich and detailed within the region of attention, but contains only the amount of resolution in space and time required for making decisions in that node. This enables the world model in each node to be updated in real-time.
To replan frequently, it is also necessary to limit the amount of search required to generate new plans. There are several ways to limit the search. One is to pre-compute and store plans that can be selected by a rule-based planner in response to the recognition of an object, event, or situation. A second approach is to limit the range and resolution of the state space that needs to be searched and evaluated. At each level, the range and resolution of maps can be limited to less than 64,000 resolution elements.
The 4D/RCS architecture has an interface between deliberative and reactive execution in every node at every hierarchical level. This enables 4D/RCS to fully realize the desirable traits of both deliberative and reactive control in a practical system. Multiple levels of deliberative planning ensure that plans can be recomputed frequently enough that they never become obsolete. Multiple levels of representation cause the planning search space to be limited in range and resolution, and the plans to be limited in the number of steps and amount of detail. Multiple levels of feedback from the environment ensure that reactive behavior can be generated with a minimum of feedback time delay. Table 1 contains suggested 4D/RCS specifications for the planning horizon, replanning interval, and reaction latency at all eight levels:
| Level | Planning horizon | Replan interval | Reaction latency |
|---|---|---|---|
| 1 Servo | 50 ms | 50 ms | 5 ms |
| 2 Primitive | 500 ms | 50 ms | 50 ms |
| 3 Subsystem | 5 s | 500 ms | 200 ms |
| 4 Vehicle | 50 s | 5 s | 500 ms |
| 5 Section | 10 min | 50 s | 2 s |
| 6 Platoon | 1 h | 5 min | 5 s |
| 7 Company | 5 h | 30 min | 10 s |
| 8 Battalion | 24 h | 2 h | 20 s |
Table 1. The Planning Horizon, Replan Interval, and Executor Reaction Latency at each level of the 4D/RCS hierarchy
The planning horizon refers to the future point in time to which each level
plans. Plans at each level typically have 5 to 10 steps between the anticipated
starting state and a planned goal state at the planning horizon. Thus, the planning
horizon typically grows about one order of magnitude longer at each successively
higher level.
Reaction latency is the minimum delay through the reactive feedback loop at
each level. Reaction can interrupt cyclic replanning to immediately select an
emergency plan, and to begin a new replanning cycle based on new information.
Reaction latencies at each level are determined by computational delays in updating
the world model as well as the sampling frequency and computation cycle rate
of the Executors. The fastest servo update rate on a typical vehicle controller
is 200 Hz. Thus, the reaction latency at the Servo level is 5 ms. The required
execution cycle rate at other levels depends on the dynamics of the mechanism
being controlled and the speed of the available computers.
There are two kinds of plans that are required by the FCS vehicles: (1) path plans for mobility, and (2) task plans for tactical behaviors. A typical path plan consists of a series of waypoints on a map. A typical task plan consists of a set of instructions or rules that describes a sequence of actions and subgoals required to complete the task. Both path plans and task plans can be represented in the form of augmented state graphs, or state tables, which define a series of planned actions (subtasks) with a desired state (subgoal) to be achieved by each action in the plan. Typically states are represented by nodes, and actions are represented by arcs that connect the nodes. Both types of plans can be executed by the same executor mechanism.
In principle, both types of planning can be performed by searching the space of possible futures to find a desirable solution. However, path planning typically requires searching only a two-dimensional space on a map. Task planning requires searching an N-dimensional space of all possible states and actions. Searching high dimensional spaces can be accomplished by evolutionary algorithms [Fogel99] or reinforcement learning techniques. [Sutton and Barto98] However, these methods are typically too slow for real-time use at levels where plans must be recomputed faster than once every few minutes. Therefore, real-time task planning is typically done by searching a library of schema or recipes that have been developed off-line and stored where they can be accessed by rules or case statements when conditions arise. When there are more than one recipe or schema that are appropriate to a task, each may be submitted to the world model for simulation and the predicted results evaluated by the value judgment process. The plan selector then selects the best recipe or schema for execution.
In 4D/RCS, path planners use cost maps that represent the estimated cost or risk of being in, or traversing, regions on the map. Values represented in cost maps depend on mission priorities and knowledge of the tactical situation represented in the KD. Path planners search the cost maps for routes that have the lowest cost under a given situation. Task planners use rules of engagement, military doctrine, and case-based reasoning to select modes of operation and schema for tactical behaviors. State variables such as mission priorities and situational awareness determine cost functions and hence decisions regarding which type of behavior to select.
For example, if enemy contact is likely or has occurred, cost maps of open regions and roads will carry a high cost. Regions near tree lines and under tree cover will have lower cost as long as they are cleared of enemy threats. In this case, path planners will plan cautious routes near tree lines or through wooded areas, and task planners will plan behaviors designed to search for evidence of enemy activity in likely places. However, if enemy contact is unlikely, roads will have a very low cost and open regions will carry a lower cost than wooded areas. This will cause path planners to plan higher speed routes on the road or through open regions, and task planners to focus on issues such as avoiding local traffic. Thus, a very small amount of information, such as knowledge that enemy contact is likely or unlikely, can completely change the tactical behavior of the vehicle in a very logical, intuitive, and meaningful way.
For the Demo III program, the range and resolution of maps is limited to about 128 resolution elements from the center of the map in each direction at each level. This means that each map contains about 256x256 (˜ 64,000 pixels). The suggested range and resolution of maps at all levels of the FCS 4D/RCS hierarchy are shown in Table 2. Maps at each level provide information to planners about the position, attributes, and class of entities. For example, maps at various levels may indicate the shape, size, class, and motion of objects such as obstacles and vehicles, and the location of roads, intersections, bridges, streams, woods, lakes, buildings, and towns.
| Level | Map | Resolution Map | Range Function Performed |
|---|---|---|---|
| 1 Servo | n/a | n/a | Actuator servo |
| 2 Primitive | 4 cm | 5 m | Vehicle heading, speed |
| 3 Subsystem | 40 cm | 50 m | Obstacle avoidance |
| 4 Vehicle | 4 m | 500 m | Single vehicle tactical behaviors |
| 5 Section | 30 m | 2 km | ection level tactical behaviors |
| 6 Platoon | 30 m | 10 km | Platoon level tactical behaviors |
| 7 Company | 30 m | 30 km | Company level tactical behaviors |
| 8 Battalion | 30 m | 100 km | Battalion level tactical behaviors |
Table 2. Range and resolution of maps at all levels in the proposed FCS 4D/RCS architecture. Range is measured from the vehicle at the center of each map.
In general, map range and resolution depend on velocity and the planning time
horizon. For any given planning time horizon, the map range must be sufficient
to guarantee that the plan will fit on the map. For different vehicle speeds,
the map resolution required for planning at various levels will be different.
The numbers in Table 2 are for ground vehicles traveling about 10 m/s. A helicopter
skimming over the ground at 100 m/s would require planning maps with an order
of magnitude greater range and an order of magnitude lower resolution than that
shown above. For systems with widely varying velocities, map range and resolution
may need to be velocity dependent.
