4D/RCS is a methodology for conceptualizing, designing, engineering, integrating, and testing intelligent systems software for vehicle systems with any degree of autonomy, from manually operated to fully autonomous. The theoretical foundation for this methodology is the 4D/RCS reference model architecture.
Df. A methodology is a set of methods, rules, and postulates employed by a discipline.
Df. An architecture is the structure that identifies, defines, and organizes components, their relationships, and principles of design; the assignment of functions to subsystems and the specification of the interfaces between subsystems.
Df. A reference model architecture is an architecture in which the entire collection of entities, relationships, and information units involved in interactions between and within subsystems and components are defined and modeled.
Df. An intelligent system is a system with the ability to act appropriately in an uncertain environment.
Df. An appropriate action is that which maximizes the probability of successfully achieving the mission goals.
Df. A mission goal is a desired result that a mission is designed to achieve or maintain.
Df. A result is represented as a state or some integral measure of a state-time history.
Df. A mission is the highest level task assigned to the system.
The 4D/RCS reference model architecture has the following properties:
- It defines the functional elements, subsystems, interfaces, entities, relationships, and information units involved in intelligent vehicle systems.
- It supports the selection of goals, the establishment of priorities and rules of engagement, the generation of plans, the decomposition of tasks, and the scheduling of activities; and it provides for feedback to be incorporated into control processes so that both deliberative and reactive behaviors can be combined into a single integrated system.
- It supports the processing of signals from sensors into knowledge 1. of situations and relationships; and it provides for the storage of knowledge in representational forms that can support reasoning, decision-making, and intelligent control.
- It provides both static (typically for long-term) and dynamic (typically for short-term) means for representing the richness and abundance of knowledge necessary to describe the environment and state of a battlefield and the intelligent vehicle systems operating within it.
- It supports the transformation of information from sensor signals into symbolic and iconic representations of objects, events, and situations, including semantic, pragmatic, and causal relationships; and it supports transformations from iconic (pictorial) to descriptive (symbolic) forms, and vice versa.
- It supports the acquisition (or learning) of new information and the integration and consolidation of newly acquired knowledge into long-term memory.
- It provides for the representation of values, the computation of costs and benefits, the assessment of uncertainty and risk, the evaluation of plans and behavioral results, and the optimization of control laws.
Details of these properties will be given in the corresponding sections later in this document.
4D/RCS draws on a number of commercial and military standards to facilitate the design, development, debugging, maintenance, and upgrading of subsystems and software. 4D/RCS is compatible with all relevant standards developed under the following U.S. Department of Defense programs: the DoD Joint Technical Architecture (JTA) [DoD 02] and Technical Reference Model (TRM) [TRM 02], Battlefield Digitization [PEO C3T 02], the C4ISR Architecture Framework [CISA 02], the Army Joint Technical Architecture-Army [JTA-A 02] and Weapon System Technical Architecture Working Group (WSTAWG) [WSTAWG 02], the Office of the Secretary of Defense (OSD) Joint Architecture for Unmanned Ground Systems (JAUGS) [JAUGS 02], and the TARDEC Vehicle Electronics (Vetronics) Reference Architecture (VRA) [Vetronics 02, VRA 01].
JTA and JTA-A define an architecture to have three interrelated views, operational architecture, technical architecture, and systems architecture. The 4D/RCS reference model architecture specifies tasks, commands, and their planning and execution, organizational units, and information flows that support the operational architecture. 4D/RCS provides a development and application framework for the standards and conventions that the technical architecture covers. The 4D/RCS control hierarchy provides a logical layout that supports the system architecture. These demonstrate the comprehensiveness of 4D/RCS, covering all the JTA and JTA-A architectural aspects.
4D/RCS provides a methodology by which military systems that meet the operational requirements defined in the JAUGS Domain Model can be engineered to meet the performance specifications defined in the JAUGS Reference Architecture. 4D/RCS has been included in the current draft TARDEC VRA as a mandate for robotic systems. 4D/RCS endorses VRA's assessment that the VRA and 4D/RCS development teams will monitor each other's progress and continue to interact on a regular basis. 4D/RCS is contributing to the various Integrated Product Teams (IPT) in WSTAWG.
4D/RCS plans to continue contributing to major DoD standards organizations and fostering an open system based architectural environment. Such an environment facilitates major DoD goals of interoperability and time/cost reduction for system development. An open system based architectural environment also facilitates the Army's goal of transitioning to the Objective Force.
Science and Technology Orientation
4D/RCS integrates the NIST Real-time Control System (RCS) [Albus and Meystel 96] architecture with the German (Universitat der Bundeswehr Munchen) VaMoRs 4-D approach to dynamic machine vision [Dickmanns, et al. 94]. It incorporates many concepts developed under the U.S. Department of Defense Demo I, Demo II, and Demo III programs [Albus et al. 02, Shoemaker et al. 99, Shoemaker et al. 98, Haas, et al. 96], which demonstrated increasing levels of robotic vehicle autonomy. The theory embodied in 4D/RCS borrows heavily from cognitive psychology, semiotics, neuroscience, and artificial intelligence. It incorporates concepts and techniques from control theory, operations research, game theory, pattern recognition, image understanding, automata theory, and cybernetics from the application domain perspective. The 4D/RCS architecture consists of a multi-resolution hierarchy of feedback control loops between sensing and acting that integrate reactive behavior with perception2, world modeling, and planning - and forming a hybrid deliberative/reactive system [Rasmussen 02, 01, Maximov 92]. A review of projects that have used RCS and a description of how RCS relates to other intelligent system architectures are contained in [Albus and Meystel 01] and [Meystel and Albus 02].
4D/RCS also adopts many software engineering techniques, including object-orientation [Huang et al. 01, Huang and Messina 96], reuse, interoperability [Gazi et al. 01], component-based software [Horst 00], software specification [Messina and Huang 02], testing, and formal models [Dabrowski 99].
Versions 0.1 and 1.0 of the 4D/RCS architecture were designed to support the design, engineering, integration, and test of intelligent system software for experimental unmanned ground vehicles developed under the Army Research Laboratory Demo III program [Shoemaker et al 99, Bornstein 02, Hong et al. 02a-d, Murphy et al. 02]. Version 2.0 of the 4D/RCS reference model architecture is intended to facilitate the integration of a wide variety of unmanned and manned vehicles and sensors (ground, air, and amphibious) into an effective fighting force system-of-systems within the framework of the Army Future Combat Systems (FCS).
The 4D/RCS methodology addresses the problem of intelligent control at three layers of abstraction: (1) a conceptual framework; (2) a reference model architecture; and (3) engineering guidelines. They are a series of successively refined descriptions in terms of the details and specific features; in other words, the upper layers mold the lower. The conceptual framework provides the overall shape for the reference model architecture. The reference model architecture provides guidance for how to apply the engineering guidelines.
If, during implementation, the engineering guidelines require changing, it will be desirable to do so without changing the reference model architecture, since adherence to the reference model helps ensure that the engineering guidelines are compatible with one another. The system builder must understand the reference model in order to apply it.
1.1.1 A Conceptual Framework
The 4D/RCS architecture is derived from the proven RCS architecture. RCS is
domain independent. The 4D/RCS conceptual framework is a mapping of RCS tenets
to the domain of intelligent vehicle systems for military use.
At the highest layer of abstraction, 4D/RCS is intended to provide a conceptual framework for addressing the general problem of intelligent vehicle systems, operating in man-made and natural environments, pursuing mission goals, and supervised by human commanders.
The 4D/RCS conceptual framework spans the entire range of operations that affect intelligent vehicles, from those that take place over time periods of milliseconds and distances of millimeters to those that take place over time periods of months and distances of thousands of kilometers. The 4D/RCS model is intended to allow for the representation of activities that range from detailed dynamic analysis of a single actuator in a single vehicle subsystem to the combined activity of planning and control for hundreds of vehicles and human beings in full dimensional operations covering an entire theater of battle. In order to span the wide range of activities included within the conceptual framework, the 4D/RCS adopts a multilevel hierarchical architecture with different range and resolution in time and space at each level3. The 4D/RCS architecture design integrates easily into the information intensive structure of Future Combat Systems (FCS) [Boeing 02] and other advanced concepts for the armed forces of the United States in the 21st century. For example, a current implementation of 4D/RCS is being interfaced to a distributed, interactive combat simulation within the OneSAF simulation/training system [OTB 02]. This enables real and/or virtual vehicles controlled by the 4D/RCS architecture to participate in force-on-force exercises with tens or hundreds of real or virtual vehicles, some manned, some controlled by 4D/RCS real-time controllers, and others controlled by OneSAF autonomous behaviors.
4D/RCS provides a progressive framework in terms of human involvement. The full range of operations conforming to 4D/RCS can be either totally performed by soldiers or fully autonomous with human supervision.
1.1.2 A Reference Model Architecture
At a lower layer of abstraction, the 4D/RCS is a reference model architecture. The architecture applies sound hierarchical control principles and, at the same time, closely follows the existing command and control structure of the military hierarchy in assigning duties and responsibilities and in requiring knowledge, skills, and abilities.
The 4D/RCS defines functional processes at each hierarchical control level such that each process embodies a set of responsibilities and priorities that are typical of operational units in a military organization. This enables the 4D/RCS architecture to map directly onto the military command and control organization to which the intelligent vehicles are assigned. The result is a system architecture that is understandable and intuitive for the human commander and integrates easily into battle space visualization and simulation systems.
1.1.3 Engineering Guidelines
At a still lower layer of abstraction, the 4D/RCS is intended to provide engineering guidelines for building and testing specific intelligent vehicle systems. In order to build a practical system in the near term, 4D/RCS engineering guidelines have been developed bottom-up, starting with a single vehicle and its subsystems. The 4D/RCS engineering guidelines define how intelligent vehicles should be configured to work together in groups with other intelligent vehicles, both manned and unmanned, in units of various sizes.
The type of problems to be addressed by the 4D/RCS engineering guidelines include:
· Navigating and driving both on and off roads,
· Responding to human supervisor commands and requests,
· Accomplishing mission goals and priorities amid the uncertainties of the battlefield,
· Cooperating with friendly agents in conducting tactical behaviors,
· Acting appropriately with respect to hostile agents, and
· Reacting quickly, effectively, and resourcefully to obstacles and unexpected events.
Intelligent vehicle systems typically consist of a variety of sensors, actuators, navigation and driving systems, communications systems, mission packages, and weapons systems controlled by an intelligent controller.
Sensors may include charge coupled device (CCD) television cameras, laser radar (LADAR) range imaging cameras, forward looking infrared (FLIR) cameras, radar, acoustic arrays, chemical or radiation detectors, and radio frequency receivers, as well as inertial, force, pressure, and temperature sensors. Actuators may include motors, pistons, steering, brakes, throttle, lasers, radio frequency (R.F.) transmitters, and pointing systems for cameras, antennas, and weapons.
Navigation and driving systems may include computer aided mission planning systems, digital terrain map management systems, route planning systems, GPS and inertial guidance systems, and machine vision systems for on and off road driving, with obstacle avoidance, target tracking, object classification, and image understanding capabilities.
Communications may include microwave, packet radio, and lasers, and may include relay via other ground vehicles, air vehicles, or satellite communications. Updates for terrain data or over-the-hill visualization may be supplied by unmanned air vehicles or satellite surveillance systems.
Mission packages may include reconnaissance, surveillance, and target acquisition systems, range finders, laser designators, direct or indirect fire weapons, counter mine equipment, sniper detection equipment, smoke generators, electronic warfare equipment, logistics support, or communications relay antennas. The weapons may include machine guns, recoilless rifles, cannons, missile launching systems, mortars, or a variety of non-lethal weapons.
It is, therefore, an extremely challenging task to engineer these intelligent vehicle systems. The 4D/RCS Engineering Guidelines address key software engineering issues that facilitate the intelligent vehicle systems lifecycle processes, including:
Reuse reduces system development costs. The 4D/RCS engineering guidelines can be leveraged in software reuse at several levels of detail.
Minimally, the definition of an RCS_Node provides control software designers with a framework for attacking the problem. The hierarchical decomposition guidelines help designers decide on how to decompose the problem and assign responsibilities to software modules. This could be considered reuse of software design and has a flavor akin to the use of architectural patterns [Gamma 1994]. Merely following the textual descriptions of what the main sub-components of an RCS_Node are, their responsibilities, and interrelationships provides initial assistance to designers and developers.
NIST and other organizations have been investigating means of enabling reuse of portions of 4D/RCS code. A Generic shell (see Section 5) provides generic computing models for 4D/RCS-based hierarchical control systems, including interfacing and communication. Developers apply the generic building blocks to all the control nodes and interfaces to build a skeleton for their control systems. The developers then embed the application-specific behavioral or processing algorithms into the skeleton and fill in the interprocess interface templates.
A number of software engineering tools have been developed for constructing generic shell modules. These range in degree of formality from C++ templates to Unified Modeling Language (UML) and Architectural Description Languages (ADL) [Huang et al. 01] [Messina 2000] [Dabrowski 1999]. A.J. Barbera and M.L Fitzgerald have applied a task decomposition based RCS approach to many industrial automatic systems and have developed a variety of tools for visualization of control system execution. [ATR 02]. A RCS tool developed by John Horst at NIST uses Control Shell [Horst 00]. Another RCS tool developed by Will Shackleford at NIST is written in Java. [Gazi01] Additional tools are being developed at Ohio State University using a LabView front end, [Gazi01] and by Pathway Technologies using MatLab as a front end [Anathakrishnan02]4
Tools that provide support for building, testing, and evaluating 4D/RCS-based systems are also being experimentally created [Balakirsky 2002]. The architect could use tools to create the initial specification for the system (hierarchy, timings, interfaces, etc.) and create the generic shell versions for the RCS_Nodes. A repository of 4D/RCS-compliant software components would then be available for developers to assemble directly or augment or customize. The tools would provide graphical and interactive means of building a system that is compliant with the reference architecture and that encourages (or enforces) reuse.
Interoperability and open systems
Complex, intelligent vehicle systems typically involve software components contributed by multiple development teams. Component and interface standards are crucial to system integration. 4D/RCS specifies nodes in terms of their functionality and interfaces. These present a comprehensive framework for developing and applying the standards, which, in turn, present open systems for components and subsystems to be easily integrated.
Large teams of software developers will have to work together. As technology
evolves and subsystems improve, it is desirable to be able to directly upgrade
components within the overall architecture to take advantage of improved capabilities.
Therefore, an architecture such as 4D/RCS is essential for defining the software
decomposition and interfaces that enable distributed development and component
1Some researchers prefer a clear distinction
between the terms information and knowledge. 4D/RCS, being a rich architecture,
supports both and adopts the concept of a smooth transition between information
24D/RCS terms. Will be defined in the document.
3The term level is used interchangeably with "4D/RCS hierarchical control level" throughout this document, unless explicitly stated otherwise.
4Commercial equipment and materials are identified in order to adequately specify certain procedures. In no case does such identification imply recommendation or endorsement by the National Institute of Standards and Technology, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.