Several words and terms that we use throughout this documentation have special or specific meaning in the context of MxVDev testing. These words and terms are defined as follows:
An Alias is an alternate name for a Signal or port. The alias name is displayed in TestCases and on Transforms, but the original name remains in the Signal Dictionary and Port Properties. An alias may be useful when the Signal/port name is too long or obscure, but not easily changed.
A Controller Area Network (CAN) database file. This file is typically provided by the automobile manufacturer. The file can be edited using the Vector CANdb++ Editor.
A Connector is a Transform that connects to another program or device through a programming interface (such as COM, a DLL, or Assembly). We can imagine that Connector Transforms exist at the boundary of a Harness in the same way that connectors are found at the ends of a wiring harness. A Connector Transform provides interfaces to:
•Another program (such as Matlab or MxRTE)
•Test equipment (such as dSPACE, Pi AutoSim, LabVIEW/PXI)
•An MxVDev project and its Scenarios and TestCases (Project Connector Transform)
•System Connector - A Transform that provides an interface to access some internal MxVDev functionality
•SUT Connector - A Transform that provides the interface to a SUT. There may be more than one SUT Connector in a Harness.
•Project Connector - A Transform that provides the interface that receives Stimuli Transitions from a Scenario and propagates them towards the SUT. It also returns Response Transitions from the SUT to the Scenario.
Counts are the internal storage method used by the system. There is a mapping from the count to the value. For example, if a temperature is defined in tenths of a degree, 10 counts equals one degree.
A DataBlock is used to partition a Signal into one or more regions on the time axis. This is useful for many reasons, including:
•Change Pass/Fail tolerances for a Signal as the test progresses
•Change the Data Source for a Signal as the test progresses
•Specify a certain behavior (shape or pattern) that we are expecting for an output Signal. We can cause a Trigger to fire when this shape is recognized
•Specifying relative pass/fail criteria between recognized behaviors that occur on one Signal relative to recognized behaviors on another Signal
Execution Model relates to Software-in-the-Loop testing only. To run a TestCase, you need to do more than change inputs and monitor outputs. You need to define when the code in the System Under Test executes. A simple scheduling sequence might involve running an initialization task at the start of a Scenario, followed by scheduling a periodic task every few milliseconds. This would be the Execution Model of a simple cyclic scheduler. It is easy to enhance this model by adding tasks scheduled at other frequencies and adding interrupts, giving a more complex and realistic Execution Model. If you have an RTOS, you can simulate the RTOS by scheduling its tasks directly from MxVDev, or you can configure MxVDev to run the scheduler of your embedded RTOS. For more details see the section on Execution Model.
The convention when referring to the MxVDev test environment is that an Input refers to an input to the System Under Test (SUT). Inputs are also called Stimuli.
Scenarios are used to schedule Jobs. A Job specifies how and when a TestCase is run. When you add a Job to a Scenario, you can specify which TestCase is run, how many times it is repeated, and what other Jobs have to have completed before you start the current Job.
This scheduling mechanism allows you to schedule Jobs to run either in sequence or concurrently.
Jobs in a Scenario
A field in a message signal that is used as a separate signal. See Editing Message Fields. In the TestCase viewer, message-based signals are marked with a bracket }. The name of the parent signal is prefixed to the name of the field to form the name of the message-based signal.
A Message-Based Signal
When using Accelerated time, MxVDev schedules events using an internal clock called MxClock. MxClock has a resolution of 1 ns. The clock may run faster or slower than real time depending on the workload on the PC.
For each tick MxVDev does the following:
•Updates each Input Signal on each TestCase to the new signal values, and invoked the event functions for that signal
•Invokes the Task associated with each Task Signal in each TestCase
•Verifies that each Output Signal for each TestCase has the expected value
•Updates the graphs
MxComponents are easily identifiable features or capabilities of the MxSuite. Each MxComponent has an associated charge measured in license tokens. When you use that component a debit is made against a Token Pool. When you stop using the component, the Token Pool is credited by that same number of tokens. The MxSuite Price List itemizes and describes the available MxComponents and their associated Token charge.
Null data indicates a Signal has no value. This is not the same as value of zero. For response Signals the Null Data state exists starting from the initialization of the SUT (or immediately after a Module Reset) and persisting until either:
•A value has been received (for example, when a CAN message is received, initializing all of its Signals)
•A measurement has been made (for a polled Signal) (for example, when the first scan to measure all output Signals is made after a reset)
In a TestCase, null data is displayed as square gray dots:
Null data dots
A useful convention when referring to the full MxVDev test environment is that an Output refers to an output from the System Under Test (SUT). Outputs are also called responses.
How a Signal changes over time in a TestCase.
A Pattern is defined to be a shape showing how a Signal changes over time. In MxVDev it can be defined by a sequence of transitions, or a Signal Generator. For event Signals, we still use the term Pattern to apply to a Pattern of events over time.
An MxVDev project is configured for a specific system that you are developing. You may have several Systems Under Test (SUT) for one project. For example, you may have a Simulink SUT, a Software-in-the-Loop SUT and a Hardware-in-the-Loop SUT. You will need to create a Project before you can use MxVDev.
•The project file has a .mxp extension.
•Every MxVDev project has a Signal Dictionary.
The Connector that connects between MxVDev (MxSpecIt) and the Virtual Wiring Harness. Signals that pass through the Project Connector are called Project Signals.
Receive refers to receiving a message from the System Under Test (SUT).
In MxVDev, the Scenario provides a way of scheduling TestCases. You schedule a TestCase by adding a Job to a Scenario. The Job properties govern how the TestCase is scheduled. You can add any number of Jobs to a Scenario. By adding Jobs and setting the Job Properties you can:
•Schedule a TestCase to start when one or more other TestCases have completed
•See which TestCases have passed and which have failed
Scenarios can either be run interactively from the GUI, from the Command Line or using the COM interface.
Send refers to a sending a message to the System Under Test (SUT).
In general, Signals affect or monitor the behavior of the System Under Test. You can configure Signals to act on and monitor the Test Harness also. In MxVDev the changes in a signal are always presented as a function of time (how they change over time).
We classify Signals as follows:
•Numeric - A numeric Signal can be a Continuous, such as RPM, or Discrete, such as True/False values or state variables
•Message - A buffer of data that is stored as a sequence of bytes.
•Task - Enables us to execute a function or trigger an event. The function can be in the Test Harness or, for Software-in-the-Loop, in the System Under Test.
•You can create and edit Arrays of Numeric Signals
•Signals are either Inputs to Harness or Outputs from the Harness.
•System Signals - You will see when you Pick Signals, that there is a set of predefined Signals called System Signals. These Signals allow you to control the operation of the MxVDev test environment.
A fuller description is provided under Signal Classification.
The Connector that connects the Virtual Wiring Harness and a SUT. Usually the SUT Connector uses some sort of Application Programming Interface (API) to access the SUT. The API could for example be used to access the I/O of a CAN transceiver, write to a file on the hard drive, open a COM connection top another program, or send and receive IP message packets.
The SUT is the entity that you are testing. You connect MxVDev and the SUT using a Virtual Wiring Harness. You may have one or more SUTs connected to your Virtual Wiring Harness at time.
For more information, see System Under Test.
A TestCase provides a mechanism to define a subset of the available Signals. You can schedule changes to input signals over time. You can also record the response of output signals over time. TestCases cannot be scheduled to stand alone, they can only be executed within the context of a Scenario.
As you watch MxVDev execute a TestCase, you will see the cursor step forward in discrete intervals. Each interval is called a Test Step. The period of the Test Steps in any TestCase can be set to a whole number of nanoseconds.
Test Suite is the informal name given to the set of all the TestCases and Scenarios needed to test a given system.
A string, provided by Danlaw, used to deposit license tokens in a token pool. See Licensing.
A Transform is an entity that:
•Receives Transitions data on zero or more Input Ports. If it has zero Input Ports it will receive data via a programming interface (such as COM or a DLL)
•Performs a transforming operation on the data received
•Transmits Transitions data on zero or more Output Ports. If it has zero Output Ports it will transmit data via a programming interface (such as COM or a DLL)
•Complex Transforms can be constructed by interconnecting simpler Transforms
•Signals are propagated from the Input side of a Transform to the Output side of a Transform by applying a periodic clock tick event
Transforms are grouped in four categories:
•User-Defined Transforms - includes the C# Snippet, SIL Easy, and the MxVMC
•Custom Transforms - You can create your own very powerful transforms using C#.
A Transition is a specification of the Value of a Signal at a point in time. The Transition specifies the Name of the Signal, and the Value of the Signal. It also specifies time as follows:
•Event Based Signals - Time is when the event occurs. For example, the time that a message is sent.
•Persistent Signals - Time is the time that the Signal changes to the specified Value. For example, if the output of an AtoD is sampled periodically, then the sample time is recorded in the transition.
For more information, see Architectural Concepts–Transitions.
Value is used to refer to the Value of a Signal. A one or two-dimensional array of values can be stored in a single transition. Array data is only supported for Continuous Numeric Values at present.
The Virtual Micro-Controller (MxVMC) is a Connector Transform in the MxSuite that simulates a microcontroller. It executes on the PC as an independent process, but it has several features just as in a real microcontroller:
•EEPROM emulation - flashable with Motorola S-record (S1, S2, and S3 are supported) or Intel hex ASCII files
•Discrete I/O, D to A and A to D, PWM
•An OSEK (or you can easily set up a cyclic scheduler)
•It will execute C or C++ code (that is compiled to run on the PC)
For more information, see MxVMC - The Virtual MicroController.
The Virtual Wiring Harness (also known as the Harness or the Test Harness) is analogous to an actual vehicle wiring harness in that it has connectors, and routing between connector terminals (or ports). It serves the purpose of connecting the Signals in MxVDev TestCases to the System(s) Under Test. Use MxTransIt to edit the Harness.
It has the following properties:
•It is a Transform (and also contains Transforms).
•It allows you to establish connectivity between inputs and outputs of MxVDev and inputs and outputs of one or more SUTs.
•It allows you to perform transformations on Signal data as the data passes through the Harness.
•The boundaries of the Harness are always terminated with Connector Transforms.
•Like all Transforms, Signals are propagated through the Harness by applying a periodic clock tick event.
•Unlike a real wiring harness, Transforms can be used to modify the Signals as they are propagated from the input side to the output side.