C3HPM: An application of IMPRINT within the MATREX Bret Kellihan Randolph Washington DCS Corporation 1330 Braddock Place Alexandria, VA 22314 571-227-6284, 571-227-6216
[email protected],
[email protected] Keywords: MATREX, Modeling and Simulation, Human Performance Modeling, IMPRINT. ABSTRACT: This paper describes an ongoing project where DCS Corporation built a prototype tool (C3HPM), using the Army Research Laboratory’s Improved Performance Research Integration Tool (IMPRINT) to synchronize human behaviors implemented in the Modeling Architecture for Technology Research and Experimentation (MATREX) C3Grid by executing real-time IMPRINT task networks representing each human task. This paper provides background information on the MATREX STO and IMPRINT, identifies the specific goals of the project, describes in detail the design of the Command Control, and Communications Human Performance Model (C3HPM), describes the integration of the C3HPM into version 0.5 of MATREX, and discusses future plans.
1. Introduction Modeling and Simulation is an essential technology in the Army Transformation for the Objective Force. The accurate representation of humans in models of the Objective Force will help the Army make critical decisions on force structure and equipment design. The U.S. Army Research Laboratory, Human Research & Engineering Directorate (ARL HRED) has been active in the development of human performance modeling tools that support the Army modeling and simulation community. This paper describes an ongoing project where DCS Corporation applied one of ARL HRED’s principal tools, the Improved Performance Research Integration Tool (IMPRINT), in an innovative fashion to support the Modeling Architecture for Technology, Research & Experimentation (MATREX) Science and Technology Objective (STO). It provides background information on the MATREX STO and IMPRINT, identifies the specific goals of the project, describes in detail the design of the Command Control and Communications Human Performance Model (C3HPM), describes the integration of the C3HPM into version 0.5 of MATREX, and discusses plans for future upgrades.
2. Project Background 2.1 MATREX STO MATREX is a U.S. Army Research Development and Engineering Command (RDECOM) managed STO, which includes participation by the major Army Research Development and Engineering Centers and Army Laboratories. The five-year STO program,
initiated in FY03, combines activities from two previous STO programs: the Joint Virtual Battlespace (JVB) and the Virtual Distributed Laboratory for Modeling and Simulation (VDLMS). The goal of the MATREX STO is to design simulation architecture and build a reference implementation to represent key characteristics of network-centric warfighting systems. Implementation of the architecture will use standardized component interfaces, such as the High-Level Architecture (HLA) networking specification, to provide a secure persistent environment that supports the evaluation of Objective Force and Future Combat Systems concepts and technologies. The MATREX simulation environment will be scalable from platform-level up to Unit of Action. The MATREX simulation architecture is designed to support distributed integration of RDECOM components developed and hosted throughout the U.S. The initial configuration of MATREX, V0.5, was completed in December 2003. As depicted in Figure 1, it consisted of numerous HLA federates interconnected via the Defense Research and Engineering Network. Rather than being configured around simulation entities (i.e., platforms or soldiers), the MATREX architecture is service-based. That is, separate models are created to simulate specific functions on behalf of multiple entities. A complete entity is simulated by the combined action of the various service models. Each functional simulation is implemented as a service that can be tasked by a client representing an entity to perform a service on behalf of that entity or can be
configured at startup to perform services on behalf of specific entities. This service-based simulation architecture enables simple scaling of the simulation infrastructure. Multiple computers running the same software may be used to provide services in high demand. As more entities are added to simulation exercises the number of computers running each service can be adjusted to optimize overall simulation performance. Platform Representation
After Action Review
Server-based Simulation Services
OneSAF Testbed Baseline
Aviation Mobility Server
Lethality/ Vulnerability Server
Missile Server
Armaments Server
Vehicle Dynamics Motion Simulation
hlaResults
Data Distribution (HLA/RTI)
Dynamic Organization Service
Organic Communication Service
C3Grid Simulation Services
Message Transceiver Service
SA Normalization & Dissemination Service
C3HPM
hlaControl
Execution Management
Automated Test Capability
Testing
Figure 1 MATREX V0.5 System Architecture A key set of federates in the MATEX V0.5 implementation are the Dynamic Organization Service, the Organic Communications Service, the Message Transceiver Service, and the Situational Awareness Normalization and Dissemination Service (SANDS.) Collectively referred to as the C3Grid, these federates provide a robust highly parametric Command Control and Communications (C3) simulation infrastructure that enables the modeling of Network Centric Warfare. The Dynamic Organization Service and the Organic Communications Service enable the representation of information flow topologies that are unique to message type, decision points, and data processes. These services work in conjunction with the OneSAF Testbed Baseline (OTB) to generate message traffic for simulated platform entities. The Message Transceiver Service models battlefield communications networks and provides realistic delays for generated message traffic. SANDS implements Common Operating Picture (COP) management for the force structure according to information flow using blue/red deconfliction, target correlation, aggregation and information dissemination. The C3Grid also supports the integration of external services such as communication effects models to increase the fidelity of the simulation. 2.2 IMPRINT IMPRINT was developed for ARL HRED to assist researchers in conducting human performance analyses. IMPRINT consists of a graphical user interface that supports the design of complex task network models and a discrete-event simulation engine that simulates the execution of the task networks based
on scenario inputs while collecting data for reports. Task network models have a long and successful history of representing human performance in military system development. Their strength is that they are easy to examine, understand, and modify. They also calculate performance measures, such as workload, time, and accuracy that give combat developers hard number metrics much like those associated with the other physical components of systems (speed, range, etc.) IMPRINT’s graphical user interface allows human factors engineers to define a human activity in terms of networks of functions. Each function is further broken down into a network consisting of other functions and tasks. A human factors engineer can then associate an operator with each task, assign an estimated time to complete that task, as well as assign visual, cognitive, auditory, and psychomotor workloads that the execution of the task places on the operator. IMPRINT includes micro-models to assist in assigning task execution times, provides various means to prioritize tasks, and the ability to resolve resource conflicts. IMPRINT also includes models that can moderate human performance level based on the values of stressors including temperature, noise level, MOPP level, and waking hours. Traditionally, IMPRINT is used as a standalone tool to generate statistical data to support human factors analysis and design. In late 2002 ARL HRED released IMPRINT 6, which includes a Microsoft COM interface to IMPRINT’s underlying discrete-event simulation engine that allows IMPRINT task networks to exchange data with external simulations. IMPRINT 6 also provides an API to control the execution of the discrete-event simulation engine allowing the IMPRINT simulation to be synchronized with external simulations. These additions enable IMPRINT to be integrated into distributed simulation architectures and support the exercising of IMPRINT task networks with high-fidelity battlefield environments. The additions also allow the development of human models in IMPRINT that can participate in large-scale distributed simulations.
3. Project Objectives Early in 2003, DCS Corporation under the sponsorship of ARL HRED conducted an analysis of the evolving MATREX simulation architecture to assess its capability to represent human behavior. The analysis determined that while there were models of human behavior incorporated in several MATREX federates; there was no overall representation of individual humans that took into account the constraints of human performance. The individual service-based models within MATREX acted independently and the interaction of different behaviors occurring in the same
human at the same time was not considered. To address this deficiency the development of a human performance modeling service was recommended to the MATREX STO program.
IMPRINT Task Networks
Task A
In mid 2003, the MATREX STO program funded a project to develop a prototype of such a service and integrate it into the V0.5 configuration of MATREX. Since the prototype was to be initially evaluated by integrating it with the SANDS federate of the C3Grid, it was named the C3HPM. The objectives of the C3HPM are to: •
•
•
Provide a service that synchronizes the activities of human operators modeled in the MATREX C3Grid using IMPRINT task network models of each specific task with priorities assigned to each task. Provide a simple mechanism to map tasks performed by platform entities to specific crew members within the platform using equipment-specific IMPRINT task networks. Provide an efficient service-based simulation implementation that allows the modeling of hundreds of human operators on a single PC, which can be scaled to larger exercises through the use of multiple PCs.
4. C3HPM Description Figure 2 illustrates the operation of the C3HPM. During a simulation exercise C3Grid federates send Task Request interactions to the C3HPM when an external or internal event triggers the simulation of a specific human task. The requesting C3Grid federate waits to receive a Task Response interaction from the C3HPM before executing the effect of the human task. The C3HPM can receive task requests from any C3Grid federate, map the request to a specific operator, and execute a task network corresponding to the task based on the operator’s equipment configuration. Task networks are executed in real time and in priority order. When a task network execution is completed, the C3HPM sends a Task Response interaction to the C3Grid federate that imitated the task. The key components of the C3HPM are the C3HPM Interface Manager, the C3HPM Task Manager, and the C3HPM task networks. Each of these components is described in detail in the following sections.
Task B
Task C
Task D
Task Manager COM C3HPM Interface Manager
Task Request
Operator Inputs
Task Response
C3Grid Federates C3Grid Federates C3Grid Federates (Human Behavior Models)
Exercise Config Files
Operator Outputs
Figure 2 C3HPM Block Diagram 4.1 C3HPM Interface Manager The C3HPM Interface Manager is a Windows 32-bit executable that shuttles information between the C3Grid federates and the IMPRINT task networks that model human performance. It is the custom interface component that binds IMPRINT’s underlying discrete event simulator to the rest of the MATREX federation; For the MATREX program, the MATREX core engineering group created several tools to ease federation development. One of those, the CodeGen, wraps the majority of the HLA/RTI Network Programming Interface into a single C++ class that manages communications on the HLA network. CodeGen standardizes the way federates communicate via the HLA network, and provides a common foundation that prevents each federate developer from re-implementing basic HLA functionality. The C3HPM Interface Manager communicates both via the HLA network to the other MATREX federates and via a COM interface to the Human Performance models that run within IMPRINT’s discrete event simulator. The C3HPM Interface Manager is responsible for receiving Task Requests from the HLA network (see Figure 3), queuing those requests by priority per operator and sending them to the C3HPM Task Manager for simulation. Once processing has been completed on a specified task, the C3HPM Task Manager returns completion information to the C3HPM Interface Manager. The C3HPM Interface Manager then generates a Task Response to send back to the requesting federate notifying them of the completion status and the duration of the task. Traditionally IMPRINT maps a specific operator to a task network at design time. IMPRINT’s architecture necessitates duplication of task networks if they are to be simulated for two different platforms concurrently.
It also requires that for every platform simulated, a corresponding set of task networks must be arranged in the IMPRINT model file. The C3HPM Interface Manager, in conjunction with the C3HPM Task Manager inside IMPRINT seeks to remedies this limitation by allowing a single instance of a task network to simulate multiple operators on multiple platforms. IMPRINT
Interface Manager
C3Grid
Task Buffer
Operator Descriptor Matrix
Operator Descriptor Matrix NewTask Queue
The core functionality of the C3HPM is implemented by the C3HPM Task Manager networks within IMPRINT. It is an IMPRINT task network that coordinates the execution of multiple C3HPM Task Networks on behalf of multiple operators. The tasks in the C3HPM Task Manager do not model human performance, rather they act as a communication bridge to the C3HPM Interface Manager and control the execution of the individual C3HPM Task Networks.
Execution Queue
Platform Status Table
Task Manager IMPRINT Execution Time Management
Task Networks
4.2 IMPRINT C3HPM Task Manager
Control
VACP Workload
Status Config File
Figure 3 C3HPM Interface Manager One responsibility of the C3HPM Interface Manager is to map external platform entity ID strings to IMPRINT Operator IDs. This is necessary because IMPRINT identifies each operator by a unique integer. The assignment is done dynamically as Task Requests are received and is governed by two configuration files. One file configures platform types by mapping each MATREX platform ID string to an operator type. The second file configures operator types by identifying the C3HPM Task Networks in priority order for each operator type. Since the same task network can be specified for more than one operator type in the configuration file, it is possible to reuse task networks in multiple operator types. The configuration files allows easy reconfiguration of which task networks are assigned to an operator type. The configuration files also permit building a library of task networks that model different ways to perform a task, which can later be used to build specific operator models. Operator models can then be assigned to platform operators through the configuration files before a scenario begins. Another requirement for the C3HPM is that it be able to run in both a time-managed and a real-time mode. IMPRINT’s discrete event simulator is capable of running much faster than real time. A special task network within IMPRINT constantly updates the C3HPM Interface Manager with IMPRINT’s current simulation time. In the MATREX application, the C3HPM is kept in sync with the rest of the federates using functions in IMPRINT’s discrete event simulator’s API to regulate model execution.
Figure 4 C3HPM Task Manager IMPRINT Networks As illustrated in Figure 4, there are three components to the C3HPM Task Manager. As the C3HPM Interface Manager receives Task Requests from C3Grid Federates, they are placed in a queue by task priority and operator ID. When IMPRINT is notified by the C3HPM Interface Manager about the next task for an operator at a given priority, the Add Task to Queue network is triggered. It records information about that task and places it into the execution queue for the specified operator at the specified priority. When the Add Task to Queue task completes, it starts the Run Highest Priority task and specifies the operator ID whose task queue it just modified. The Run Highest Priority task will suspend all currently executing tasks for the operator and then start or resume whichever task has the highest priority. If the task that was running before the new task was received had higher priority than the new task, the original task will be allowed to continue. Figure 5 shows the process for receiving a task request.
and modified for any changes in a scenario. The method demonstrated by the C3HPM allows a single instance of a task network to process any number of operators and allows an operator’s task networks be easily reconfigured via configuration files..
Task Request Received
Add Task to Buffer
Determine Operator Type from PST
Yes Operator Allocated?
Add Task to Operators Queue
Push Operator Descriptor Matrix to IMPRINT
Notify IMPRINT of Tasks Types to be executed.
No END
Allocate Operator in ODM
Figure 5 Task Request Flow Diagram When simulation of a task for an operator is complete, information about the completion status and duration is sent back across the COM interface to the C3HPM Interface Manager. All human performance metrics (workloads, stressors, etc) are recorded within IMPRINT’s discrete event simulator for later report generation. As part of task completion, the Remove Task from Queue task is started for that operator. It removes the task that has been completed and requests the C3HPM Interface Manager to send another task at the same priority as the one that just completed if there is one queued. Finally, the Run Highest Priority task is started again and the highest priority task available for the operator begins execution. This process is illustrated by a flow diagram in Figure 6. Task Complete
IMPRINT Sends Task Complete Status
Record completion Time and Status in Task Buffer
Yes More Events of Same Type?
Push Operator Descriptor Matrix to IMPRINT
Notify IMPRINT of Tasks Types to be executed.
No Yes More Events of Any Type?
Send Task Response to Initiating Federate
Delete Task from Task Buffer
No
END
Delete Operator from Operator Descriptor Matrix
The built-in priority mechanism in IMPRINT is static and task priorities cannot be changed without making changes to the task model. The C3HPM’s architecture allows priorities to be reordered and changes to which particular task networks are executed for a given platform configuration to be made by a simple configuration file change. The C3HPM makes it easy to model additional platforms by simply adding their platform information to the configuration files There is no need to replicate task networks and statically assign operators as is normally done with IMPRINT. One other feature the C3HPM offers is variability of execution within the C3HPM Task Networks. There are two items in the Task Request interaction called Task Detail and Task Complexity that allow a task network to be run slightly differently depending on circumstances. Task Complexity is essentially a multiplier that can represent a count (i.e.; number of targets in a salute report) or difficulty rating. It can be used to increase the duration of a task or modify the workloads placed on an operator by a specific task. Task Detail is a bitwise field that can be used to signal whether certain sections of a task network should be run or not. This can be useful for modeling similar vehicles with similar roles but perhaps at different echelons with slightly different responsibilities. If the vehicle were to inherit a higher or lower role, it is a simple matter to enable or disable sections of a task network via Task Detail. Both Task Complexity and Task Detail can be changed dynamically during a simulation as situations evolve. In implementation, IMPRINT’s Goal Orientation mode is still used at design time for task network creation. It is necessary to use Goal Orientation mode because it is the only mode that provides access to the COM interface. The other modes, VACP and Advanced Workload, do not support COM.
Figure 6 Task Response Flow Diagram 4.3 C3HPM Task Networks This method of handling tasks is somewhat different from IMPRINT’s standard Goal Orientation model. IMPRINT has a built-in mechanism for assignment of task priorities and handling their execution, however it does not allow the same task network to be assigned to multiple concurrent operators. This limitation requires the task networks to be duplicated for each operator
C3HPM Task Networks are specialized IMPRINT task networks which define the specific steps in performing an operator task. With the exception of a few design rules, the process for developing C3HPM task networks is nearly identical to the process for developing them for standard IMPRINT.See Figure 7 for an example of the design time interface.
The first phase of the MATREX V0.5 integration was to test the C3HPM with the ATC (Advanced Testing Capability) federate. The ATC is a java tool that can be set up to send and receive any interactions that exist within the MATREX Federation Object Model (FOM.) For test runs, the C3HPM was configured to emulate ten platforms with two different platform configurations. The ATC was programmed to send several Task Requests for each platform. All Task Requests received the appropriate responses from the C3HPM at the proper time. Figure 7 C3HPM Task Networks To handle proper recording of human performance information and allow the C3HPM Task Manager to run when necessary, there two IMPRINT macros that must be inserted at the beginning and ending of every task: C3_BEGIN and C3_ENDTSK. Also, for the last task in a task network, C3_ENDTSK is replaced with C3_ENDLST. Finally, for the task network to function properly, the last task bubble is not connected to END. The only other design requirement is that a task network not split into multiple paths where both paths are followed and later rejoined. The similarity between IMPRINT and C3HPM task networks permits modelers familiar with IMPRINT to easily create task networks for use with C3HPM.
5. MATREX 0.5 Integration The prototype C3HPM delivered to the MATREX V0.5 integration utilizes the design discussed in previous sections. Example models conformining to the C3HPM design rules were built for integration and testing with the C3Grid. These models provided a representation of vehicle commanders dealing with the generation and receipt of spot and situation reports. An example is provided below in Figure 8.
After the ATC testing was complete, a copy of the C3HPM was delivered to the MATREX Integration Lab for testing with the C3Grid and other MATREX federates. During testing with the C3Grid, the C3HPM was configured to model about 100 individual platforms during a test run. The C3HPM performed exceptionally on a Dual 2.0GHz Xeon system. From informal testing, it is estimated that upwards of 1000 separate platforms can be simultaneously simulated by the C3HPM on a single high-performance PC. At the MATREX V0.5 integration, the C3HPM demonstrated the need for real time human performance modeling in network centric warfare experiments. By modeling the human actions necessary to generate, send, receive, and process basic communication interactions, information flow between platform entities was slowed to more realistic levels. Before the introduction of the C3HPM, the C3Grid assumed that the sender and receiver of a communication could transmit and understand a message instantaneously. With the C3HPM running there were situations where operators became backlogged and were not able to send information as quickly as hoped, which led to platforms not having information they were assumed to have about both enemy and friendly units. Though the testing used only rough models, and only involves a small subset of interactions being modeled, the C3HPM project clearly demonstrated the need for greater exploration of human performance modeling in future experiments.
6. Future Plans
Figure 8 An Example Network from MATREX V0.5 Integration: Receive Salute Report
DCS Corporation is continuing to support the development of the C3HPM for MATREX V0.7 in 2004. Planned activities include continued testing of the scalability of the C3HPM, definition of task request interactions for additional C3Grid human behaviors, and modification of the C3HPM to allow it to be configured via the HLA interfaces rather than through local configuration files. In future experiments the C3HPM will become a centralized model for human performance where decisions that are currently made
by different service federates without regard for human workload will correlated and impact each other. In the longer term, DCS plans to modify the C3HPM to enable it to monitor environmental conditions within a MATREX simulation and dynamically adjust IMPRINT stressors to moderate human performance. DCS also plans to implement more advanced task scheduling approaches in the C3HPM including execution of concurrent tasks and off-loading of tasks to other operators.
7. References Imprint Website, http://www.arl.mil/hred/imb/imprint/imprint.htm
Author Biographies BRET KELLIHAN is an electrical engineer at DCS Corporation. He has led the design of constructive models for distributed simulations using IMPRINT for several ARL and Tank Automotive Research, Development and Engineering Center projects. RANDOLPH WASHINGTON is the Vice President of the Defense and Aerospace Division at DCS Corporation. He has been involved in simulation and modeling of Army ground vehicles for over 14 years. He is currently leading DCS efforts to develop techniques to model and simulate intelligent behavior with ground vehicles.
