The hierarchy of Signals starts with three basic types:  Numeric, Message, and Event.  These are described below:

hmtoggle_plus1Numeric Signals

Use a numeric Signal for inputs and outputs that have a numeric value (such as temperature or RPM), or a finite list of values (such as for a state variable). Numeric Signals always have an Initial Value, a Minimum, and a Maximum. We know a from basic mathematics that numbers are partitioned into Real and Integer. This is a very useful distinction in our environment also.  For numeric Signals, we sub-classify them into: Continuous (Floating Point or Fixed Point) and Discrete (Integer).

hmtoggle_plus1Continuous Signals

These Signals are used to represent numeric values such as temperature, RPM, and wheel speed.  They are manipulated and stored in the MxSuite as real numbers (doubles).  These are sub-classed into Floating Point or Fixed Point. Continuous Signals may be associated with Engineering Units; see Using the Signal Dictionary.

Floating Point Signal-CtsFloat

If Floating Point is selected, the Signal can assume any value that can be stored in a 64-bit IEEE 754 double variable.

Fixed Point Signal-CtsFixed

There are limits imposed on the value that the Fixed Point number can assume.  Choose Fixed Point when you know that the value will be stored in a location with fixed point scaling (for example if the number is stored in just 6 bits of a message field).  When you select Fixed Point you are prompted to enter information about how to pack the number into its fixed point location (scaling and offset). When you enter values for a Fixed-Point number you will only be able to select values that can actually be stored in the fixed point location.  The values will be displayed as real numbers, but when converted through the scaling and offset will be an integer that will fit in the Fixed Point location without any loss of accuracy.

Choose the Discrete Signal classification for Signals that you want to assume only integer values.  We use this class for True/False Signals, On/Off Signals, and state variables (such as, PRNDL - Park, Reverse, Neutral, Drive, Low). When this class is chosen we rarely perform arithmetic operations on the Signal. For this reason, discrete Signals do not have units.

Guidelines for using Discrete Signals:

•The Signal is represented graphically.  It is beneficial if the range of the Signal is small (less than ~20), and the values are contiguous.

•It is usually a good idea to associate an enumeration label with such Signals.  A representative label is nearly always more informative than the Signal's actual value.

•For a continuous Signal that uses only integer values, use the continuous fixed-point type.

Discrete Signal values are stored internally as 64-bit signed long long integer. The hardware limit is ‑9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.

Discrete Signals are marked in TestCases with this icon: Signal-Discrete

Boolean Discrete Signals are marked with this icon: Signal-Discrete-Boolean

 
Note: In the MxSuite Signal Dictionary, the choice between Continuous or Discrete determines:

•How pass/fail is performed (among other differences, there is no Value Tolerance on Discrete Signals)

•The default Edit Mode (Pulse or Ramp)

•Whether the Signal can assume non-integer values

•Whether the values stored in the XML TestCase file (.mxc) are Integer or Real

You should not make the choice between Continuous and Discrete based on how the value is stored in the SUT.  For example, if in the SUT Temperature is stored as a UINT8 and is scaled as 1 bit = 1 degree (so it is always an integer), it should still typically by classified as Continuous  Fixed-Point Signal because we consider temperature to be continuously variable.

The MxSuite enables you to manipulate one or two-dimensional arrays of numeric data.

•The arrays can be one or two dimensional.

•The array data can be sparsely populated, that is, values may not exist for every cell in the array.

•When values are assigned to a specific array element, the values of other elements are unchanged from the previous transition. For some uses, such as an array to be converted to a message, it may be necessary to clear the whole array before assigning values.

•It supports data interchange with other programs:

oOne dimensional array data can be mapped directly into one dimensional arrays in Simulink via the S-Function Connector transform.

oCCP and XCP connectors take advantage of the array data format for data interchange. However for CCP/XCP, arrays currently can be used as stimulus only, not as response.

•In TestCases, array Signals are marked with the icon that corresponds to the Signal classification of the array elements.

•Presently there is no way to graphically plot array data.

•Properties of the array Signal, such as min and max, apply to all elements of the array.

See Editing Test Patterns–Arrays.
hmtoggle_plus1Message Signals

