The hierarchy of Signals starts with three basic types: Numeric, Message, and Event. These are described below:
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).
•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.
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:
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.
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:
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
For more information on message-based Signals, see Editing Message Fields.
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:
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.
Event transitions may have an integer or Enum value, or no value. Event Signals have no defined value between transitions.
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
•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
To convert one image type to the other, use an Image Conversion Transform.