A key philosophy of the MxSuite is that unless you explicitly reset the test system (SUT and MxVDev), the system remains in the state it was in upon completion of any prior test or Scenario. This is exactly the same behavior as you would see when testing a real piece of hardware in a bench test environment.

This means:

Between one TestCase and the next in a given Scenario, the SUT is not reset by default.

Between one Scenario and the next, the SUT is not reset by default.

Between one test (or Scenario) and the next, Signal values (stimulus and response) are not reset by default.

The purpose of the MxV Module Reset System Signal is to put the System(s) Under Test back to a known initial state. Note that there is a difference in how this is achieved depending on the MxSuite release level. In 3.36 and later releases,  MxV Module Reset resets the whole Test Harness.  In 3.34 and earlier, it only resets the Transform that has an MxV Module Reset input port.

Asserting MxV Module Reset puts the Test Harness back into the state it was in when the project was first loaded.  Note though that the MxSuite test tool is not in its initial state. In particular, the Stimulus Signals are still at the last value that they were set to in the TestCases that have just run. To reset these Stimulus Signals to their initial values (specified in the Signal Dictionary, the DBC files, and the LDF files), assert the MxV Input Reset Signal.

To summarize, resetting the system is accomplished using two System Signals:

The MxV Module Reset System Signal resets the Test Harness to its initial 'power on' state. (In release 3.34 and earlier, only the SUT is reset.) As part of the reset event, note that:

oNumeric Stimulus Signals - The last transition is transmitted back into the Harness (as if they just changed on the tick of the reset). Numeric message-based Signals are treated as message Signals.

oMessages (including message-based Signals) are not re-transmitted into the Harness, but the last value transmitted into the Harness is preserved.

oResponse Signals have no defined value until the first Transform tick after the MxV Module Reset. At that point the Signal assumes the value output by its source Transform or SUT.

oFor periodically ticked Transforms, we expect no output transitions until the next transform tick after the MxV Module Reset.

oWhen a Module Reset and a transition on a stimulus Signal happen in the same tick the stimulus transition takes effect. See Simultaneous Resets.

oAll changes to automatic message transmission from Bus Control System Signals are cleared. The automatic message transmission strategy returns to that defined in the DBC or LDF file.

oThe VMC application code is terminated, the SUT DLL is unloaded, and then reloaded. (The MxRTE process remains open, but the portion containing the written code is no longer loaded.) 

The MxV Input Reset System Signal resets all of the stimulus Signals included in the current Scenario back to their initial value.

oNumeric Signals - The Init Value of each Signal (from the Signal Dictionary) is transmitted into the Harness. (A side effect is that at this point values of input signals in current TestCases no longer represent the values that the Harness sees.) Numeric message-based signals are treated as message signals. See below.

oMessages (including message-based signals) are not re-transmitted into the Harness, but the last value transmitted into the Harness is reset to the default value for the message (defined in the DBC or LDF file).

oResponse Signals are not affected by the MxV Input Reset.

oIf you have a transition on a stimulus Signal at the same time as an MxV Input Reset is asserted, the transition overwrites the initial default value. See Simultaneous Resets.

Simultaneous Resets

If resets are asserted at the same time (that is, if the transition times are the same), MxVDev processes the transitions in this order:

1.MxV Module Reset

2.MxV Input Reset

3.Any other transitions

Backward Compatibility

The behavior above is the default for all new projects created with MxSuite release or later. For older projects, or if the Backward Compatibility option is selected, the behavior is as follows:

If the MxV Input Reset is in a TestCase before the MxV Module Reset, and they are asserted at the same time, the Input Reset is thrown away. This can lead to problematic and unpredictable results and a warning is generated.

To resolve the issue and clear the warning, either turn off the Backward compatibility option off (causing the Input Reset to always occur and send down new transitions) or move the MxV Input Reset Signal after the MxV Module Reset Signal in the TestCase. Note that in EITHER case, the test results may differ, because in the past, the input reset that occurred at the same time as a module reset would never transmit the new initial values (since the module reset would clear the pending transitions).

Init TestCase

By default, new projects include the Init TestCase, which includes these two System Signals. You can use this TestCase at the beginning of your Scenario to put the test system into a known initial state. You can modify or delete the Init TestCase to produce the desired behavior of your test system.

The default Init TestCase also includes a SUT Init task signal, which is used to initialize the MxVMC, if present.

Note: If the Init TestCase is a precondition to subsequent TestCases, it has the effect of delaying the start of the rest of the test. This can cause unexpected results for time-dependent Signals. To avoid this behavior, set the Init TestCase to start concurrently with other TestCases.

Related Topics:

System Signals

Editing Message Fields (message-based signals)

MxTransIt Model—Tick Order

Min and Max Warnings

Viewing Signals—No Defined Value (null data)