MxSuite™ Programming Interfaces

There are several ways that you can programmatically interface with the MxSuite to build a more comprehensive test environment.  These are summarized in the image below, and described in some more detail in the following table.  Note that the numbered blocks in the image have corresponding entries in the table.






.Net interface to TestCases

Using Visual Basic or C# you can programmatically create TestCases and Scenarios in the MxSuite XML format.

The .Net Assemblies create, open, parse, read, validate and write the XML files.

This capability is one way that we provide support for external automatic test generation, custom signal pattern generation or custom pass/fail analysis.

It is also possible to perform 'data mining using this interface. For example:  Search for a test case that performs a specific pattern of changes to some input signals.

A sample program is provided, see C# Test Creation Sample Project.


Custom Stimulation

Often you may want to generate a more complex test pattern on the fly as the test runs.  For example, suppose inputs to the SUT I1, and I2 can be defined programmatically in terms of test case signals S1 and S2, and Time since the start of the test.  A typical example is the creation of a PWM signal.  The test case Signals would define frequency and duty cycle.  The actual PWM signal is delivered into the SUT.  In this way we can operate on the parameters in the test case and have the 'complex pattern' be generated as the test progresses.



Triggers are implemented in the DataBlock.  They 'watch' for certain sequences or values to be achieved.  Once the trigger point is reached the Trigger fires.  Triggers can cause the test case to be terminated (with a pass or fail outcome), the entire Scenario to be terminated, or an external script to be executed.  Trigger events include:

A signal value threshold crossed

A signal changes (the first or nth time, or after another signal pattern has been recognized)



COM is a Microsoft Windows programming paradigm that allows two programs (processes) to communicate via a programming API.  The MxSuite provides three COM interfaces:

MxVDev COM Automation API

MxVDiff COM Automation API

MxTransIt COM Automation API

These are some examples of tasks you can perform programmatically using a COM API:

Open/Close project

Execute a Regression Command File or load and execute a Scenario

Examine the results of executing a Scenario

Accept Results on a Scenario

Compare two sets of regression results


Shell Command Signal

There is a System Signal called MxV Shell Command that allows you to invoke any process or program when a Transition in this Signal is encountered.  It is a message based Signal that takes as parameters the name of the program to execute, and a string for command line parameters that are passed to the program.  This feature may be used for:

Re-flashing an ECU with a new version of the executable code

Performing a check-out of a suite of test cases from a version control system

Running a batch file to set environmental variables or search paths


Inline Transform

Run a transformation on an individual signal.  This is similar to item 2 above except for the following:

There can be only one input and one output signal.

You do not need an external compiler.  The compiler environment for the Inline Transform is built into MxVDev.


Custom Pass/Fail Analysis

Sometimes the pass/fail criteria are rule based.  A simple example is that an Signal2 is always twice Signal1.  We can write a Custom Pass/Fail algorithm that determines if this rule is obeyed by the SUT.  In this case, the transform has two inputs (Signal1 and Signal2) and one output.  If the inputs are Discrete, then the output would likely be a True/False Signal.  If the inputs are continuous, then the output may be calculated as the ratio of the two input signals.  In this way, you could set a tolerance on the value of the output signal.

Of course, if the value of Signal1 is predictable as the test runs, then we can define the expected value of both Signal1 and Signal2 without needing any custom code.


Plant Model

The Plant model is a place to store behavioral information about how the environment of the SUT behaves.  It is often implemented in code.  When describing system behavior in code or script for the purposes of testing, you should recognize the difference between:

Building a model of the execution environment (Plant Model)

Adding logic to your test suite.

By carefully delineating what should be Plant Model and what should be part of the test  suite, you end up with more reusable tests and a more reusable Plant Model.  In the MxSuite™ environment, you can implement Plant Model functionality in C, C++, or C#.  You can also use a Simulink model (depending on execution time constraints).

Related Topic:

System Signals