Introduction to the Mimic Application Suite

Overview

The Mimic Application Suite is protected under U.S. Patent No. 7,280,955.

The Mimic Application Suite enables you to create, deploy and use a messaging interface emulator or monitor application extremely rapidly, with little or no software development effort. Typically, the suite can decrease the development time of such emulators and monitors by a factor of 5 to 20. Messaging interface emulators and monitors are custom test tools that engineers use to test the systems they develop.

The Mimic Application Suite enables engineers to compress 80% to 100% of the development task normally undertaken to develop an emulator or monitor down to the mere clerical task of creating an Interface Control Document (ICD), which describes the binary formats of messages passed between two or more systems. Mimic reads this ICD, and then uses it to configure itself to encode human-readable data into the appropriate outgoing binary message format, and decode incoming binary messages into a human-readable format. Since software developers often spend months developing emulators and monitors during system development, integration and testing, using Mimc can offer projects significant savings.

Mimic can emulate the messaging interface of virtually any computer system that communicates with other computers in a binary format. (Mimic was not designed to emulate text-based protocols, such as FTP or HTTP). Embedded systems are typically good candidates for testing with Mimic, since they typically communicate with other systems using binary message formats, though there are exceptions. Examples include:

Military avionics and electronic warfare systems such as:

Radar warning receivers
Chaff/flare dispensers
Jammers
Missile warning systems
RF flight environment simulators

Handheld GPS devices
Wireless networking devices
Computer chips embedded in cars
Manufacturing process control
Other examples abound

Currently, Mimic can emulate systems that communicate using their own protocols (defined in an ICD) using either TCP, UDP, COM/Serial ports, or the MIL-STD-1553 protocol.

Applications

The suite contains three applications, each described below.

Mimic

Mimic serves as the flagship for the suite. Using information inside an Interface Control Document (ICD), Mimic configures itself into the emulation or monitoring solution you require. With Mimic, you can send and receive data to and from your system(s) under test, all in a human-readable format. Mimic contains the following primary features:

Automatically encodes outgoing message data from the human-readable format you define into the binary message format described in the ICD when sending messages.
Automatically decodes incoming message data from the binary format described in the ICD to a human readable format for display.
Customization with user-defined "MiCL" scripts to control the emulation. MiCL consists of the entirety of the TCL, an industry standard, commercial quality scripting language, plus almost 300 Mimic-specific extensions that form the MiCL API. These extensions enable your scripts to:

Output text in Mimic's GUI

Get and set message data

Send messages

Wait for and respond to internal Mimic events, such as

Sending a message

Receiving a message

Implement "Custom Streaming" protocols

Creating and playing sequences of outgoing messages

Controlling and accessing Mimic's Message Log
Share data with other MiCL scripts
Get and set shared data from other MiCL scripts

Log any or all incoming and outgoing messages, all in a human-readable format.
Play, pause and stop sequences of outgoing messages that the user defines in a human-readable format.
Customizeable messaging behavior through "Behavior Objects," which are created by the ICD Author and implemented by a software developer. Normally, it's better to use MiCL scripts for this purpose, but for very high-performance customization, Behavior Objects may be a better option.

For more information, please see the Introduction to Mimic topic.

ICD Editor

The ICD Editor enables a user to create and edit Interface Control Documents in a visual manner. It hides all the details of how to format an ICD file, making ICD development a much easier, user-friendly task.

For more information, please see the Introduction to the ICD Editor topic.

Mimic Customization Wizard

This small application generates Visual C++ 6.0 projects, each complete with skeleton source code and project files, so a developer can create customization modules that can plug-in to Mimic. Usually, the ICD Author invokes this application from within the ICD Editor. Only rarely will it be invoked from the Start Menu. For more information, see the Custom Streaming DLL and Behavior Object DLL definitions, as well as the Mimic Customization Wizard topic (not that this is not a seperate section, but is part of the ICD Editor help documentation).

The Process of Developing an Emulation or Monitoring Solution

