The Mimik™ Application Suite consists of two related applications: The Mimik Application, and the ICD Editor.  Both are protected under U.S. Patent No. 7,280,955.

The suite enables engineers to develop test tools for their systems, software and devices extremely rapidly, 5-20 times faster than normal.  These test tools come in two types: messaging interface emulators, and messaging interface monitors.  

First, we'll describe the need for these emulators and monitors during development, integration and testing. Then we'll hone in on the value proposition.

The Need for Emulators During Development, Integration and Test
Imagine developing a system with two nodes that communicate using data messages passed over a network or databus. (Note that Mimik uses the term "Component" as a synonym for "node.")


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, so you can't define the content of its transmitted messages, or control the circumstances under which it transmits messages.
• 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 join the test setup for A.
• Perhaps Component B exists, but it's embedded in a large hardware device such as a radar system on a military aircraft, which is a very expensive and rare asset in the organization, and none can be spared to move into your lab to test Component 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 Mimik Application Suite, the team developing Component A can develop an emulator of B much more rapidly, typically an order of magnitude.



The Need for Monitors 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. Mimik can serve this need as well, decoding binary message data into a human-readable format using an ICD. In this type of use case, Mimik doesn't send any data at all, and only silently listens in on the communications between Component A and B.



The Value Proposition
Mimik™ enables your organization to obliterate most of the software engineering effort involved in developing messaging interface emulators or monitors, compressing their development time, typically by a factor of 5 to 20. This saves your projects money, increases product quality, decreases time to market, increases customer satisfaction, and helps make your bids more competitive.

The Mimik Application’s ability to read an Interface Control Document (ICD) is the central, critical feature that enables such a radical productivity gain in your engineering and development projects. This is why we describe it as a protocol emulator at the application layer, because it understands the message formats used by your application(s) and system(s)-under-test.

The diagram below details this productivity gain. The items on the left are common features that a software engineer has to implement in an emulator or monitor. With Mimik, the software engineer no longer has to develop the blue features - they are automatically generated inside Mimik when the user loads it with an ICD. This represents a vast savings in time and money, typically a factor of 5 to 20. Also note that non-software engineers can perform these GUI-based tasks, loosening up your project's staffing constraints.

You can also compress the time to develop the items on the left in orange through Mimik. Rather than coding these features using a low-level language such as C++, you can script them directly in the Mimik GUI with our high-level scripting language, MiCL (Mimik Command Language).

These savings in engineering and development hours can multiply across development projects that require such emulators and monitors. Also, development projects that wouldn't have otherwise used emulators because they would have been cost-prohibitive to develop can now benefit from Mimik as well.

1) Does your organization develop software, systems, and/or devices that communicate using one or more of the protocols that Mimik™ supports?

1. UDP
2. TCP
3. MIL-STD-1553
4. CAN
5. J1939
6. Serial Ports (RS-232, plus RS-422, RS-485 with converters)
7. GPIB
8. Any protocol whose interface device looks like a Virtual COM Port (VCP) to Microsoft Windows.

If your answers include either CAN, J1939, MIL-STD-1553, Serial, GPIB or VCP then your organization can certainly benefit from using Mimic. If your answers include only UDP or TCP (and none of the others), go to question 2.

2) Regarding your software, systems or devices that communicate using UDP and/or TCP, are the application-level messages “carried” directly by UDP or TCP? Or are they carried by a higher-level commercial protocol such as HTTP, FTP, SNMP, SMTP, or POP3? If the answer is “directly by UDP and/or TCP,” then your organization can almost certainly benefit from using The Mimik™ Application Suite. Otherwise, it would probably not be a good fit for your current needs, since it was not designed as a test tool for such higher-level commercial protocols.  There are exceptions to this rule however, so please feel free to contact ArcAxis with questions.

1. UDP
2. TCP
3. MIL-STD-1553
4. CAN
5. J1939
6. Serial Ports (RS-232, plus RS-422, RS-485 with converters)
7. GPIB
8. Any protocol whose interface device looks like a Virtual COM Port (VCP) to Microsoft Windows.

The message formats you specify in the ICD Editor describe how Mimik should interpret the payload that these protocols carry.

Yes! You may define as many nodes (we call them "Components") as you wish in your ICD with the ICD Editor, and each can use whatever protocol you wish. When you load the ICD into Mimik, you choose which nodes to emulate, which ones to monitor, and which ones are part of your system-under-test (SUT).

