MEDIATION TO IMPLEMENT FEEDBACK IN TRAINING

--- M.I.F.T. ---

MIFT Applied to Military Exercise Management

The initial application area for Stanford University's project on is the Exercise Analysis and Feedback phase of military exercise management. So far we have focused on simulation-based army training exercises.

MIFT processes the data that is logged during training exercises and uses scenario information and domain knowledge to organize the data from the exercises in ways that are meaningful and useful for O/Cs, trainees, commanders, exercise evaluators, and others interested in the results of training exercises. MIFT is also designed to feed information to other software systems that generate training scenarios and help commanders plan future training exercises tailored to the needs of their trainees.

Figure M-1: MIFT's mediators supplement the flow of information from simulations to evaluation and review and complete the feedback loop by supplying information to plan and tailor future training exercises.

MIFT's mediators handle some of the information flows involved in training exercise management. An overview of information flows is shown in Figure M-1. MIFT is designed to integrate with other evolving army exercise management software as illustrated in Figure M-2.

Figure M-2: MIFT can interact with other army exercise management software and support the many customers and uses of exercise result data.

Figure M-2 illustrates the many different consumser of simulation results and the rolls that MIFT can play by implementing reusable mediators that aggregate, summarize, and analyze simulation results and deliver them to various consumers in terms tailored to their individual needs.

MIFT Application Goals

MIFT seeks to achieve two key application goals for military exercise feedback software:

1. Since trainees, O/Cs, commanders, exercise evaluators, and weapons evaluators seldom have time to devote to learning to use exercise feedback software, the software must be easy to use and not force them to learn computer concepts rather than their normal domain concepts.
2. Domain experts must be able to extend feedback software and tailor it to domain-specific and local needs. Neither professional programmers nor sofware development contracts should be required to extend the feedback analyses, modify them for additonal consumers, and use them with additional exercises.

Mediators will achieve the first goal by incorporating 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 scenario-based terminology. For example, rather than forcing the O/C to formulate a query to "select all enemy detections of Alpha company before it began its attack," the O/C can 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 the needs of exercise planners, weapons designers, tactics developers, and other consumers of simulation results.

The second goal of the mediator-based architecture is to enable military training and support personnel to tailor and extend analysis and feedback software to meet there own local needs. The goal is to dramatically reduce the amount of contract programming needed to develop analysis and feedback software for each simulator and each consumer of the simulation results.

MIFT Architecture and Technical Approach

A mediator is a software module that exploits encoded knowledge about certain sets or subsets of data to create information for a higher layer of applications. It should be small and simple, so that it can be maintained by one expert or, at most, a small and coherent group of experts. -- Wiederhold, IEEE Computer, March, 1992 .

For a generic presentation about mediation architectures, click . [Gio's Mediation Architecture presentation].

The first step in developing a mediation architecture for training feedback is to isolate the mediators from lower level data sources and from higher level user interface and application code. The role of mediators as reusable middleware is shown in Figure A-1.

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.

Interfacing to MIFT

The current MIFT user interface 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.

We propose to use standard knowledge exchange and communications protocols based on KIF/KQML so that mediators can work with data from multiple sources and supply information that is reusable in multiple roles.

A key benefit of mediators for military training applications is that they avoid each simulation program having to build from scratch and maintain a separate set of analysis and feedback software packages.

Mediators interact with each other through the standardized knowledge exchange and communications protocols. The implements elements of the first three levels of the mediation hierarchy shown in Fig. A-2. The lower level mediators perform standard accumulations, selections, and analyses on the data sources. They provide their results both to user interface code and to higher level mediators. We had to implement these lower level mediators first to provide a basic level of functionality for the higher level mediators. The third level of mediators, for which there are illustrative examples implemented in the current demonstration, use knowledge of the training scenario so that O/Cs and trainees can obtain feedback about how well specific scenario tasks have been performed. These mediators allow users to obtain specific feedback without having to understand the structure of the underlying data. Our planned fourth level of mediators will use domain-specific models about the exercise, the scenario, and causal relationships in the exercise to analyze the data for its probable significance and automatically call the users' attention to what it perceives as the more relevant exercise results.

Figure A-2: Mediators support multiple applications of feedback.

Within each level of the mediation hierarchy shown in Figure A-2, multiple mediators may collaborate to produce the desired results. The collaboration among mediators at the same level is well described.

It is useful to think of mediators as composed of three parts as illustrated in Figure A-3:

Figure A-3: Typical mediators are a combination of components that interface to data sources, represent domain knowledge, and draw inferences from the internally represented data and knowledge.

1. Data sources are converted into object instances over which inferences can be performed.
2. Knowledge about the application domain is maintained in declarative representations.
3. An inference engine processes the knowledge and data sources to produce higher level knowledge that is passed to other mediators or to the user interface in a standardized form.

This page and related demo are maintained by David Maluf.