Mimic FAQ Trinidyne Systems, LLC

What is Mimic?

Mimic is a desktop software application that serves as an engineering test tool. It can best be described as a "universal messaging interface emulator."

Mimic automates common test tool development tasks during the development of systems, devices or software.  Specifically, using Mimic, you can develop emulation and monitoring test tools extremely rapidly. See below for more information on emulators and monitors. (These terms can mean different things in different contexts.  See the rest of the FAQ for what these terms mean in Mimic's context.)

Mimic is protected under U.S. Patent 7,280,955, and runs on Microsoft Windows operating systems.

Trinidyne encourages you to read this FAQ sequentially, since dependent concepts are presented in order.

Why Use Mimic?

Mimic can collapse the time to develop custom emulators and monitors by a factor of 5 to 20. This saves tremendous amounts of expensive engineering hours for your organization.

What kinds of systems can Mimic test?

Generally, any system that meets the following criteria:
  1. It communicates with other systems, devices or software programs using binary-formatted messages (as opposed to text-based messages many common commercial protocols use, such as HTTP)
  2. These binary-formatted messages are transmitted using one of the four following protocols
Generally, "Embedded Systems" are good candidates to test with Mimic. These include, but are not limited to:


What do you mean by "Emulator," and why are emulators important?

An emulator is a test tool developed to transmit and receive messages to and from your system-under-test. It "emulates" one or more systems that talk to your system-under-test in a manner where your system-under-test can't tell the difference between the real system and the emulator. Most importantly, an emulator can stimulate your system-under-test with incoming messages in the expected format, and receive messages transmitted from the system-under-test in the expected format.

To clarify, let's walk through an electronic warfare system scenario.

Let's say our engineering team is charged with developing a Chaff and Flare Dispenser (CFD) for a jet fighter. Another company is simultaneously developing a Missile Warning System (MWS) for the same aircraft, and the two systems have to communicate with one another. Our two companies must agree an an interface between them - that is, the messages passed between the two systems, and the formats of those messages. Such an agreement is always specified in an Interface Control Document (ICD).

The ICD states that the MWS will send the CFD a "Dispense" message whenever it senses a missile is in the air. It also states that the CFD will regularly send a "Status" message to the MWS, indicating how many bundles of chaff and flare it has available.

To test our CFD's response to the Dispense message, we need to develop a emulator of the MWS, which will stimulate our CFD system with the incoming Dispense message. This allows us to verify that our system actually dispenses the requested amount of chaff or flare. Likewise, this emulator should receive and display the Status message from our CFD, so we can make sure our CFD is sending the correct data.

Normally, such an emulator is embodied in a software application running on a desktop or laptop computer.  

Thus, we can test our CFD without needing the "real" MWS. This is very important, since the real MWS probably wouldn't serve as a good test tool for the following reasons:
To make it easy to use, this emulator should display each message's data in a human-readable format, despite the fact that the message formats are binary. So one of it's main tasks is to encode outgoing message data from text to binary, and decode incoming message data from binary to text.

Another useful feature might be logging the message data that is sent and received from/to the emulator. The log can be sent to the GUI, or to a file.

Many other useful features are common in such emulator applications, but are beyond the scope of this FAQ.

Traditionally, such emulators are developed to emulate one and only one system (the MWS in this case). To emulate another system, the organization must incur the same development cost all over again.


What do you mean by "Monitor," and why are monitors important?

Monitors are engineering test tools that silently "listen" to the communications of two or more systems, devices, or software programs.

Continuing our Chaff-Flare scenario from above, a monitoring tool would listen in and log the messages passed between the CFD and the MWS, but wouldn't transmit any messages on it's own.   Typically, monitors would be used after you've used a MWS emulator to test the CFD (and vice versa), and you begin integrating the real CFD and MWS systems together.

Monitors can be very important tools, since they provide visibility into the data passed between the systems you are integrating.  This becomes essential when testing and debugging.

As in the case of emulators, monitors should ideally be human-readable, displaying the binary message data captured in a human readable format.  There are COTS monitoring tools that can be purchased commercially, but since they have no knowledge about the ICD, they are not human readable, and users are stuck reading hexadecimal-formatted data.  Like emulators, human-readable monitors must undergo custom software development  - until now.


So what's special about Mimic?  How does it help develop emulation and monitoring solutions 5 to 20 times faster?

Typically, about 80% of the software processing done by emulators and monitors is related to the ICD.  This insight creates a tremendous opportunity: rather than traditionally develop one custom emulation or monitoring application per system, as described above, Mimic consumes a (properly formatted) ICD.  Using the ICD's information, Mimic configures itself to emulate one or more of the systems defined in the ICD, and is then able to:
All this with exactly zero software development effort.  In many cases, Mimic can compress months of development time into days or hours.

Best of all, this time savings can be repeated with each emulation or monitoring solution your organization needs.
 
Mimic superimposes a large palette of important features on top of this core encoding/decoding functionality.  These features enable the user to:
It is envisioned that MiCL scripts will be used primarily for implementing what we at Trinidyne call "messaging behavior."  For example, if the protocol requires Mimic to transmit an acknowledgement message immediately after receiving a data message, you can implement this behavior using a MiCL script.  In particular, for this example, you would use the MiCL API to:
We mentioned above that developing the ICD typically takes care of 80% of the tasks that a traditionally-developed solution would require.  As an approximation, implementing your own MiCL scripts takes care of the remaining 20%.  This 80/20 ratio will vary with each solution you implement.  Some solutions will require more scripting than others, and some ICDs will be larger than others.  Interestingly, many of your monitoring solutions may not need any scripting at all since monitors are generally silent.  In this case, you can accomplish 100% of the development task by simply defining the ICD.

The diagram below illustrates how using Mimic collapses emulator and monitor development efforts.


Development Task Comparison

Development Task Comparison

The table below contrasts developing emulation and monitoring solutions the traditional way with developing them using Mimic.
Traditional Emulators and Monitors Mimic
Re-use One custom application per emulation or monitoring solution One application suite (Mimic and the ICD Editor) for all emulation and monitoring solutions
Expertise required Low-level software engineering (ex: C/C++)
  • ICD definition, a clerical task supported by the ICD Editor
  • High-level scripting (software expertise helps, but not required)
Schedule Months of development effort Days or hours of development effort.
Budget Software engineer required Software engineers unnecessary - less skilled/lower-paid technicians can use Mimic and the ICD Editor


How do I format the ICD properly so Mimic can read it?

You will never have to expose yourself to the details of how the ICD file is formatted.  Instead, use the ICD Editor to create and edit ICDs.  The ICD Editor is a Windows application that is installed alongside Mimic.  In fact, for ease of use, you can easily launch Mimic from the ICD editor, causing Mimic to consume the ICD you currently have open.

The ICD editor allows you to create and edit ICDs visually, and hides all the ICD formatting details for you.  Any ICD you create with the ICD Editor will be consumable by Mimic.


Do you have screen shots of Mimic and the ICD Editor?

Of course.  There's plenty below to give you a sense of Mimic's look and feel, as well as it's capabilities and power.  Same for the ICD Editor.  Note that these screen shots are only a sample of all the views and dialogs in Mimic and the ICD Editor.

Mimic Messages Tab

Mimic's Messages Tab, showing the current state of each of the ICD's message types.


Mimic Logging Tab

Mimic's Logging Tab, showing some recorded messages.


Mimic Sequences Tab

Mimic's Sequences Tab, showing an outgoing message sequence (currently stopped).


Mimic MiCL Scripts Tab

Mimic's MiCL Scripts Tab, showing a running MiCL script.  The script randomly picks an outgoing message, sets it's field data to random values,  and sends the message.  Note the "$API SetMsgToRandom" and "$API SendMsg" calls to the MiCL API.  Note also how the text in the "$API OutLine" command appears in the window below the script editor.



ICD Editor Message/Struct Object View

ICD Editor Message/Struct Object View.  Field rectangles can be moved around and rubber-banded to grow and shrink (sort of like PowerPoint objects).


ICD Editor Component Object View


ICD Editor Component Object View, showing information about a particular component's UDP socket.
Field Length Properties Numeric Properties Page Field Enumeration Page
Various pages of the Field Wizard, used to define a field in a message.