One extremely powerful use case of this multi-node, multi-protocol capability involves "round trip testing" of your SUT. For example, if your SUT receives messages over a serial port, processes this data, and then sends this processing output over TCP, you can use Mimik to stimulate it with serial port messages and receive its TCP messages simultaneously, in a single Mimik emulation, and verify the TCP data matches the original serial port data.

Absolutely. You may also want to download our data sheet here.


This screenshot displays a Message Type in the ICD Editor, with a field selected and its parameters displayed on the right in purple, and descriptive comments about the field in blue. Note the Validation View on the bottom displays warnings when two or more aspects of the ICD are inconsistent with one another.



This screenshot displays Mimik's Message States View, which shows the current state of all incoming and outgoing messages for all emulated or monitored Components (e.g. nodes). The user can view and edit message data in a human readable format, or a raw/hexadecimal format. The user can also send outgoing messages from this view manually, and can create graphs of message field values over time (a more sophisticated graphing feature is shown in another screenshot below).



This screenshot displays Mimik's Log View logging data. The blue and yellow table identifies each Message Type received along with its time tag, and shows its message data in a textual, parsed, human-readable format. You can filter out any Message Types from the table you wish with a simple click on the appropriate list item in the lists on the left. You can optionally show each message's protocol header (i.e. IP Addresses and Port Numbers, CAN/J1939 header data, etc). You can also search the log for particular field values, and save the log to various text file formats.



This screenshot displays Mimik's Graphs View. It can display several graphs at a time, each one with as many fields (lines) as you wish. You can scroll in time (left/right), or select "Fit to Window" to see the entire graph within the view's size. You can show x and y dimension guides that snap to data points in response to mouse movements, causing them to show the exact value and time tag or the data point. You can also easily generate a statistics snapshot, displaying averages, mean, median, data rate, and population distributions.



Mimik's MiCL Scripts View enables you to write scripts to control your emulation, particularly its messaging behavior. The MiCL language consists of two components:

• The TCL language in its entirety, an industry-standard, commercial-quality scripting language, and TCL’s associated GUI toolkit, Tk
• The MiCL API, a set of over 400 Mimik-specific extensions to TCL, which enables script writers to:
  • Get and set field data (in a human-readable format)
  • Get and set raw message data
  • Send messages
  • Wait for and respond to incoming messages and other internal Mimik events
  • Create your own GUI using Tk, and hook your GUI events into MiCL API functions
  • Access Mimik’s command line parameters, enabling highly-configurable automated testing
  • Start and stop other MiCL scripts
  • Share data with other concurrently-running MiCL scripts
  • Implement “Custom Streaming” protocols
  • Create and play sequences of outgoing messages
  • Control and access Mimik’s Message Log
  • Output text in Mimik’s GUI

You may create as many scripts as you wish, and run them concurrently. You can configure the scripts to start automatically when Mimik opens and initializes the emulation. Also, increase your productivity by leveraging the source editor's code completion feature for the MiCL API.



Mimik's Sequences View enables you to create sequences of outgoing messages that you can play from any point in the sequence, pause or stop at any time, manually or through a MiCL script. You can generate large numbers of messages automatically through the interpolation feature. You can control the number of times the script loops, or set it to loop infinitely (until you hit the Stop button). You can also configure the sequence to start automatically when Mimik opens the emulation.

Absolutely. Help documentation is included with the Mimik Application Suite, and Mimik and the ICD Editor both support context-sensitive help. You can also see the help documentation online here.

An Interface Control Document describes the formats of all the Messages passed between nodes that are connected by a network or data bus.  Normally, when developing an emulator or monitor, a software developer hard-codes the data structures for each message described by an ICD.  In contrast, the Mimik™ Application reads an ICD, which enables it to emulate virtually any system, software app or device.

Specifically, an ICD specifies in detail how the Mimik™ Application packs outgoing messages from a human-readable format to the binary format the destination expects.  Likewise, it also specifies how Mimik™ parses (or unpacks) incoming messages from their binary format to a human-readable format

ArcAxis provides the ICD Editor, Mimik™’s sister application, which enables you to create and edit ICDs in a visual, user-friendly manner.  The ICD Editor guarantees that the ICDs you create will be in the format Mimik™ expects, without you ever having to worry about formatting considerations.

Below is a screenshot of the ICD Editor.

Yes! Both Mimik and the ICD Editor support bit packing.

What do we mean by this? Sometimes, a message field might start on a bit offset rather than an even byte offset. Also, a field's bit length might not be divisible by 8. In principle, a field can start on any bit offset, and can be any number of bits long. For example, in the ICD Editor you could define a 59-bit integer field that begins on bit offset 3. You will probably never see an example this extreme, but it does exhibit Mimik's bit packing flexibility.

