Mediation to Implement Feedback in Training (MIFT)
Old version, use
MIFT research instead.
OLD Participants:
Computer Science Department, Stanford University, Gates 4A, Stanford CA 94305
Myriad Software; 2245 Tasso St., Palo Alto, CA 94301
Phone: 415-327-2973; FAX: 415-327-5509
Funding
We are supported by DARPA ISO / CAETI, as part of the Exman Project.
Funding started March 1 1996.
Kirstie Bellman is the DARPA program Manager.
Description
Mediator technology to analyze data obtained during simulated, real,
and mixed training exercises according to training scenarios.
Abstract
This project will undertake research in automated data abstraction,
based on a formalized model of the customer's need for information.
Such an abstraction process will be performed by a knowledge-driven
subsystem
in a computer network which mediates between customers and
data resources. The aproach focuses on the crucial issue of data or
information overload, which occurs when the volume of data exceeds
what a customer can comprehend. This problem is increasing in
importance, since improved communication, larger databases, and
effective search methods are now providing more material than people
can afford to read or analyze.
The specific application is to training data, and the model
represents the learning/training scenario. A scenario is intended to
fullfill a number of training objectives. After the scenario is
executed (and perhaps even during excution) the feedback can help
design better or complementary successor scenarios,
Mediators
for training data (gif)
Information
Flow.
Work Plan
Stanford University is developing a mediator-based software architecture
for the Exercise Analysis and Feedback phase and for the feedback loop to
exercise planning and preparation. The mediators incorporate knowledge
about the scenario objectives and the task and subtasks to be trained.
Mediators use this scenario knowledge to relate simulation results to the
objectives and tasks to be trained so that O/Cs, trainees, and commanders
can query the simulation results using normal scenario-based terminology.
For example, rather than forcing the O/C formulate a query to "select all
enemy detections of Alpha company before it began its attack," the O/C
will simply ask whether Alpha company achieved its scenario subtask of
remaining hidden until the beginning of the attack. A mediator will know
that enemy detections before the attack are evidence that the unit was not
successful in remaining hidden. Mediators will produce results tailored to
various needs including those of exercise planners, weapons designers,
tactics developers, and other consumers of simulation results.
A second goal of the mediator-based architecture is that military training
and support personnel will tailor and extend the analysis and feedback
software to meet there own local needs. The goal is to dramatically reduce
the amount of contract programming needed to develop separate analysis and
feedback software for each simulator and each consumer of the simulation
results.
MIFT Demonstration Plan (draft)
Plans for the November, 1996 Exercise Management Demonstration.
Prepared October 4, 1996 by Ted Linden
The Stanford University MIFT project will demonstrate a mediator-based
software arch[Bitecture for the Exercise Analysis and Feedback phase of the
training cycle.
Figure 1: MIFT three level architecture
The demonstration will show progress toward two key goals:
- Eliminate software learning time for typical trainees, commanders,
and others who use the analysis software only occassionally.
- Dramatically reduce the technical knowledge required to extend the
capabilities of analysis software and tailor it to local needs. This goal
will eliminate most needs for contract programming when extending the
analysis software, modifying it for additional consumers of simulation
results, or transferring it for use with a new simulator.
MIFT achieves the first goal by exploiting knowledge about the scenario
objectives and the task and subtasks to be trained. Mediators use this
scenario knowledge to relate simulation results to the objectives and tasks
to be trained. Trainees, commanders, and O/Cs, can query the simulation
results using scenario-based terminology. These users will select a
training task, subtask, or standard and the software will respond with a
display of the evidence relevant to that training goal. For example,
rather than forcing the O/C to conceive and formulate the query to "select
all enemy detections of Alpha company before it began its attack," the O/C
will simply ask whether Alpha company achieved its scenario subtask of
remaining hidden until the beginning of the attack. A mediator will know
that enemy detections before the attack are evidence that the unit was not
successful in remaining hidden.
The MIFT mediation architecture combines plug-in components at three levels:
- User interfaces that accept information from mediators and provide
a standard set of display options.
- Mediators that use scenario-based knowledge to analyze, transform,
query, and present simulation results. Each mediator is a relatively small
component. Domain experts extend the analysis functionality by adding
domain knowledge to mediators or by plugging in additional mediators.
- Wrappers that are changed to connect MIFT with the output formats
of additional simulators.
The MIFT user interface for the November demonstration is built on Web
browsers since most users are soon likely to be familiar with a browser.
The MIFT user interface can run at any location that supports Web browsing;
the user does not have to download all the simulation data. An innovation
of the user interface is that it is designed to display information
received from mediators in varying formats so that new mediators can be
added without requiring that a new scripts be written to display the
information from each new mediator.
The November demonstration will be instantiated with a small initial set of
mediators. Initial mediators will generate comparative information about
detections, firings, and kills over time for selected units. An additional
mediator will generate force-on-force ratios over time for selected units.
And mediators will know about several of the training tasks and subtasks
and how to find information relevant to evaluating a units performance on
that task.
Once the basic infrastructure of the MIFT architecture is in place, the
goal will be to show that MIFT functionality can be expanded rapidly by
adding additional mediators. Mediators are currently written in Clips 6.0,
a widely-available expert system shell. Since user interface functions and
data access functions are separated out into other components, the mediator
implementations are quite small. For example, the force-on-force ratio
computation for any set of units is only 10 lines. Most other mediators in
the initial demo are smaller. We believe that some domain experts will be
able to write mediators in Clips; however, we also plan to provide
alternative means of writing mediators.
The demonstration will use four kinds of mediators:
- Conflict resolvers identify and deal with inconsistencies and
anomalies in the underlying data. Our experience is that data from
simulation results are seldom free of anomalies. Our approach is to
identify and deal with these problems explicitly. By having mediators that
focus on handling anomalies in the data, we have found that we can
dramatically simplify the implementations of other mediators; for example,
one of our mediators assumes that a unit that is fired at or killed is an
enemy. Friendly fire is an anomaly with respect to this assumption, and
instances of friendly fire are dealt with by a separate mediator.
- Maintenance rules. TBD
- Reporting agents travers the knowledge base and assemble formatted
structures to be passed to the user interface. These reporting agents
provide the mainstream functionality that is visible during the
demonstration. These are usually implemented as simple Clips statements of
the form "Do-for-all-(object-)instances [selection criteria] [action].
Figure 2: MIFT agents around a central object base.(to come)
- Object deletion agents. These agents clean up objects that are no
longer needed by the system.
MIFT uses wrappers to isolate the mediators from the specific data formats
and other differences between simulator outputs. Wrappers are written in
C++. When a mediator needs additional information, it calls the
appropriate wrapper. The wrapper accesses the data and creates instances
of the appropriate Clips objects. We have implemented a wrapper that
processes the outputs of Janus simulation runs, and plan to implement a
wrapper for LEAF formated data from SimNet results. The latter may or may
not be completed by November. We believe that MIFT functionality can be
made available for additional simulators by writing the appropriate wrapper
to process that simulators outputs. Writing additional wrappers requires
programming expertise, but it is not a major undertaking. Of course, using
MIFT on a different simulation may also require additional mediators and/or
user interfaces to provide new functionality appropriate for that
simulation. For example, the mediator that create force-on-force ratios is
more useful for simulations at the battalion or higher level and would not
have been developed for analysis of simulations at the company level.
The MIFT architecture is also intended to allow analysis and evaluation
software to be reused by all of the different consumers of simulation
results. In addition to trainees, O/C, and commanders, others who need to
analyze and evaluation simulation results include exercise planners,
training managers, weapons designers, tactics developers, and doctrine
writers. MIFT can also provide results directly to other software; for
example, software used to assist in exercise planning and preparation can
use MIFT analyses of previous exercises to identify the tasks and subtasks
that can become the focus of additional training. Thus MIFT contributes to
completing the feedback loop from the results of one simulation run into
the planning and preparation for future training.
Back to LIC overview.
