MEDIATION TECHNOLOGY

The Stanford University MIFT project will demonstrate a mediator-based software architecture for the Exercise Analysis and Feedback phase of the training cycle. This versions is meant toward two key goals:

1. Eliminate software learning time for typical trainees, commanders, and others who use the analysis software only occassionally.

2. 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 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.

MEDIATION KNOWLEDGE EXCHANGE AND COMMUNICATION PROTOCOL

Up to :FOCUS, the fields are the user's queries and configuration data. :LANGUAGE and below is a typical mediator reply. Notice in this example :QUERY and :MEDIATOR are expressed simultaneously to express the language only and cannot be meant as the same time, typically this will result in two reports.

(:FROM          bigeye.stanford.edu>
 :TO            static and CKNP:earth.stanford.edu:3000
 :SERVER        http://sole.stanford.edu:8080
 :MEDIATOR      force-ratio
 :SIMULATION    JANUS Sim01
 :EXECUTION     2.43sec
 :QUERY         (if (and 
                     (kills ?ins-a:source ?ins-b:target) 
                     (kills ?ins-c:source ?ins-b:target)) then
                   (agent::report ?ins-c:time 
                                  (describe ?ins-c:source)))
 :FOCUS         40 41 43
 :DATABASES     (detection kills shots artillary)
 :LANGUAGE      clips 
 :DEBUGMODE     nil
 :EXECUTION     1.43sec
 :Y-AXIS        "force ratio"
 :X-AXIS        "minutes"
 :DESCRIPTION   [blue] [red] 
 :CONTENT       ((9.4 1.0 0.0)(19.6 1.0 0.0) ...)
 :MESSAGE       (FOCUS on 40 43 is illogical since they are enemy)
 :COMMENT       (This report is bogus and is manually written))

One feature provided by such a representation is the potential of selecting some queries and storing them statically for teaching purposes; a senior officer may perform some abstraction and demsonstrate in his class the results. The main feature is the potential of another mediator that will chose the mediation titles and queries and perform on the results addtional analysis (automated) in function of the scenario (future implementation).

A ONE LEVEL DEEP MEDIATOR: THE COLLABORATIVE VIEW
(A Programmable Mediatior)

Conflict Resolver: Priority 1 . To maintain a the truth values in the system.

Modules: Priority 2 . The processes revolving around the modules rules are launched.

Report Agent: Priority 3 . Reports can be generated after the main requirements are accomplished.

Maintenance: Priority 4 . Once processes have termnated, It is time to clean up after every terminated sequence.

Data Wrapper: Priority 5 . Having the lowest priority since there is no need to introduce new data since all the processes on the previous and current data haven't terminated.

Conflict Resolver

Cyclic: Inference on some knowldge might result in some cylic effects.

Repetetion: Some knowledge might be asserted to the system however with some conflicting contents with prior definitions.

Constrained Space: Some data might be asserted to the system however the truth value of the new knowledge conflicts with prior knowledge.

Data Wrapper

([DETECTIONS-47] of DATA (class detections) (time 21.7498) (source-unit 9) (target-unit 36) (range 4.40604))

([SHOTS-10] of DATA (class shots) (time 23.7498) (source-unit 9) (target-unit 36) (range 3.74032) (x-source 60.9533) (y-source 86.1474) (x-target 57.4887) (y-target 87.5568))

when the interest is inferable, hence we have the time difference from detection to shots is clearly computed.

Modules

Report Agent

This page and related demo are maintained by David Maluf.