|
|
| Project Metadata | Keywords | |||||||||||||||||||||||||||||||||||||||||||
|
|
Support the Naval Research Laboratory in developing high-level requirements and design for a DIME/PMESII model or suite of models that would be available to the government for review and validation without proprietary restrictions.
The general DIME/PMESII background can be found in the discussion of Analytical Tools for OOTW. The historical developments can be organized into three periods: the Academic Period, the Early DoD Period, and Current Period.
|
|
The period from 1992 (and before) up to 1996 is the “Academic” period. During this time most of the interest in what we now call DIME/PMESII operations belonged in the academic world. Four tools have been chosen to represent the activities during this time, the Kansas Events Data System (KEDS) and the Protocol for the Assessment of Nonviolent Direct Action (PANDA). KEDS is an organized collection of events that are relevant to various instabilities, with the organization aimed at understanding the implications of the events. PANDA was the beginning of an automated tool to collect the events from electronically published news sources. PANDA was expanded by its inventors, Virtual Research Associates (VRA) into Integrated Data for Events Analysis (IDEA) during the next period. The Center for Computational Analysis of Social and Organizational Systems (CASOS) created the dynamic social networks model, Organizational Risk Analyzer (ORA). In 1998, DoD became interested in it. The Synthetic Environments for Analysis and Simulation (SEAS) model was begun during this period as an academic project. Later, DoD became interested in it. Simulex describes SEAS on its website http://www.simulexinc.com/products/case_studies.
The SEAS-VIS model is a representation of the Institutions, Organizations, Leaders, Individuals, and Infrastructure that make up a society. The geography of the society is modeled at various levels including City, Province, Country, Region, and World in terms of Political, Military, Economic, Social, Information, and Infrastructure (PMESII) nodes. The virtual environment integrates multiple theories from various disciplines to program behaviorally accurate agents with dynamic rules that govern and guide their actions and interactions. SEAS-VIS facilitates a seamless and interchangeable integration of human and software agents and allows for testing the efficacy of theories, decisions, strategies, and tools.
Models are made fully transparent to allow for close scrutiny by the client, facilitating model critique and development.
SEAS-VIS offers the ability to do course of action analysis, test hypotheses, learn through experimentation, conduct effects-based operations and planning, and develop Operational Net Assessment. The product allows the user to evaluate and manage the challenges of international crises.
The second period extends from 1996 roughly to 2001. This is the “Early DoD” period. During this period the DoD began to express interest in OOTWs. Most of the applicable tools were dual-use, designed for combat operations, but having some use for OOTWs, such as logistics tools. However, even they were often wrong-direction: computing “tail” given “tooth,” rather than computing “tooth” given “tail.” Some databases existed, supporting warnings of state failures and there were some special application tools, such as counter-narcotics and disaster models. And there were some potentially useful models; however, they were not widely used.
Spurred by the U.S. Pacific Command (USPACOM), a series of conferences were held to define the domain and identify research and development needs.
Feb 1996, PACOM, Monterey, CA
Identify OOTW information requirements, investigate OOTW processes and interactions, begin functional specification for OOTW tools, develop definitions-taxonomy-attributes-tasks, identify future work
Created a draft report
Mar 1996, Cornwallis I, Nova Scotia, Canada
Detailed presentations and discussions on various aspects of OOTW
Created proceedings
Sep 1996, International Symposium on Military Operational Research (ISMOR), Shrivenham, UK
20% of papers were on OOTW
Sep 1996, PACOM, Monterey, CA
Review the draft report
Created final report
Oct 1996, Military Operations Research Society (MORS), McLean, VA
Prepare for upcoming QDR
One of seven working groups examined OOTW and recommended creation of historical database of OOTWs
Created a report
Jan 1997, MORS, Tampa, FL
Examine the results of the PACOM work in more detail
Created a report
Apr 1997, OSD Program Analysis & Evaluation (PA&E) /Joint Staff J-8
Examine the functionality of Joint Warfare System (JWARS) with respect to OOTWs
Oak Ridge was tasked by OSD (PA&E) to define the OOTW/JWARS intersection
Created a report
Jan 1999, Office of the Assistant Secretary of Defense (OASD), Special Operations/Low Intensity Conflict (SO/LIC), Alexandria, VA
Refine the requirements for force design tools to support OOTWs
Created two reports for force design
Created a report on cost
Created a report on impact analysis
Jul 1999, PACOM, Alexandria, VA
Examine the methodologies and tools available for forecasting instability
Created a report
Feb 2000, MORS, Fairfax, VA
Help prepare for Quadrennial Defense Review (QDR) 2001
OOTW beginning to be addressed more firmly in QDR
Just prior to the start of the Early DoD period and lasting into the “Current” period, a number of books were published that contained lessons from various DIME/PMESII type operations or theoretical discussions on the topic. The major source of these books has been the Command and Control Research Program (CCRP), an OSD activity.
During the Early DoD period some tools were built or begun, including COST, SEAS and DIAMOND UK. The Contingency Operational Support Tool (COST) was built ca. 1998-99. The following lists the requirements for costing tools and indicates which COST supported.
Incremental costs of notional OOTWs, to support long-term analysis
Generic types of operations, represented by a few cost drivers
COST not designed for this, but could support
Probable incremental costs, to support decision to engage in a particular OOTW
Complete cost model, permitting iterative refinements
COST meets the requirement
Relative (full) costs, to support the selection of mission plan
Support comparison of costs of alternative COAs
COST would require modifications to permit selection of full costs
Costs incurred, to support recovery from other agencies and governments
Ensure all recoverable costs are identified
COST would require modification with database of allowed categories
Incremental costs of a particular OOTW, to support Congressional budget process
Ensure long-term operations are correctly budgeted
COST should support this at FOC
Cumulative costs of a particular operation
Ensure capture of costs of replacing lost capabilities
COST would require major modifications
Actual costs of a completed operation
Capture and compare actual costs against forecasts
COST would require additional data gathering to support a database of actual costs
The Diplomatic and Military Operations in a Non-warfighting Domain (DIAMOND) was begun by the United Kingdom’s (UK) Ministry of Defense (MOD) Science and Technology Laboratory (DSTL). The following description is taken from a report on its Verification and Validation (V&V) [13].
DIAMOND is a moderately-fast running, high-level, stochastic, object-oriented simulation of peacekeeping, peace enforcement and humanitarian aid operations (collectively called Peace Support Operations (PSO)). The major aspects of the technical design include.
• A simple node and arc network that provides a graphical representation of the region and environment allowing the model to represent key areas of interest. Key facilities, such as airports and civilian shelter can be represented.
• The representation of key actors and contributors to PSO by use of Entities. These represent the capabilities and behaviors of military units, civilians, non-military organizations, and the leaders or commanders for each. Entities interact with each other and the environment and exchange or consume key commodities such as food, fuel and ammunition.
• A mechanism to organize entities into common ‘parties’ that represent specific organizations or common groups within a scenario. These parties have an appropriate command structure and communications network to facilitate the allocation of missions and flow of intelligence throughout the party. Parties have relationships with one another that define their interactions.
• A mechanism to represent each party's concept of operations by nesting objectives in a series of plans and for those objectives to consist of a series of missions which entities can prosecute during a campaign. Commanders within a party allocate resources to achieve their objectives in line with the sequence of plans and the simulation completes when a set number of parties achieve their end state conditions or when a predetermined period of time has elapsed.
• A mechanism (referred to as negotiation) to obtain access to an area denied to one party by another and to allow multi-party co-operation to achieve aims and objectives without having to rely entirely on their own resources.
• A mechanism to allow entities to gain information on their environment and other entities through sensing, interactions and communication during model run. This information is organized into a local picture that allows those entities to make informed decisions on how they should prosecute their missions and activities delegated to them by their superior commanders.
The Current period began about 2001 and is marked with an increase in interest in DIME/PMESII models, both in their creation and their use.
2000, the Center for Army Analysis (CAA) created the Analyzing Complex Threats for Operations and Readiness (ACTOR) model to make long-term forecasts of country instability.
2001, the Fund for Peace created the Conflict Assessment System Tool (CAST) model to provide early warning and assessment of internal conflicts.
2001, the Defense Modeling and Simulation Office (DMSO) began the creation of the Flexible Asymmetric Simulation Technologies (FAST) Toolbox to provide support for analysis of OOTWs. The FAST Toolbox has grown to include the US version of DIAMOND, DIAMOND-US; the Joint Conflict and Tactical Simulation (JCATS), a combat model; the Unit Order of Battle Data Access Tool (UOB DAT), a force structure manipulation tool, the ISSM, and Pythagoras.
2002, Northup Grumman created the Pythagoras agent-based model, which can be used for modeling many aspects of OOTWs.
2003, the Sentia Group created the game-theoretic Senturion model for forecasting DIME/PMESII situations.
2003, Hartley Consulting created the Interim Semi-Static Stability Model (ISSM) to track, monitor and understand DIME/PMESII operations.
2003, CAA created the Near-Term Forecasts of Crisis and Instability Using Text-Based Events (NEAR-TERM FORECITE) model to make short-term forecasts of country instability using the IDEA tool mentioned earlier to capture data from electronic news media.
2005, the Defense Advanced Projects Agency (DARPA) created the Conflict Modeling, Planning, and Outcomes Experimentation (COMPOEX) system as the next generation DIME/PMESII system.
2007, the Air Force Research Laboratory (AFRL), Warfighter Interface Research and Technology Operations (WIRTO) began contracting to build a DIME/PMESII information sense-making tool.
2008, DARPA began contracting to build an Integrated Crisis Early Warning System (ICEWS).
In 2005, the DoD used the FAST Toolkit to support the investigation of DIME/PMESII issues for the QDR.
In the latter part of the Current period, several efforts have been undertaken to understand the current status.
Nov 2006, the U.S. Army Training and Doctrine Command (TRADOC) Analysis Center (TRAC), Wargaming & Support Division compiled information on models to support Stability Operations.
Apr-May 2007, OSD/PAE/Joint Data Support (JDS) compiled information on models and tools.
Nov 2007, METRON, sponsored by N81, assessed modeling capabilities.
Feb-Mar 2008, University of Central Florida (UCF) Institute for Simulation and Training (IST), sponsored by Joint Forces Command (JFCOM), compiled information on DIME/PMESII tools.
Three broad areas were included: metadata, VV&A, and modifications to the requirements framework.
Metadata is a fancy word for extra information about data or models. The simplest example for metadata on data is the source and date information on a particular datum. The corresponding metadata for the model would be requirements on the nature of a particular input. For example, the input might require a distance denominated in kilometers, rather than miles.
Syntactics, or syntax, is concerned with the way sentences are constructed from smaller parts, such as words and phrases. Semantics is the study of meaning in communication. In computer science, semantics permits programs to be separated into their syntactical part (grammatical structure) and their semantic part (meaning). One of the modern applications of ontology deals with semantic web. In computer science,ontologies are representations of a set of concepts within a domain and the relationships between those concepts. All three of these concepts are needed in defining metadata requirements. When we prescribe the format of the data, e.g., text, integer, fixed decimal, the subject of the metadata is syntax. When we describe the meaning of the data, for example, the units in which it is denominated or which factors are aggregated into it and which factors require different instantiations of the datum for each value of the factor, the subject of the metadata is semantics. When we say that sets of variables have given relationships with one another, the subject of the metadata is ontology.
Metadata on the Required Inputs: The following elements have been observed to be useful for each input datum.
Units label: e.g., “people,” “battalions,” “million gallons,” “percent,” Likert “scale”
Coordination: whether the numerator or denominator with another datum,
Coordination datum: the identifier of the other datum,
Likert scale anchors: text defining the meaning of the scale values,
Potential component data: identification of variables that might be combined to yield the required datum,
Composition formula: formula for composing the components,
Definition: definition of the datum in terms of raw data, text,
Source(s): suggested sources for the datum,
Social model: description of the social model used by the source,
Social model validity: level of validity of the social model,
Social model citations: citations for the social model and its validity,
Distribution: distribution of the source data over countries, showing central tendencies and extrema and helping to ensure that the semantic meaning is correct for the model,
Required precision and accuracy,
Conversion formulas: formulas for converting raw data into the required datum,
Alternatives: alternatives to any of the above.
Metadata on the Delivered Outputs: The following elements have been observed to be useful for model outputs.
Units label: e.g., “people,” “battalions,” “million gallons,” “percent,” Likert “scale”
Likert scale anchors: text defining the meaning of the scale values,
Component data: identification of variables that have been combined to yield the output or description of the model that yields the output,
Definition: definition of the output in text,
Social models: description of the social models used by the output,
Social model validity: level of validity of the social models,
Social model citations: citations for the social models and their validity,
Estimated precision and accuracy of the output.
Metadata on the Internals of the Model: The following elements should be addressed to support the user of the model.
Base understandings: standard assumptions for the input data and description of how it will be processed,
Differences caused by time delays, initial data values, special circumstances: alternative assumptions for the input data and processing for special cases,
Metadata on each submodel, whether social, economic, etc.,
Type of model,
Source for logic,
Level of validity,
Citations,
Estimated precision and accuracy,
Special issues dealing with custom logic,
Coordination of custom logic variables among themselves,
Coordination with the rest of the model.
Metadata on Model VV&A: Verification, Validation and Accreditation metadata should include:
Dates,
Locations,
Personnel,
Personnel roles,
Type of event,
Intended model use(s),
Test types,
Test standards,
Test scenarios,
Test results,
Mitigation recommendations,
Metadata on the Collected Input Data: The following elements have been observed to be useful for collected input data.
Collection date,
Date associated with the datum value (if appropriate),
Units label: e.g., “people,” “battalions,” “million gallons,” “percent,” Likert “scale”
Definition: definition of the datum in terms of raw data, text,
Source: source for the datum,
Social model: description of the social model used by the source,
Social model validity: level of validity of the social model,
Social model citations: citations for the social model and its validity,
Estimated precision and accuracy.
The DoD metadata specification provides for three formats for metadata: text (comma separated) documentation, XML, and Hypertext Markup Language (HTML). Other formats are possible, such as text with hyperlinks and a relational database. The DoD specification appears to be oriented toward describing large groups of homogenous data. Unfortunately, it appears that in the DIME/PMESII domain much or most of the data will be found in bits and pieces, requiring separate metadata entries for each number, rather than for each file. This situation makes the option of a relational database that contains the data values and the metadata much more attractive.
The VV&A requirements from the COMPOEX project were adapted to NRL needs.
NRL developed a set of requirements and vetted these with its DIME/PMESII Advisory Panel. It was advised that Metadata and VV&A requirements be added to the revised requirements framework.
1. C4I Analysis and Database Branch. Reverse Engineering for Data Integration and Sharing (REDIS) Methodology Manual [Draft]. C4I Test Division Electronic Proving Ground, Fort Huachuca, AZ, 1996.
2. Cipparone, John and Wayne Randolph. “Operations Other Than War: A FAST Toolbox for Warfighters,” PowerPoint Presentation at DMSO Technical Review, 14 July 2004. DRC, Vienna, VA, 2004.
3. Clemence, Robert C., et al. Verification, Validation, And Accreditation (VV&A). Evidence Based Research, Vienna, VA, 2007.
4. Deputy Assistant Secretary of Defense (Deputy Chief Information Officer). Department Of Defense Discovery Metadata Specification (DDDMS), Version 1.2. 3 January 2005.
5. DoDD 5000.59.
6. Hartley, D. S., III. Operations Other Than War: Requirements for Analysis Tools Research Report, K/DSRD-2098. Lockheed Martin Energy Systems, Inc., Oak Ridge, TN, 1996.
7. Hartley, D. S., III and S. L. Packard. OOTW Tool Requirements in Relation to JWARS, Y/DSRD-3076. Lockheed Martin Energy Systems, Inc., Oak Ridge, TN, 1998.
8. Hartley, D. S., III and S. L. Packard. OOTW Cost Tools, Y/DSRD-3099. Lockheed Martin Energy Systems, Inc., Oak Ridge, TN, 1998.
9. Hartley, Dean S., III, Richard E. Bell, and Stephen L. Packard. OOTW Force Design Tools, Y/DSRD-3117. Lockheed Martin Energy Systems, Inc., Oak Ridge, TN, 1999.
10. Hartley, Dean S., III and Richard E. Bell. OOTW Force Design Workshop Proceedings, Y/DSRD-3124. Lockheed Martin Energy Systems, Inc., Oak Ridge, TN, 1999.
11. Hartley, D. S., III. PACOM Instability Indicators Workshop, Y/DSRD-3134. Lockheed Martin Energy Systems, Inc., Oak Ridge, TN, 1999.
12. Hartley, D. S., III. Designing an OOTW Impact Analysis Tool, Y/DSRD-3148. Lockheed Martin Energy Systems, Inc., Oak Ridge, TN, 2000.
13. Hartley, Dean S., III. MOOTW FAST Prototype Toolbox: FY05 Validation Strategy & Plan. DRC, Orlando, FL, 2005.
14. Hartley, Dean S., III. Operations Other Than War (OOTW) Flexible Asymmetric Simulation Technologies (FAST) Prototype Toolbox: ISSM v4.00 Analysts’ Guide. DRC, Orlando, FL, 2006.
15. Henningsen, Jacqueline, ed. Quick Response Analysis Requirements and Methodologies (QRAM) Mini-Symposium. MORS, Alexandria, VA, 1996.
16. Joint Staff. Joint Pub 5-0.
17. Knepell, Peter L. and Deborah C. Arangno. Simulation Validation: A Confidence Assessment Methodology. IEEE Computer Society Press, Los Alamitos, CA, 1993.
18. Lacy, Lee W., et al. “Experiences with using OWL in Military Applications,” in OWL: Experiences and Directions. Galway, Ireland, November 11-12, 2005. http://www.mindswap.org/2005/OWLWorkshop, March 2008.
19. Lincoln, Don and Richard Gautier. Operations Other Than War (OOTW) Flexible Asymmetric Simulation Technologies (FAST) Prototype Toolbox Architecture Specification (Rev 1). DRC, Vienna, VA, 2004.
20. Staniec, Cyrus and Dean Hartley, eds. OOTW Analysis and Modeling Techniques (OOTWAMT) Workshop Proceedings. MORS, Alexandria, VA, 1997.
21. Tolk, Andreas. “Composable Mission Spaces and M&S Repositories – Applicability of Open Standards,” Paper 04S-SIW-009, April 2004.
22. Tolk, Andreas. “Metamodels and Mappings: Ending the Interoperability War,” Paper 04F-SIW-105, 2004.
23. Woodcock, Alexander and David Davis, eds. Analytic Approaches to the Study of Future Conflict. The Canadian Peacekeeping Press, Clementsport, Canada, 1996.
If you arrived here using a keyword shortcut, you may use your browser's "back" key to return to the keyword distribution page.
Return to Hartley's Projects Page
