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


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.


This is the language used to communicate with the mediator in either direction. Example, a user might specify a mediator name (e.g. force-ratio) or put a query directly (not implemented yet). The user should specify the simulation number. In return the mediator reply will the full report including the content, axis names and description etc.. Some fields might not written and depend on the mediator result.

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.

 :TO            static and
 :MEDIATOR      force-ratio
 :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))

The sample query shown below results in the kills event of units which are already killed. The output of that query is a time field and all related details of the unit.

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 Programmable Mediatior)

This proposed achitecture is meant for systems that can sustain first order logic inference engines: A forward or backward chainer, a unifyer, a data-base and a knowledge base that accepts knowledge in form of objects, rules and facts. The blackboard is a temporal hypergraph that triggers the hooked agents to it which will peform their assigned tasks in a prioritization sequence.

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

Not all data or knowledge are valid. Some knowledge might be disruptive to the overall operation and can genrally be classifiled under:
  • 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

    Performs the necessary wrapping to maintain a correct syntax for the language in use Hence, templates structures are not violated. This reduces tremendously the amount of data to be loaded versus the amount that will be used. We might have originally a collection of instance events

    ([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 are rule based oriented and are defined the rules that interact with the HYPERGRAPH in function of the user's need.

    Report Agent

    The separation of the report agent is mainly to give its independence from the system. Hence, data can be generated into the remote format and data/knowledge output becomes accessible. The report-agent is activated once an appropriate maintenance rule puts a request.

    This page and related demo are maintained by David Maluf.