The process of developing an Emulation or Monitoring solution generally follows this sequence:

The ICD Author, using the ICD Editor, creates the ICD.
If necessary, the ICD Author, using the Mimic Customization Wizard, generates any necessary skeleton C++ projects that will create DLLs that can "plug into" and customize Mimic. Note that many projects will not require such customization, particularly monitoring solutions.
A software developer implements any projects created in step 2. Note that if step 2 is not necessary, this step is not necessary.
The Solution is now ready for the Mimic user.

Note that three roles were mentioned: the ICD Author, the Developer, and the Mimic user. All three can be the same person, though this may not be the case.

Why use Mimic?

The Need for an Emulator During Development, Integration and Test

Imagine developing a system with two components that communicate using data messages passed over a network or databus.

2 Components sending data messages to each other

2 Components sending data messages to each other

Two Communicating System Components

When testing Component A while it is under development, it beomes obvious that we will need Component B to

Stimulate Component A with incoming messages and
View and log it's outgoing messages.

However, very often Component B will not serve as a useful test tool. Any combination of the following reasons can cause this:

Perhaps Component B doesn't have a user interface, such as an avionics system on a military aircraft.
Perhaps Component B doesn't offer the level of control of its messaging interface needed to test Component A adequately.
Perhaps Component B doesn't even exist yet, since it is under development in parellel with Component A.
Perhaps Component B exists but has not reached a high enough maturity level to have been thoroughly tested itself, so it cannot yet be trusted to be used to test A.

Given any of these possibilities are true, it becomes clear that the team developing Component A will need to develop a desktop application that emulates the messaging interface of Component B. This emulator must stimulate Component A with incoming messages, and display and log it's outgoing messages. An important feature of these emulators is that message data is presented to the user in a human-readable format, but the messages are transmitted in the binary format described in the ICD. The emulator encodes outgoing message data from a human-readable to binary format, and decodes incoming messages from their binary format into their human-readable format.

Using the Mimic Application Suite, the team developing Component A can develop an emulator of B much more rapidly, typically by a factor of 5 to 20. These savings in engineering hours can multiply across development projects that require such emulators. Also, development projects that wouldn't have otherwise used emulators because they are cost-prohibitive can now benefit from Mimic as well.

Mimic Emulating Component B, Testing Component A

The Need for a Monitor During Development, Integration and Test

When Component A and the "real" Component B finally start communicating with each other during testing, the test engineer often finds it advantageous to monitor their communications. This gives the engineer visibility into exactly how the two components are communicating, exposing problems and aiding debugging. Mimic can serve this need as well, decoding binary message data into a human-readable format using an ICD. In this type of use case, Mimic doesn't send any data at all, and only silently listens in on the communications between Component A and B.

Mimic Monitoring Messages Passed Between Component A and B

Where to go from Here

Included as part of this help documentation are several conceptual topics that describe concepts and terms that are unique to the Mimic Application Suite. The Mimic user should be familiar with some of the concepts in the Essential ICD Concepts topic, including Components, Message Types and Fields. ICD Authors, on the other hand, should be intimately familiar with the Essential ICD Concepts topic as well the following related topics:

If you plan to control their emulation through scripting, you will need to get familiar with the The MiCL API. If you don't have a background in TCL, here are some external links to get you started.:

After familiarizing him/herself with these topics, the ICD Author should start at the Introduction to the ICD Editor topic to begin learning to use the ICD Editor application. Alternatively, start with the ICD Editor tutorial <<LINK>> (This is not complete yet - 8Apr2007)..

Mimic users should start at Mimic GUI Elements and Features topic to begin learning to use Mimic. Alternatively, start with the Mimic tutorial <<LINK>> (This is not complete yet - 8Apr2007).

When using Mimic or the ICD Editor, the user can bring up context-sensitive help topics in this documentation through pressing the F1 key. Both apps have the smarts to bring up help for the view or widget the user is working in. "Help" buttons are also commonly provided in most dialogs.