For a more reasonable example, consider a set of 3 bit flags in a single byte, followed by 5 unused bits. In the ICD Editor, you can define 3 BOOLEAN fields, one per bit flag, and then add a 5-bit "unused" integer field after them. The ICD Editor automatically arranges these fields in a bitwise-contiguous manner. After reading this ICD, Mimik will encode/decode these fields properly.

Yes! Both Mimik and the ICD Editor support dynamic message formats.

What do we mean by this? Sometimes, a message may contain a field whose value determines the format of the rest of the message. These are considered "dynamic" message formats. Four constructs, each of which you can define in the ICD Editor, support dynamic message formats:

• Structs serve as containers for other message elements, such as Fields, Pivots, Repeaters and other Structs. They also serve as building blocks for two other dynamic message constructs, Pivots and Repeaters. See the Struct section below for details.


• Pivots enable you to associate the value of a message field with a particular Struct to superimpose over a later segment of the message. Different values of that field superimpose different Structs. See the Pivot section below for details.


• Repeaters enable you to specify a message field whose value determines how many times a Struct repeats in a later segment of the message. See the Repeater section below for details.


• Self-terminated Fields enable you to specify a message field whose length changes, depending on the location of a terminator. For example, a string field might have a null terminator, or a newline terminator. In the latter example, the string field would contain a single line of text. You can specify any sequence of bytes for a field's terminator in the ICD Editor.

Note that these constructs are "infinitely hierarchical." For example, a Struct can contain one or more Pivots, each of which can contain one or more Structs, which can contain one or more Repeaters, which can contain one or more Structs, which can contain one or more Pivots, etc.

A good question, with a good answer. First, lets define the problem, then Mimik's solution.

We can divide the protocols Mimik uses into two camps: datagram-oriented and stream-oriented. UDP, MIL-STD-1553, CAN and J1939 are datagram-oriented. TCP, Serial Ports and GPIB are stream-oriented. The difference involves how the receiver knows when it has received a complete message. In datagram-oriented protocols, one receive operation against a socket or device results in one and only one message. In stream-oriented protocols, one receive operation might result in a complete message, but it also might result in a fragment of a message, or a single complete message plus a fragment of the next, or several complete messages, etc. As a result, both sender and receiver must agree an a way to encapsulate complete messages within a stream of data.

Mimik and the ICD Editor support two constructs which together specify this "encapsulation agreement:"

• Datagram Boundary Finders (DBFs) examine a receiver's incoming data stream and identify full messages (datagrams) inside it. They operate only on the destination (not the source). The ICD Author must associate a DBF with a Component (e.g. node) that uses a stream-oriented protocol. The ICD Editor enforces this rule.


• Stream Stuffers modify the outgoing data stream on the source side to encapsulate a single message, and de-encapsulate the message on the destination side. HDLC represents a good example. HDLC prepends and appends a 0x7e delimiter byte to the message data, and escapes any intervening 0x7e. The ICD Author can specify an HDLC Stream Stuffer in the ICD Editor that performs this delimit-and-escape functionality. Many encapsulation schemes do not require stream stuffers. For example, an encapsulation scheme that includes a length field before the rest of the message data. The Streaming Wizard in the ICD Editor helps you make this decision.

A system that has a computer "embedded" within it, which controls or otherwise accesses other hardware components of a system.  Examples include avionics systems on commercial and military aircraft, GPS devices, the computers in your car, cell phones, and even PDAs.  Desktop and laptop computers are not considered to be embedded systems.

The Mimik™ Software can emulate or monitor the messaging interface(s) of your embedded systems. Embedded systems are generally good candidates for testing with Mimik™ because they typically use communications protocols that the Mimik™ Application Suite supports.  However, it’s certainly possible that the Mimik™ Application Suite can develop test tools for desktop apps as well.

An emulator, or more specifically a "messaging interface emulator," is a software application that serves as an engineering test tool during system development and integration.  Consider an F-22 fighter jet, where it’s Missile Warning System (MWS) must communicate with it’s Chaff/Flare Dispensor (CFD) over a databus.  The MWS must transmit a “Dispense” message to the CFD when it senses a missile, and the CFD must regularly transmit a “Status” message to the MWS.  To test the CFD, engineers may need to develop an emulator of the MWS.  The MWS emulator accomplishes the following:

