Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004
An Introduction to Cognitive Architectures for Modeling and Simulation Randolph M. Jones Soar Technology, Inc. and Colby College
[email protected]
ABSTRACT Increasingly, across the broad spectrum of modeling and simulation, as well as in battlefield information and control systems, autonomous reasoning ability is required, and the “intelligence” developed and tested in simulation is migrating to real-world entities. Cognitive and agent architectures represent maturing computational approaches to intelligence that can provide robust, scalable, and realistic intelligence. This tutorial will provide an introduction to cognitive architectures, concentrating on production system computation. Examples will be presented from the ACT-R, GOMS, and Soar cognitive architectures. Differences and similarities in cognitive modeling and human behavior representation will be discussed. Attendees will also learn to recognize some of the requirements that suggest the need for a cognitive architecture as compared to other approaches and be better able to assess risks, costs, and benefits of different approaches.
ABOUT THE AUTHOR Randolph M. Jones, PhD is Chief Scientist at Soar Technology, Inc. and Assistant Professor of Computer Science at Colby College. He has been principal investigator for a variety of Soar Technology’s advanced R&D projects funded by ONR, ARI, DMSO, DARPA and other DOD agencies. He has previously held research positions at the University of Michigan, the University of Pittsburgh, and Carnegie Mellon University. His general areas of research include computational models of human learning and problem solving, executable psychological models, and automated intelligent actors for training and entertainment systems. He earned a BS in Mathematics and Computer Science at UCLA, and MS (1987) and PhD (1989) degrees from the Department of Information and Computer Science at the University of California, Irvine.
Page 1 of 7
Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004
An Introduction to Cognitive Architectures for Modeling and Simulation Randolph M. Jones Soar Technology, Inc. and Colby College
[email protected]
INTELLIGENT CONSRUCTIVE FORCES The DOD often relies on simulated environments for training and experimentation. For many applications, immersive systems provide high fidelity simulation of vehicles, weapons, and the environment, but the simulations are often isolated from the multi-player realities of operational environments. One solution to enriching these environments is to populate them with additional synthetic (i.e., computer-controlled) players and participants, commonly called constructive forces. Constructive forces come in many flavors, from simple models that require intensive human control to intelligent systems that generate realistic behaviors with high levels of autonomy, as well as many systems that fall between these two extremes. The conventional wisdom is that improved autonomy of constructive forces will save expense, especially for simulations requiring complex, detailed, realistic behavior among the trainee’s teammates and opponents. Technically, such autonomy requires the representation of intelligent decision making within the constructive force models. The level of autonomy and intelligence required is dictated by the demands of the application, and in turn determines the most appropriate implementation approach for the constructive forces. For the highest degree of intelligence and autonomy (e.g., Jones et al., 1999), we argue that the best suited implementation tools are cognitive architectures. These architectures are simultaneously psychological theories and programming environments for intelligent systems. The have behind them years of research into the foundations of intelligent reasoning and behavior. Their associated programming languages provide primitive structures and processes tailored to the efficient and intuitive design of intelligent systems. This presentation provides an overview of cognitive architectures and the philosophy behind them, examines case studies of some of the most prominent cognitive architectures, and attempts to characterize those situations in which developers of constructive forces should consider using a cognitive
Page 2 of 7
architecture instead of programming paradigm.
some
more
traditional
OVERVIEW OF COGNITIVE ARCHITECTURES Cognitive architectures generally describe behavior models at three distinct levels: the knowledge level, the symbol level, and the architecture level (Newell, 1990). The knowledge level refers to an external, descriptive view of an agent (Newell, 1982). Knowledge-level descriptions of intelligent systems often assume the principle of rationality, which says that if an agent has access to some knowledge that is relevant to the situation, it will use that knowledge to make the most advantageous decision. The knowledge level is a level for analysis; one observes the actions of an intelligent entity and makes assumptions about the knowledge it has (and does not) based on the observations. The knowledge level is important because it is the level at which humans generally describe behavior. Subject-matter experts (SMEs) use knowledge-level terms to describe what they do. Educators and trainers usually teach at the knowledge level. And deployed constructive forces are usually validated by comparing their behavior to knowledgelevel descriptions (to the extent they are validated at all). However, to build constructive forces that actually generate behavior, their knowledge must be encoded in some form that can be interpreted and executed by a computer. Traditional cognitive architectures dictate that knowledge is encoded in a symbol system, which provides the means for universal computation (Newell, 1990). The symbol level is the level in which the “knowledge” of an intelligent system is represented in a structured, executable format. While it is common to think of an agent as having knowledge, in reality every intelligent system (human or otherwise) has only some representation of knowledge. The knowledge representations of the symbol level must be accessed, remembered, constructed, acted on, etc. before an observer can ascribe knowledge to the agent. The fixed mechanisms and representations that are used to
Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004
realize the symbol system comprise the cognitive architecture. An architecture enables the distinct separation of content (the computer program) from its processing substrate. Thus, the primary differences between various constructive forces or models of human behavior consist of differences in the encoding of knowledge for their various applications. From a computationally theoretical perspective, every cognitive architecture provides equivalent computational power to standard programming languages. Thus, cognitive architectures and traditional programming languages should be sufficient for any application requiring intelligent behavior (assuming intelligence can be captured in computational terms). However, performance efficiency and the ease with which particular algorithms can be encoded and retrieved also impact the sufficiency of the architecture for producing intelligent behavior in a particular application. Thus, the choice between cognitive architectures and more traditional programming paradigms is not to be made based on theory, but on pragmatics. Which formalism provides the best substrate for encoding and maintaining large, knowledge-based systems? Finally, while symbol systems may attempt to approximate it, they will necessarily always fall somewhat short of the perfect rationality desired in the knowledge level. One can think of the way in which a system falls short of the knowledge level as its particular “psychology”. It may not act in time to appear to have the knowledge, it may use some fixed process for decision making that sometimes leads to a failure to consider some relevant knowledge, etc. However, when it comes to constructive forces, this fact can be an advantage. Especially for applications that require human-like levels of flexibility, autonomy, and intelligence, it may also be desirable to have constructive forces that do not all behave identically to each other. Rather, for realistic modeling, we sometimes want each individual force model to have its own “psychology”, and cognitive architectures provide the appropriate framework for defining such variability.
those have to do with each architecture’s associated psychological theory. Often, when using these architectures to build intelligent systems, the precise psychological theory is not as important as the symbollevel specification of knowledge that generates humanlike behavior. From the applications perspective, various architectures can be seen to share a number of commonalities. Before examining this generalized view of cognitive architectures, we will outline some of the most prominent current architectures to provide the flavor of some of their philosophical and theoretical differences. GOMS GOMS (Goals, Operators, Methods, and Selections) was developed from a psychological perspective as an analysis tool mostly for human-computer interaction (Card et al., 1983). GOMS formalizes many details of high-level human reasoning and interaction. Although GOMS has so far not been used to develop large-scale systems, it has been used to represent the human knowledge necessary for performing many tasks, including complex human activity. The representation and process regularities that GOMS has identified are critical for intelligent systems that encode human performance and interaction knowledge. GOMS systems explicitly encode hierarchical task decompositions, starting with a top-level task goal, plus a number of methods, or plans, for achieving various types of goals and subgoals. Each goal’s plan specifies a series of actions (called operators) invoking subgoals or primitive actions to complete the goal. Selection rules provide conditional logic for choosing between plans based on the agent’s current set of beliefs. GOMS is a high-level framework, realized in a number of individual implementations. Early implementations of GOMS (as with many early cognitive architectures) relied on hand-crafted representations of problems and situations, instead of being situated in interactive environments, such as DOD simulation systems. However, many of the more recent implementations contain integration subsystems to interact with realistic environments, including running user-interface models. These variations allow GOMS to provide increasingly capable constructive forces that explicitly model perception and action.
ARCHITECTURE CASE STUDIES Soar There are a number of existing cognitive architectures, each having their own points of emphasis and theoretical underpinnings. These architectures contain important distinguishing features, but for the most part
Soar has roots in cognitive psychology and computer science, but it is primarily a functional approach to encoding intelligent behavior (Laird et al., 1987). The
Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004
continuing thread in Soar research has been to find a minimal but sufficient set of mechanisms for producing intelligent behavior. An additional hallmark of efforts with Soar has been to focus from the start on the principled integration of representations and processes. These goals have resulted in uniform representations of beliefs and knowledge, fixed mechanisms for learning and intention selection, and methods for integrating and interleaving all reasoning. Soar’s theoretical principles are based in part on assumed high-level constraints on intelligent behavior. Foremost among these are the problem space hypothesis (Newell, 1982) and the physical symbol systems hypothesis (Newell, 1980). Problem spaces modularize long-term knowledge so that it can be brought to bear in a goal-directed series of discrete steps. The problem space hypothesis assumes rationality the rationality of the knowledge level, but it is certainly possible to build Soar systems that behave irrationally (by programming them with bad knowledge). The physical symbol-systems hypothesis argues that any entity that exhibits intelligence can be viewed as the physical realization of a formal symbolprocessing system. The physical symbol systems hypothesis led to Soar’s commitment to uniform representations of knowledge and beliefs. For example, Soar’s design encourages the development of models and knowledge representations that allow the same knowledge to be used for planning as for execution. Uniform knowledge representations also allow certain reflective capabilities, where a model can create its own internal representations that mimic the representations it might see from its perceptual systems (or supply to its motor systems). While Soar imposes strong constraints on fundamental aspects of intelligence, it does not impose functionally inspired high-level constraints (as, for example, GOMS does in its use of hierarchical goal decomposition). Thus, Soar is a somewhat lower level framework for reasoning than GOMS. In theory, GOMS principles could be encoded into systems that use Soar as the implementation architecture. ACT-R ACT-R (Anderson & Lebiere, 1998) is a similar level of cognitive architecture as Soar, and it has its roots in the same early research sessions at Carnegie Mellon University that ultimately led to Soar. However, where Soar adopts a primarily functional approach, ACT-R could perhaps best be described as a full-
fledged psychological theory. Of the most prominent cognitive architectures, ACT-R takes most seriously the interaction of a detailed model of human memory (and its limitations) in concert with a theory of human knowledge (where GOMS and Soar have their focus). The family of ACT architectures has undergone a series of evolutions, each version building on the lessons of the previous versions. The most recent version, ACT-R, combines two primary types of symbol-level specifications of long-term knowledge (labeled procedural and declarative) with constraints on memory (through the use of restricted buffers) and a detailed quantitative model of human memory. This additional machinery allows developers (often researchers in psychology and cognitive science) to develop very high fidelity models of a wide variety of human skills, behaviors, and learning phenomena. However, ACT-R has also been used to develop constructive forces for military simulations. Each version of the ACT architecture has been fundamentally grounded in the desire to emulate human behavior faithfully at a fairly low level of detail. The computational mechanisms are informed by psychological data on execution times, errors, and behavior of memory retrieval, skilled and novice behavior, and learning. Unlike the Soar effort, which attempts to compose all intelligent behavior from a minimal set of mechanisms, ACT-R builds in a number of different mechanisms, so that models can focus on using the best set and producing behavior based on mechanism interactions. Because of this design philosophy, it can be argued that some of the process implementations look more descriptive than generative, but you could reasonably argue this about any cognitive architecture, depending on the level of abstraction you analyze. A GENERALIZED VIEW Despite the differences in design and implementation, intelligent systems built within each of these architectures all assume a similar set of basic representations and decision processing. Abstracting away implementation details along with some of the theoretical differences, we can summarize the basic decision cycle of each cognitive architecture in the following terms: 1. 2.
Use sensory systems to create a primitive representation of the current situation. Elaborate the primitive representation by creating (or retrieving) additional elements
Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004
3.
4. 5.
6.
that produce a set of beliefs or interpretations about the current situation (possibly simultaneously abandoning previous beliefs). Use the current situation interpretation to identify, retrieve, and select a goal to pursue (possibly simultaneously abandoning a previous goal). Identify, retrieve, and select a primitive action relevant to the current situation and goal. Execute the selected action (could be an external action, a memory retrieval, a belief annotation, etc.). Return to Step 1.
It is important to note that this is not the same decision cycle you see in traditional programming languages. If it were, we would have to question why we need cognitive architectures at all. This decision cycle includes important features that help define the circumstances under which we should consider using cognitive architectures or some other approach for constructive forces. In support of this basic decision cycle, each architecture also provides direct support for a number of different types of primitive data structures, detailed below. Beliefs From primitive perceptual elements, an agent creates a (often elaborate) set of beliefs, or interpretations of the environment. Belief representation is perhaps one of the most important distinguishing features between cognitive architectures (and other intelligent agent frameworks) and standard software paradigms. Before an intelligent system can get around to making choices about goals and actions, it must spend significant effort creating stable representations of its understanding and interpretation of the environment. Using the terminology of reason maintenance systems (Forbus and deKleer, 1993), beliefs can be classified as either entailments (sometimes called justified beliefs) or assumptions. Entailments remain in memory only as long as they are (logically) grounded in perceptual representations and assumptions. Assumptions, by definition, receive a high level of commitment and remain in memory, independent of their continuing relevance to−and logical consistency with−the external environment. Assumptions remain asserted until the agent explicitly removes them. Assumptions are necessary because not all beliefs can be grounded in current perception. For example, if a model needs to remember an object no longer in the field of view, then
it must commit to remembering (or “assuming”) that the object still exists. Active Goals A hallmark of intelligent behavior is the ability to commit to a particular set of concerns and then pursue them (Bratman, 1987; Newell, 1990). Cognitive architectures support explicit representation of the goals that a model has committed to pursue. Each architecture provides mechanisms for selecting which goal or goals should be active each time it executes the decision cycle. Importantly, the architectures also allow appropriate dynamic deactivation of goals. This is an extremely important aspect of intelligent behavior, because it allows systems to organize their behavior rationally (around goals) but simultaneously to be reactive and adaptive in response to a changing environment. Actions An agent must eventually commit to some type of action relevant to its active goals. There are generally three classes of actions: execute an output command, update the belief set, or commit to a new goal (or desire). Cognitive architectures define operators as the atomic level of action. Because operators are primitive steps, and they can be loosely associated with different goals, they can compose flexibly into rich action sequences. This is again a key aspect of intelligent systems, because we generally require such systems to generate smooth and appropriate flows of responses, instead of allowing them to get locked into scripted sequences and canned responses. The dynamic composability of actions in the context of goals is another key design feature that sets cognitive architectures apart from traditional programming languages. ALTERNATIVE APROACHES TO CONSTRUCTIVE FORCES The primary alternative approach to building constructive forces is to use traditional procedural programming languages, often loosely couched within a finite state machine paradigm. True finite state machines do not allow variables to encode a system’s state information, so remaining completely faithful to the theoretical paradigm would results in massive and unwieldy situation representations and program structures. As a compromise, this programming paradigm uses “states” as ways to usefully compartmentalize the context for various types of
Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004
actions, and then allows arbitrary representation of data (using traditional program variables) within each state. This also allows some amount of communication of information across states. In this approach to programming, states can be considered as somewhat akin to goals in cognitive architectures. They are generally individual symbols or flags that provide a context for the current set of actions that the model will consider generating. The first major difference is that finite-state approaches generally associate with each state a procedure or script of (usually conditional) actions to execute while in that state. Procedures and scripts are not necessarily a bad thing. They have proven useful for decades as an efficient way for software engineers to organize their representations of action and control within computer program. The tradeoff is that procedures and scripts are generally not reentrant. That is, it is difficult for a system to pick up in the middle of a script, or opportunistically skip steps in the procedure if the situation warrants it. Whether this is a good or bad thing again depends on the particular application. If the desired behavior of the constructive force model is to be flexible and adaptive, and to flow appropriately in the face of dynamic situation changes, then the finite-state approach could be overly rigid and inflexible. The second major difference between the finite-state approach and cognitive architectures also has to do with flexibility and composability of behaviors. Finite state machines include a transition function that tells the system when to move from one state to the next. One can think of this as a sort of meta-script or metaprocedure for the model’s behavior. Again, the transition from one state to another is akin to the portion of a cognitive architecture’s decision cycle that deactivates old goals and activates new ones. But where state transitions are a function of the current state plus some state information, goal transitions are a function of the ever-changing situationinterpretation structures maintained by an intelligent behavior model. While it would certainly be possible to mimic such situation-interpretation representation within state variables, it would require (hopefully standardized) extra computational machinery to do so efficiently and in a consistent way. This is precisely the type of machinery that is built into cognitive architectures from the ground up. WHEN TO USE COGNITIVE ARCHITECTURES
When considering which technology to use to build a constructive force model, it is important to analyze the requirements on entity behavior for that application. However, additional important issues are the cost of development and maintenance of the model. Traditional software approaches are associated with mature software engineering paradigms, and can be supported by powerful development environments. There is also a relatively large pool of software engineers that is competent to built finite-state models. The primary tradeoff comes in the form of relatively inflexible, scripted actions for the behavior models, as well as the tendency to focus on relatively small sets of behavior that can be encapsulated into manageable state machines without becoming an onerously tangled mess of interacting units. In contrast, there is increasing demand for highly realistic and human-like behavior from constructive force models. It is certainly feasible, in the long run to engineer finite-state approaches so they can do all of the necessary belief maintenance, situation interpretation, goal management, task switch, and flexible response generation required for intelligent behavior. But the finite-state formalism comes out of a theoretical computer science tradition, which has been adapted for traditional, procedure-oriented software engineering. As requirements grow and systems become larger, the incompatibility of the approaches will exacerbate, leading to systems that are expensive to develop and difficult to maintain. Certainly there will be a middle ground, or transition area, where it might be appropriate to use finite-state approaches in order to avoid the extra investment in learning a new architecture. However, for the largest systems that see increasing demand, the most costeffective approach for both development and maintenance will be to use software architectures that have been engineered to support precisely the knowledge-level concepts and behaviors that we want to see in intelligent constructive forces. REFERENCES Anderson, J. R., & Lebiere, C. (1998). The atomic components of thought. Mahwah, NJ: Lawrence Erlbaum Bratman, M. E. (1987). Intentions, plans, and practical reason. Cambridge, MA: Harvard University Press. Card, S., Moran, T., and Newell, A. (1983). The psychology of human-computer interaction. Hillsdale, NJ: Lawrence Erlbaum.
Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2004
Forbus, K., & deKleer, J. (1993). Building Problem Solvers. Cambridge, MA: MIT Press. Jones, R. M., Laird, J. E., Nielsen, P. E., Coulter, K. J., Kenny, P. G., & Koss, F. V. (1999). Automated Intelligent Pilots for Combat Flight Simulation. AI Magazine, 20(1), 2742. Laird, J. E., Newell, A., & Rosenbloom, P. S. (1987). Soar: An architecture for general intelligence. Artificial Intelligence, 33(3), 1-64.
Newell, A. (1980). Physical symbol systems. Cognitive Science 4:135-183. Newell, A. (1982). The knowledge level. Artificial Intelligence, 18(1), 82-127. Newell, A. (1990). Unified Theories of Cognition. Cambridge, Massachusetts: Harvard University Press.