Message Signals are used to capture value information for Signals where the data normally exists as a sequence of bytes.  A message Signal can either be fixed length or variable length.  If it is fixed length, then the length must be provided, if it is variable length, then the maximum length must be provided.

Message Signals are marked in TestCases with this icon: Signal-Message

There are usually some associated rules about how the information in the stream of bytes is encoded, and the MxSuite environment supports several basic encodings. Supported Encodings include:

•Hex - Choose this format if you want to view the data as a sequence of hexadecimal bytes.

•Text - Use text format to represent data in that is typically displayed as a readable/printable string.

•Image data - The MxSuite supports internal image formats, both black/white and color. This enables you to display image data graphically.  Typically the internal format is not the format used directly by your SUT, but it is usually not difficult to create a Signal Processing Transform to translate the image data from one format to the other. For more information, see Comparing Image Signals.

Fields can be associated with and overlaid on the message data.  The fields are used to extract further Signal data from the Message Signal. See Editing Message Fields. The packed Signals also follow the classification tree defined here. Field packing information is often available in a standard format. The MxSuite can import such information from DBC, LDF, and ASAM files. The fields are also known as message-based Signals and may be used independently in TestCases.

The MxSuite includes Signal Processing Transforms which can pack and unpack message data that is stored in other formats. For example, there are Transforms that decode Signals from packed diagnostic-messages. Custom Transforms can be built to pack and unpack formats that are not supported in the base product.

Message-Based Signals (Component Signals)

In the MxSuite, the fully qualified name of a message-based Signal has the format MessageName·FieldName. The parts of the name are separated by the middle dot character (Alt+0183, not to be confused with a period). For example:

VehSpeedRPM·EngineRPM

In addition, for CAN or LIN signals the bus name and data flow may be prepended to the message name, as specified in Network Configuration. For example:

CANB - In - VehSpeedRPM·EngineRPM

LIN SNA Signals have a special naming format, see LIN Receive Driver.

For more information on message-based Signals, see Editing Message Fields.

hmtoggle_plus1Event/Task Signals

An Event is an occurrence of some sort that causes some action to be taken. Examples include resetting the Test Harness or calling a function in the VMC. The word Task is used to describe Events that are Function calls in a compiled C/C++  executable. Transitions on a Stimulus Event Signal cause the action to occur.

Event Signals are marked in TestCases with this icon: Signal-Event

When to Use an Event Signal

The examples below give guidance on when to choose an Event Signal instead of a Discrete Signal:

Choose an Event Signal when:

•Simulating radio buttons: The event sets a state (the value), but each event is independent, and repeated events with the same value are possible. An event Signal is the best choice for this simulation.

•When a Signal is used to transmit a command (represented by a number), it could be associated with the Enum values Open and Close. Using an event Signal, you can send consecutive Open commands without an intervening Close command. This enables retries.

Choose a Discrete Signal when:

•Simulating the behavior of an ignition switch: The event sets a state, but an event that repeats the previous value (for example, Off to Off) is not meaningful. A discrete numeric Signal is the best choice for this simulation.

Parameters

Event transitions may have an integer or Enum value, or no value. Event Signals have no defined value between transitions.

To create an event Signal, see Signal Dictionary–Events or Port Registration—Task (Event) Ports.
hmtoggle_plus1Image Signals

There are two types of image Signals: MxV Image Signals and NI Vision Image Signals:

•MxV Image Signals are used for color or black and white images in native MxVDev format. In MxTransIt, you can identify MxV Image ports a Display String port property of Image.

Properties of an MxV Image port

Properties of an MxV Image port

•NI Vision Image Signals (also called SourceImage Signals) are special Signals used to connect Image Recognition Transforms. They cannot be imported into MxVDev or used in TestCases. The images are a proprietary National Instruments format. In MxTransIt, you can identify MxV Image ports a Display String port property of Vision Image.

Properties of an NI Vision Image port

Properties of an NI Vision Image port

To convert one image type to the other, use an Image Conversion Transform.

 

Related Topics:

Signal and Port Properties

Signal Dictionary

Using the Signal Dictionary

Signal List

Editing Message Fields

Viewing Signals