• Communicates with the CFD in exactly the same way as the "real" MWS would.  This includes using the same message formats, message timing and call-and-response messaging behavior.
• Enables the user to define outgoing message data in a human-readable format, and encodes the data into the appropriate binary message format.  This enables the test engineer to stimulate the CFD with an incoming Dispense message transmitted from the MWS emulator.
• Decodes the incoming binary message data into a human-readable format and displays it to the user.  This enables us to view the content of the Status message transmitted from the CFD.

Other features may include:

• Logging the incoming and outgoing message data to the display and/or a file.
• Enabling the user to create sequences of outgoing messages that can be played, paused and stopped at the user's discretion.
• Enables the user to store predefined outgoing messages so the user doesn't have to define the same message data over and over again.
• Implements the “messaging behavior” correctly.  For example, if the CFD reports it’s Chaff stores are empty, the MWS Emulator should only include Flare dispense requests in the next Dispense message.

The Mimik™ Application serves as a universal messaging interface emulator.  Mimik™ claims to be universal because it can read an Interface Control Document (ICD), and thereby configure itself to transform human-readable data to binary message data and vice versa.  The user can then customize their emulation by using MiCL scripts.  Usually, engineers develop emulators to emulate only one Component, or node, of a system.  If they need to develop another emulator, they start from scratch.  In contrast, Mimik™'s ability to configure itself with an ICD enables it to emulate the messaging interface of virtually any system, software app or device.

In contrast to its emulation capability, Mimik™ can also serve as a universal messaging interface monitor.

A monitor, or more specifically a "messaging interface monitor," is a software application that serves as an engineering test tool during system development and integration.   Often during integration and test activities, engineers find it useful to monitor the messages passed between two or more components.  Monitors serve this purpose.  Consider our Chaff-Flare/Missile Warner example from above.  A monitor would silently capture, display and log the Dispense and Status messages passed between the CFD and MWS.

To display captured data in a human-readable format, engineers must program their monitors to decode the captured binary message data into a format the user can read.

The Mimik™ Application can serve as a universal messaging interface monitor.   Mimik™ claims to be universal because it can read an Interface Control Document (ICD), and thereby configure itself to transform any kind of binary message data into a human-readable format.  Mimik™'s ability to configure itself with an ICD enables it to monitor virtually any system whose components communicate using binary message formats.

In contrast to its monitoring capability, Mimik™ can also serve as a universal messaging interface emulator.

The ICD Editor is Mimik™’s sister application, which enables you to create and edit Interface Control Documents (ICDs) in a visual, user-friendly format. 

Below is a screenshot of the ICD Editor.

In ArcAxis’ terminology, a Component is what is normally termed a node.  Components are the entities defined in your ICD that transmit messages to each other over a network or data bus.  When the Mimik™ Application reads the ICD, you select which Component(s) you want Mimik™ to emulate.  The ones you don’t emulate should be the “real” systems, software or devices that you are using Mimik™ to test.  After reading the ICD, Mimik™ can transmitt and receive messages to/from these “real” components.

Imagine our Chaff-Flare/Missle Warner example from above.  Both the MWS and the CFD would be components in your ICD.  When Mimik™ reads the ICD, you can tell it to emulate the MWS, so it can test – that is, transmit and receive messages to/from – the “real” CFD.

A Message Type specifies the format of a particular kind of message.  For example, in our MWS/CFD system, the MWS transmits a “Dispense” message to the CFD.  The Dispense message contains data items, or “fields,” that specify how much chaff to dispense, how much flare to dispense, which side of the aircraft to dispense them from, etc.  When you define this Message Type in the ICD, you would specify the order of these fields, their data types, their lengths, and other attributes.

Message Elements make up a Message Type.  There are four types: Fields, Structs, Pivots and Repeaters.  The simplest and most common of these are Fields.  The others enable you to create complex, dynamic Message Types. 

A Field is one of the Message Element types the Mimik™ Application Suite supports.  A field is a particular data item in a Message Type.  Fields have a name, a data type, a bit length, a bit offset (it’s location in the Message Type) and many other attributes.

The data type plays a central role in how Mimik™ transforms the human-readable displayed value into the binary value encoded into a message (and vice versa).  The Mimik™ Application Suite supports many different kinds of data types for fields.  They include:

• Signed and Unsigned Integers (1-64 bits)
• IEEE-32-Bit Floating Point (float)
• IEEE-64-Bit Floating Point (double)
• Booleans
• Binary Coded Decimals
• Enumerated Types (numbers mapped to a descriptive string)
• Character strings (ASCII and Unicode)
• Hexadecimal (any length)
• IP and MAC address

Usually, Message Types contain fields.  However, Structs can also contain Fields as well.

