digital watch zee
  • Radical productivity gains in systems integration and test
  • Extremely rapid test tool development
  • View, edit and send messages in a human-readable format
  • Log incoming and outgoing messages
  • Create sequences of outgoing messages you can play, pause and stop
  • Write MiCL scripts to customize your emulation


Click on a title to display its description.

The Mimik™ Application Suite

The Mimik™ Application Suite is a software suite developed by ArcAxis, LLC.  It 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 message interface monitors.  

The Mimik™ Application’s ability to read an Interface Control Document (ICD) is the central, critical feature that enables this revolutionary productivity gain.

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

Embedded System

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.

Interface Control Document (ICD)

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.

ICD Editor

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. 


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.

Message Type

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 Element

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

Transport Method

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

How do I know if the Mimik™ Application Suite is applicable for my project(s)?

1) Does your company develop software, systems, and/or devices that communicate using one or more of the protocols that Mimik™ supports?
  1. UDP
  2. TCP
  3. CAN
  4. J1939
  5. MIL-STD-1553
  6. Serial communications: RS-232. RS-422, RS-485
If your answers include either CAN, J1939, MIL-STD-1553 or Serial, then your company 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 company 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.