Mimic - PowerPoint PPT Presentation

1 / 17
About This Presentation
Title:

Mimic

Description:

Radical gains in productivity for systems integration... For a typical systems integration project, Mimic ... Serial/COM Port. MIL-STD-1553. Others possible ... – PowerPoint PPT presentation

Number of Views:57
Avg rating:3.0/5.0
Slides: 18
Provided by: josephb70
Category:
Tags: comport | mimic

less

Transcript and Presenter's Notes

Title: Mimic


1
Mimic
  • Radical gains in productivity for systems
    integration
  • Save 25 in engineering test tool development
  • Extremely rapid application development
  • Develop test tools 5x faster

0110111010001
0110111010001
0110111010001
0110111010001
0110111010001
0110111010001
0110111010001
0110111010001
0110111010001
011
0110
0111
2
What is Mimic?
What is Mimic?
  • The Mimic software application is a systems
    development, integration and test tool used by
    engineers.
  • For a typical systems integration project, Mimic
    can save hundreds, perhaps thousands, of
    engineering man-hours
  • Example Mimic replaces an 880-hour emulator
    development project and saves 60,000
  • Business case spreadsheet calculator helps us
    estimate
  • Mimic serves as a universal, human-readable
    emulator and monitor of system components.
  • What does this mean?
  • How does it do that?

3
Communication - Speaking the Same Language
1) Computer systems talk by sending messages to
each other over a network or data bus.
01010101
System 1
System 2
Encode
Decode
Encode
Decode
01010101
ICD (Interface Control Document)
A Geo-location message
5) When receiving a message, a computer must
decode it in a manner compliant with the ICD.
Bytes 0-3
Bytes 4-7
Bytes 8-11
Latitude
Longitude
Altitude
4) When sending a message, a computer must encode
it in a manner compliant with the ICD.
2) Each type of message has a certain structure.
3) The structure of all the messages are defined
in an Interface Control Document, or ICD.
4
Testing the Need for an Emulator
System 2 Emulator
System 1
System 2
System 1 Under Test
Encode
Decode
Decode
Encode
Decode
Encode
Why do we need Emulators?
When Engineers test System 1, very often they
need to - stimulate it with incoming messages
and - monitor its outgoing messages
In most situations, System 2 would not be useful
for stimulating and monitoring System 1 -
System 2 may be under development itself -
System 2 may not provide a user interface
So, engineers typically develop an PC-based
Emulator of System 2. The Emulator must provide
a user interface which - stimulates System 1
with incoming messages - monitors System 1s
outgoing messages
5
More about Emulators
The Emulator must encode and decode messages in a
manner identical to the real System 2, as
specified in the ICD
Geo-location Msg
System 1 Under Test
Encode
56
Latitude
Decode
-39
Longitude
10000ft
Altitude
Decode
Encode
ICD (Interface Control Document)
The Emulator typically has the message formats
hard-coded into its software. To change the
formats of the messages, you must change the
software.
The Emulator typically has the message formats
hard-coded into its software. To change the
formats of the messages, you must change the
Emulator software.
How do emulators work?
Sending a message
- The user defines the content of a message in
human-readable format - The Emulator encodes
the human-readable data into the format defined
in the ICD and sends the message
Receiving a message
  • The Emulator decodes the message data into
    human-readable format according to the ICD
  • The Emulator displays the message in
    human-readable format

6
Mimic as a Universal Human-Readable Emulator
The Mimic Application Emulating System 2
Like other emulators, Mimic must encode and
decode messages in a manner identical to the
real System 2, as specified in the ICD
System 1 Under Test
Encode
Decode
Decode
Encode
ICD (Interface Control Document)
The Emulator typically has the message formats
hard-coded into its software. To change the
formats of the messages, you must change the
software.
However, instead of containing hard-coded message
formats, Mimic reads the ICD to determine the
message formats and other interface information.
Why emulate using Mimic?
  • Human-Readability
  • Automatically encodes human-readable data into
    outgoing messages
  • Automatically decodes incoming messages into a
    human-readable format
  • Universality
  • With other emulators, one application only
    emulates one system
  • Mimic is Universal it can emulate virtually
    any system
  • Transparency to ICD Modifications
  • The software of other emulators must change when
    the ICD changes
  • Mimic simply reads the modified ICD no
    software changes