A Struct is one of the Message Element types the Mimik™ Application Suite supports.  A Struct serves as a container for other Message Elements.  In simple cases, a Struct contains a set of ordered Fields.

Here’s a common example of how Structs come in useful when authoring an ICD: if more than one Message Type shares the same sequence of Fields, define that sequence of Fields once in a Struct, and simply “point” to that Struct in each Message Type.  This is easier than manually creating each sequence of Fields more than once.  Also, any update to the Struct will automatically apply to the Message Types that point to it.

A Pivot is one of the Message Element types the Mimik™ Application Suite supports.  Pivots enable Message Types to have dynamic formats – that is, formats that can change over time.  

At any particular time,a  Pivots points to one of several Structs.  The Struct that it points to depends on the value of a “Pivot Field” that occurs earlier in the Message Type.  Only the Struct that the Pivot is currently pointing to is part of the Message Type.
For example, imagine an embedded computer responsible for displaying telematics data for a car‘s dashboard.  The dashboard contains two sections, the “Speedometer Display” and the “Fuel/Engine Display.”  Imagine a Message Type that the computer may receive (from other embedded computers elsewhere in the car) called “Telematics Data.”  The message may either contain data for the Speedometer Display or the Fuel/Engine Display.  The data fields for both Speedometer and Fuel/Engine are encapsulated in their own Structs.  If the “Telematics Type” field has a value of 0, then the message contains the “Speedometer Display” Structs.  If 1, then the message contains the Fuel/Engine Display Structs.

Example: Telematics Data Message Type:


A Pivot can be contained by either a Message Type, a Struct, or a Repeater (though the latter is very rare).

A Repeater is one of the Message Element types the Mimik™ Application Suite supports.

When a Message Element repeats a dynamic number of times in a message, and the repeat count is determined by the value of a Field, the ICD author must use a Repeater.  

A Repeater contains one original copy of a “Repeating Element.”  The Repeating Element can be either a Struct or a Pivot (typically a Struct).  

The Repeater manages multiple copies of the original Repeating Element, which are aligned contiguously as part of the Message Type.

A Repeater also contains a pointer to a “Repeat Count Field.”  The Repeater determines the number of repetitions by querying the Repeat Count Field for its value.  

For the example below, imagine a handheld GPS device that can report to a laptop the positions of all the GPS satellites that can be utilized to determine the device’s position.  The “Sat Count” field serves as the Repeat Count Field.  In this example, it has a value of "3," indicating that the “Satellite Position” Struct must repeat 3 times.  Note how the “Sat ID,” “Azimuth” and “Elevation” fields repeat 3 times.

Example: GPS Satellite Positions

“Stands for "Mimik™ Command Language."  MiCL is the scripting language Mimik™ users can use to control and customize their emulation.  You create and edit MiCL scripts directly in Mimik™’s GUI, and you can start and stop them at will.  You can even have them start automatically when the emulation opens.  MiCL is an extension of a popular scripting language called TCL, adding over 300 Mimik™-specfic API functions for:

• Getting and setting message field values
• Waiting for and responding to internal Mimik™ events, such as receiving a message
• Sending messages
• Creating and playing sequences of outgoing messages
• Controlling and accessing Mimik™'s Message Log
• Saving logged data.
• Implementing "Custom Streaming" protocols
• Sharing data with other MiCL scripts
• Getting and setting shared data from other MiCL scripts”
• Accessing Mimik’s command line parameters, enabling highly configurable automated testing
• Outputting text in Mimik™'s GUI

A Transport Method is the protocol the ICD author identifies that “carries” the Message Types you define in the ICD from one Component to another.  The Message Types essentially define the format of your Transport Method’s payload.  The term “protocol” in many contexts is synonymous by what ArcAxis means by “Transport Method.”  However, ArcAxis chose to use “Transport Method” instead, since the term “protocol” is applicable at all layers of a protocol stack (Link layer, Network layer, Transport layer, Application layer, etc), and we wanted a term that specifically identifies the layer that transports your application data.

The Mimik™ Application Suite supports several Transport Methods, including:

• UDP
• TCP
• MIL-STD-1553
• CAN
• J1939
• Serial Ports (RS-232, plus RS-422, RS-485 with converters)
• GPIB
• Any protocol whose interface device looks like a Virtual COM Port (VCP) to Microsoft Windows.

The Mimik™ Application Suite can be extended in the future to support other Transport Methods, such as DeviceNet, ARINC-429, etc..  Users are invited to inform ArcAxis of any Transport Methods they would like to see the Mimik™ Application Suite support in the future.