The Extended OODA Model for Data Systems Elisa Shahbazian Lockheed Martin Canada 6111 Royalmount Ave. Montréal, QC, Canada H4P 1K6 dale.blodgett@lmco.com Dale E. Blodgett Lockheed Martin Canada 6111 Royalmount Ave. Montréal, QC, Canada H4P 1K6 dale.blodgett@lmco.com Paul Labbé Defence Research Establishment Valcartier 2459 Blvd Pie XI Nord Val-Bélair, QC, Canada G3J 1X5 paul.labbe@drev.dnd.ca Abstract Various models have been created to categorize, structure and organize the description of Data (DF). One common problem in these models is the difficulty in depicting multiple concurrent interacting DF processes in different phases of information processing, and the continuous and often ad hoc interaction between functions and processes. This paper proposes an approach, called the Extended OODA model, which is derived from some of the existing models, but provides a mechanism to present interactions and concurrency. A brief overview is given for the models upon which the Extended OODA model was derived. A detailed description of the Extended OODA model is provided, along with an explanation of its relationship to its predecessors, and how it overcomes certain deficiencies of them. Finally, the use of the Extended OODA model is demonstrated by applying it to Command and Control for the HALIFAX Class Frigate. Keywords: Command and control, data fusion, model. 1 Introduction All systems that must make decisions using multiple observations and existing/accumulated knowledge, while exploiting the synergy between these, perform Data (DF). DF is a very diverse field which applies methods of mathematics, probability, operational research, industrial engineering, theory of computation, mathematics of computing, statistics, communication and decision theory, fuzzy logic, uncertainty management, estimation theory, image processing, digital signal processing, computer science and artificial intelligence, etc. in its functions. Models are created to categorize, structure and organize the DF discipline. These models identify the processes, functions, and techniques applicable to DF as information flows from the sources to the human operator. Different models group and map the processing and functions that combine the observations and knowledge, perform reasoning and make decisions differently. There is one main aspect of a large DF based system that has been most difficult to convey within these models. It is the possibility of multiple concurrent interacting DF processes in different phases of information processing within a system and the continuous and often ad hoc interaction between functions and processes within it. This paper proposes an approach, called the Extended OODA model, derived from some of the existing models, which provides a mechanism to present such interactions and concurrency. The following sections first provide an overview of existing models, then describe the specifics of our model. 2 Background The following models for DF have been proposed by various authors: 1) The JDL Model 2) The Boyd Control Loop 3) The Waterfall Model 4) The Intelligence Cycle 5) The Dasarathy Model 6) The Omnibus Model. The detailed description and mapping of these models are provided in [1]. A brief overview of the models that can be considered the predecessors of our approach, namely the JDL, Boyd Control Loop, and the most recent, the Omnibus model, follows. 2.1 The JDL Model Initially most of the research in the domain of DF was done for defence applications, and in more recent years this technology was applied for other commercial applications. The most recent revisions to the JDL DF model have reduced the defence context from the definitions [2, 3] of the processes that comprise this model. Level 0: Sub-Object Data Assessment Estimation and prediction of signal/object observable states on the basis of pixel/signal level data association and characterization. Level 1: Object Assessment Estimation and prediction of entity states on the basis of observation-to-track
association, continuous state estimation (e.g., kinematics) and discrete state estimation (e.g., track ID). Level 2: Situation Assessment Estimation and prediction of relations among entities to include force structure and cross force relations, communications and perceptual influences, physical context, etc. Level 3: Impact Assessment Estimation and prediction of effects on situations of planned or estimated/predicted actions by participants; to include interactions between action plans of multiple players (e.g., assessing susceptibilities and vulnerabilities to estimated/predicted threat actions given one s own planned actions). Level 4: Process Refinement Adaptive data acquisition and processing to support mission objectives (an element of resource management (RM)). Figure 1 shows the data flow between the DF levels, as described above. Situations Level 2 Situation Assessment Objects Level 1 Object Assessment Signals/Features Level 0 Sub-Object Assessment Measurements Situations Plans Level 3 Impact Assessment Plans Situations Plans Level 4 Process Refinement (Resource Mgmt) Plans Situations Objects Signals/Features Resources Figure 1: Logical flow across the DF Levels of JDL Model With the JDL model, the RM portion that deals with impacting the environment (rather than information sources and the DF processes) is considered to be outside of the DF domain. Within the JDL model, the DF levels are presented as a sequential flow. In reality there is a lot of parallel/concurrent activation of the functions within a DF system in all levels, and more significantly for levels above 0 and 1. 2.2 The Boyd Control Loop The Boyd control loop [4] also called the OODA loop, consists of four phases: Observe, Orient, Decide and Act. Mapping of the OODA loop to JDL DF levels is shown in Figure 2. Environment, Sensors and Actuators Level 0 Level 1 Observe Act Level 4/RM Plan Implementation Orient Decide Level 2 Level 3 Level 4/RM Plan Creation Figure 2: OODA Loop and mapping to JDL DF Levels This mapping is currently used by many Canadian DF researchers, however not all authors agree with this mapping of the JDL with OODA [1]. The width of the arrows in this figure also indicates the amount of the data flow in the loop. As data gets further refined in the loop (becoming information), the amount of data passed to the next phase (or DF level) decreases. The attractiveness of this model is the fact that it closes the loop, acting on its environment and sensors, manifesting the cyclic nature of the DF. It lacks the ability to show the impact of the Decide and Act phases (level 4) on the other phases of the loop. It also implies a sequential execution of the phases. It is easy to imagine an OODA loop (or a few OODA loops) within every phase of this loop performing reasoning to assess different specific information. It is also possible to imagine that these loops act on each other. 2.3 The Omnibus Model The Omnibus model was introduced by Bedworth and O Brien [1]. The Omnibus model flow chart is shown in Figure 3. Soft Decision Feature Sensor data Pattern processing Feature Extraction Orient Decision making Context processing Decide Observe Act Signal Processing Sensing Control Resource tasking Figure 3: Omnibus model data flow Hard Decision Sensor Management This model is built around the OODA loop and tries to unify a number of earlier models. The authors propose to use the model in two ways:
1) To characterize and subdivide the overall system with the aim to provide an ordered list of tasks 2) To use the same structure to organize the functional objectives of each such task. The main consequence of this model is that it makes the loop within the loop concept explicit and it also has no defence context. The drawback of this model is that it combines too many concepts (e.g., DF model, level of processing, architecture), which may cause the misconception that a specific architecture (soft decision, hard decision) is appropriate for only a certain specific phase of the loop. 3 The Extended OODA Model The Extended OODA model for DF systems developed at Lockheed Martin Canada (LMC) synthesizes some of the particularly useful aspects of the models described in section 2, but provides a mechanism for multiple concurrent and potentially interacting DF processes. The fundamental aspects of the Extended OODA model are depicted in Figure 4. OBSERVE System... Function A Function B Function C Function N subsequent OODA phase, while the Act phase acts not just on the environment, but may also directly influence functions in any of the OODA phases (and is the mechanism by which the results of the OOD phases will affect other OODA phases e.g., implementation of Level 4 DF actions). The decomposition of functions at each node should respect these properties of the model. This relationship of this model to its predecessors is as follows: 1. On the high level it is consistent with the OODA model. It closes the loop between the decision making and its environment. 2. It is consistent with the increasing level of abstraction for information processing in each level of the JDL model, and also provides for process refinement (Level 4 DF) to Act on all phases of decision making. 3. This model also provides the loop within the loop capability of the Omnibus model. On the other hand, it overcomes certain difficulties of its predecessors in the following way: 1. It provides for multiple interacting OODA loops as well as process refinement multiple loops through the Act phase impacting each phase of the decision making Environment ORIENT DECIDE ACT 2. It includes the decision making for the RM capability for the DF system to interact with its environment, as well as provides means to express the interactions between the DF levels. Figure 4: Extended OODA Model for Data A system using DF for decision making is decomposed into a meaningful set of high-level functions (Figure 4 shows a set of N such functions). These functions are examined in terms of the Observe, Orient, Decide, and Act decision loop that constitute the OODA model. Each function can be further decomposed and evaluated with respect to each OODA phase. Figure 4 shows a node for each function at its relevant OODA phases. For instance, Functions A and N indicate subsequent decomposition and evaluation at each OODA phase. However, as indicated by Functions B and C, only partial or single OODA phases may be relevant. As shown in Figure 4, the model has properties such that the environment provides input to functions in the Observe phase, while it is acted upon by functions in the Act phase. Furthermore, the functions of the Observe, Orient and Decide phases directly influence only the functions in the 3. The model permits any implementation, fusion architecture, decomposition of the functionality, etc. and different functions can be designed using a different approach, as appropriate to the decision making requirements of the function. The Extended OODA model is amenable to a functional decomposition of the System via Vineberg s user functions [5], which are the highest level functions in a layered system architecture, and are upwards looking to the user, directly supporting a user mission. Subsequent decomposition at each node of the relevant OODA phases proceeds through more and more levels of complexity and detail that tend to eventually be oriented to lower levels (e.g., system, applications, utilities, etc.) in a layered system architecture. The Extended OODA model thereby provides the framework for structuring and understanding the specification of, and interconnections between, the fundamental components of a system, and facilitates the
transition to actual physical architectures and system implementation. In addition, by representing the functional decomposition with respect to the OODA phases in this manner, the context dependencies of functions (e.g., mission/goals, state under which system is used, etc.) can be introduced and easily understood with respect to the OODA phases. The other interesting aspect of this model is the fact that one does not need to fully define the complete system functionality and design. One can do it incrementally with minimal impact to the already defined and designed functionality. The next section illustrates how the Extended OODA model can be applied to Command and Control (C2) for the HALIFAX Class Frigate. 4 C2 for the HALIFAX Class Frigate The Combat System of the Canadian HALIFAX Class Frigate is composed of weapon systems, sensor systems, navigation systems, information systems, support systems, and the command and control system (CCS). The CCS lies at the heart of the Combat System, and is an integrated combination of people, procedures, hardware, and software used to enhance the ability of the personnel performing C2. The functional decomposition of C2 for the HALIFAX Class Frigate, using the Extended OODA mo del described in section 3, is given if Figure 5. OBSERVE ORIENT DECIDE ACT UWW Command & Control Data Exchange / [ Fig. 6] [ Fig. 10] [ Fig. 7] [ Fig. 8] [ Fig. 9] [ Fig. 11] [ Fig. 12] [ Fig. 13] Navigation Platform Support Readiness System Monitoring Configuration Command Coordination Office / Admin Figure 5: C2 for the HALIFAX Class Frigate In Figure 5, C2 for the HALIFAX Class Frigate was decomposed into its primary user-oriented functions: Above Water Warfare (), Under Water Warfare (UWW), Data Exchange and, Platform Support, and Command Coordination. Such functions are a convenient starting point for a top-down decomposition since they are essentially independent of implementation details. Although a logical distinction is made between these user functions, they may be wholly or partially combined during the physical implementation of the C2 system they represent (e.g., combining some aspects of and UWW DF functionality in one algorithm, software/hardware module, or database). The function is a user function that incorporates all activities, including both Anti-Air Warfare (AAW) and Anti-Surface Warfare (ASuW). The UWW function is a user function that incorporates all UWW activities, including both Anti-Submarine Warfare (ASW) and Mine Warfare. The Data Exchange/ function is responsible for sending and receiving all data and communications between ownship and external sources/destinations, and where required other subsystems of the Combat System. It includes the infrastructure and systems that support various modes of data exchange/communications, as well as the requisite functionality to use and manage these systems. The Platform Support function encompasses systems and services that provide support to one or more of the primary C2 user functions identified in Figure 5. These activities include Navigation, Readiness Monitoring, System Configuration, and Office/Administration. The Command Coordination function enables the platform for specifying and executing command direction as to the use of the Combat System, and controlling the ship s and Force s movements. It also includes the mechanisms for initializing and changing the CCS mode of operation. Figure 5 also shows the nodes (with respect to the OODA phases) where subsequent functional decomposition is relevant. The appropriate decomposition for the and Data Exchange/ functions is presented in the figures indicated in Figure 5. Note that to the level considered in this paper, the decomposition for UWW is very similar to (in the case of the HALIFAX Class Frigate), so is not presented. The remaining nodes whose decompositions are not presented are for functions that involve C2 processes that in general do not directly perform DF, but rather support, coordinate, provide input or use the results of DF. Figures 6 13 show the functional decomposition with respect to the OODA phases according to the Extended OODA model, for the nodes indicated in Figure 5. The depth of the decomposition was aimed at providing detail for functionality relevant to the COMDAT I DF technology insertion program being conducted for the HALIFAX Class Frigates. The functions defined in the functional decomposition need not be implemented separately or independently. Upon actual implementation in software/hardware modules, various functions may be combined or associated with a single module, or the capabilities of a given function may be distributed in whole or in part to several different modules.
A detailed discussion of all the components of the functional decompositions presented in Figures 6 13 is beyond the intended scope and relevance of this paper. Such a discussion is provided in [6]. Instead, a brief overview of each functional decomposition figure will be provided, along with comments about the relevance to DF. subsequent decision support; and perform behaviour analysis. The Refine Portion of MTP function resolves issues resulting from Assess Portion of MTP. The Situation Interpretation function The functional decompositions of in Figures 6 9 (along with analogous decompositions for UWW not shown) constitute the primary explicit DF processes for this system. Figure 6 shows the functional decomposition of for the Observe phase of OODA. Situation Assessment Assess Portion of MTP Refine Portion of MTP Situation Interpretation Situation Projection Monitor Situation Assess Neutral Tracks Coordinate with UWW Situation Assessment Compile Portion of MTP Produce Portion of MTP Maintain Portion of MTP Sensor Data Merge Non-Organic Data Merge Relevant UWW Data Compile Portion of MTP History Ownship Sensor Data Sensor Data of TDL Data Figure 6: Functional decomposition for -Observe The -Observe decomposition concerns the compilation of the Maritime Tactical Picture (MTP), which incorporates both organic (local and tactical data link (TDL) data) and non-organic data. It thereby involves Level 0 and Level 1 DF processes. The Sensor Data function handles the organic data, while the Merge Non- Organic Data function handles the non-organic data (e.g., JMCIS/GCCS type wide-area picture data). Note that the Produce Portion of MTP function also decomposes into the Merge Relevant UWW Data, which introduces data produced via the UWW function in Figure 5. Finally, the introduction of distinct functions for dealing with local, TDL and non-organic data is intended to accommodate potential differences in representing and implementing the DF processes associated with these different types of data. Figure 7 shows the functional decomposition of for the Orient phase of OODA. The -Orient decomposition concerns situation assessment (i.e., Level 2 DF) and threat assessment (i.e., Level 3 DF) processes for. Figure 7 shows how each of these is further decomposed in consideration of C2 for the HALIFAX Class Frigate. The Assess Portion of MTP function monitors the portion of the current MTP to: examine track attributes from Level 1 DF for incompleteness, contradiction or ambiguity; establish relationships amongst entities in the MTP; compute kinematic information (e.g., mean line of advance, closest point of approach, etc.) for Threat Assessment Determine Current Threats Determine Potential Threats Determine Relative Threat Numbers Stabilize Threat Evaluation Coordinate with UWW Threat Assessment Figure 7: Functional decomposition for -Orient generates and validates hypotheses about the current tactical situation to explain the presence of perceived entities, and determine the intent of enemy or unknown tracks. The Situation Projection function generates hypotheses about future states of the tactical situation. The Monitor Situation function stores expectancies (such as hypotheses about future events and anticipation of kill assessments) and monitors the situation for discrepancies between expectancies and the currently perceived state of the world. The Determine Current Threats function identifies the tracks that are to be processed for relative threat ranking. The Determine Potential Threats function predicts potential threats. The Determine Relative Threat Numbers function considers the lethality, opportunity and intent of the threats to form the basis of a threat ranking, while the Stabilize Threat Evaluation function attempts to bring stability to the threat ranking. Note also the interaction and coordination with analogous UWW situation and threat assessment. Figure 8 shows the functional decomposition of for the Decide phase of OODA.
Data Exchange/ Resource Management Plan Weapon Engagements Receive Other Units MTP Data/ Control of MTP Data/ from Other Units Plan Level 4 Data Process TDL Data/ Figure 8: Functional decomposition for -Decide The -Decide decomposition concerns the planning phases of RM. It includes the planning for Level 4 DF. These plans take account of the results of -Observe and -Orient, and determine and schedule an action to be implemented by -Act. Figure 9 shows the functional decomposition of for the Act phase of OODA. Implement Resource Management Plans Provide Portion of MTP Information to Data Exchange/ Systems Implement Weapon Engagement Plans Implement Level 4 Data Plans Figure 9: Functional decomposition for -Act The -Act decomposition concerns the implementation of actions determined and scheduled according to - Decide. It includes the actions determined for Level 4 DF. Various methods or agents may be used to effect a scripted action on a system resource (e.g., weapon or sensor subsystem, or even other functions). The Provide Portion of MTP Information to Data Exchange/ Systems function represents a logical placeholder for the output of MTP data to the Data Exchange/ user function. The input of data to the MTP is implicitly imbedded within the functions represented in -Observe. The Data Exchange/ function, although for the most part not explicitly a primary DF process in C2 for the HALIFAX Class Frigate, does provide critical support for these DF processes and is fundamentally connected to them. For this reason, the functional decompositions of Data Exchange/ are presented in Figures 10 13. Figure 10 shows the functional decomposition of Data Exchange/ for the Observe phase of OODA. Receive Other Units Non-MTP Data/ Receive Requests for Data/ Determine Data/ Capacity Demands Process Non-TDL MTP Data/ Receive Information and Requests for Identity Exchange Figure 10: Functional decomposition for Data Exchange/ -Observe The Data Exchange/-Observe decomposition concerns receipt of data/communications information from external sources, receipt of requests to send information to external sources, and observations about capacity and demands on the data/communications infrastructure. The functions shown in Figure 10 are selfexplanatory. Figure 11 shows the functional decomposition of Data Exchange/ for the Orient phase of OODA. Data Exchange/ Assess Data Exchange/ Predict Data Exchange/ Needs and Performance Monitor Data Exchange/ Figure 11: Functional decomposition for Data Exchange/ -Orient The Data Exchange/-Orient decomposition concerns assessing, predicting and monitoring capacity and demands on the data/communications infrastructure. The Assess Data Exchange/ function examines capacity and demands, looking primarily for problems. The Predict Data Exchange/ Needs and Performance function generates hypotheses about future capacity and demands. The Monitor Data Exchange/ function stores expectancies about future capacity and demand, and looks for discrepancies between expectancies and the currently perceived state of data exchange/communications. Figure 12 shows the functional decomposition of Data Exchange/ for the Decide phase of OODA.
Data Exchange/ Plan & Schedule for Routine Information Exchange Plan & Schedule Responses to Special Requests for Data Exchange/ Plan & Schedule Support Functions Plan Ship Data Recording and Analysis Support Coordinate All Data Exchange/ Plans & Schedules Figure 12: Functional decomposition for Data Exchange/ -Decide The Data Exchange/-Decide decomposition concerns determining and scheduling actions for the exchange of data/communications using the data/communications infrastructure, as well as coordinating the various planning activities. The functions shown in Figure 12 are self-explanatory. Note that routine information exchange covers all periodic or predictable exchanges (e.g., TDLs), while responses to special requests refers to requests for information that were not anticipated or routinely accommodated. Figure 13 shows the functional decomposition of Data Exchange/ for the Act phase of OODA. Data Exchange/ Implement Routine Information Exchange Implement Responses to Special Requests for Data Exchange/ Implement Support Functions Implement Ship Data Recording and Analysis Support Coordinate the Implementation of All Data Exchange/ Actions Figure 13: Functional decomposition for Data Exchange/ -Act The Data Exchange/-Act decomposition concerns the implementation of the actions determined and scheduled according to Data Exchange/- Decide, as well as coordinating the various implementation activities. between the decision making and its environment. It is consistent with the increasing level of abstraction for information processing in each level of the JDL model, and also provides for process refinement (Level 4 DF) on all phases of decision making. It also provides the loop within the loop capability of the Omnibus model. However, the Extended OODA model also overcomes certain difficulties of its predecessors, particularly in its ability to handle interacting processes. This model provides a framework that facilitates the transition to physical architectures and system implementation. The model also accommodates an incremental build of system functionality and design, with minimal impact to the existing specification. Finally, as demonstrated, the Extended OODA model can be successfully applied, and indeed is useful for representing and understanding Command and Control for the HALIFAX Class Frigate. References [1] M. Bedworth and J. O Brien, The Omnibus Model, a new model of DF?, IEEE AES Systems Magazine, pp. 30-36, April 2000. [2] A. Steinberg, C. Bowman, and F. White, Revisions to the JDL DF Model, SPIE Vol 3719, pp. 430-441, 1999. [3] Alan N. Steinberg, New developments: FUSIAC and JDL DF Model revision, NASA and Data Mining Conference, 9-10 July 1999. [4] J. Boyd, A discourse on winning and losing, Maxwell AFB lecture, 1987. [5] M. Vineberg, A proposed user-centric battle management system, Proceedings of the Twelfth Ship Control Systems Symposium, 19-21 October 1999. [6] D. Blodgett, COMDAT I Command and Control Functional Architecture, Combat System and Engineering Support Task 0008, No. 652000801, pending April 2001. 5 Conclusions The Extended OODA model decomposes a system using DF decision making into a meaningful set of high-level functions, which are examined in terms of the Observe, Orient, Decide, and Act phases of the OODA model. Each function can be further decomposed and evaluated with respect to each OODA phase. The Extended OODA model is consistent with the OODA model, and closes the loop