7
Mimic as a Universal Human-Readable Monitor
In addition to serving as an emulator, Mimic can
also silently monitor the messages transmitted
between two systems.
Decode
System 1 (Under Test)
System 2 (Under Test)
Encode
Decode
Encode
Decode
ICD (Interface Control Document)
Why monitor using Mimic?
When used in monitor mode, Mimic exhibits the
same defining characteristics of
human-readability, universality, and transparency
to ICD modifications as it does while emulating.
8
Behavior Objects
Behavior Objects - Problem
Problem
  • How do we add dynamic, automated messaging
    behavior to Mimic?
  • Examples
  • ACK Mimic must send an acknowledge message
    upon receiving a message from System 1
  • Command-Status Messaging Mimic must change
    the content of an outgoing status message in
    response to receiving a command message from
    System 1
  • Request-Response Messaging Mimic must send a
    message to System 1 upon receiving a request for
    that message from System 1

ACK
Lat/Long/Alt
System 1 Under Test
Encode
Decode
Heading NE
Heading North
Message
Position Request
Decode
WeatherT-storm
Encode
9
Behavior Objects (Contd)
Behavior Objects - Solution
Solution
  • Enable the user to plug-in Behavior Objects to
    Mimic
  • Behavior Objects consist of separate binary
    (DLL) modules
  • When the user initializes a Behavior Object, the
    Behavior Object requests Mimic to notify it of
    important events like
  • Receiving a message
  • Sending a message
  • Starting a message sequence
  • etc.
  • Examples
  • ACK Behavior Object tells Mimic to send an ACK
    message upon receiving a message
  • Command-Status Messaging Tells Mimic to
    change the content of an outgoing status
    message in response to receiving a command
    message
  • Request-Response Messaging Tells Mimic to
    send a message upon receiving a request for that
    message

10
Protocols Supported
Protocols Supported
  • - TCP/IP
  • UDP/IP
  • Serial/COM Port
  • MIL-STD-1553
  • Others possible
  • Modular, Object-Oriented design enables easy
    development of new protocols

11
Features
Messages View
  • The current state of every message type is
    displayed in the Messages View
  • The user can send outgoing messages with the
    Send button

12
Features (Contd)
Sequences
  • The user can define sequences of outgoing
    messages that he/she can play, pause, and stop at
    any time.
  • No limit on the number of sequences the user can
    play at a given time.
  • The user can view the sequence in a web browser
    for convenient viewing and analysis.

13
Features (Contd)
Logging
Message Logging
  • The user can log any or all incoming or outgoing
    messages. Mimic displays the content of each
    recorded message for the user.
  • The user can search through the log for messages
    whose field values match a user-defined set of
    criteria.
  • The user can save and view the log in a text
    format, spreadsheet-friendly format, and with a
    web browser for convenient viewing and analysis.
  • The user can automatically generate an Outgoing
    Message Sequence from a recording of his/her
    outgoing messages.

14
Features (Contd)
Predefined Messages
  • The user can define and save the content of
    outgoing messages once, and send it again at will
    without having to redefine it.

15
Features (Contd)
Behavior Objects
  • The user can attach plug-ins to Mimic, called
    Behavior Objects, that add dynamic, automated
    behavior to a Mimic Emulation.

16
Typical Business Case
Who does what?
  • - Client informs Trinidyne of the need for an
    emulation or monitoring solution for a particular
    system
  • - Trinidyne and client agree on the behavior
    object requirements, if any
  • Trinidyne and client agree on pre-set message
    sequences, if any
  • Trinidyne and client agree on a test plan
  • Client provides Trinidyne with unformatted ICD
  • Trinidyne transforms the ICD to a Mimic-readable
    format
  • Trinidyne implements behavior objects
  • Trinidyne develops test procedures, with client
    input
  • Trinidyne executes test procedures with client
    oversight
  • Trinidyne delivers a Mimic Basic emulation of
    the system in question. This includes
  • The Mimic executable binary files
  • The Behavior Object executable binary file(s)
    (if any)
  • The Emulation File
  • An installation program to install the above
    files.
  • An Emulation Software License

17
Business Case Spreadsheet Calculator
Write a Comment
User Comments (0)
About PowerShow.com