Using the Signal Dictionary

MxVDev Signal Dictionary

The MxVDev Signal Dictionary presents information about Signals in the test environment.  It shows information from several sources. System Signals are predefined and not listed here.

To access it from the main menu, select Project->Signal Dictionary. The Signals are organized in a tabbed dialog box as shown below.

SignalDictionary

The main Signal Dictionary browser shows several of the key Signal properties to help you locate a particular Signal.  The listed Signal properties are:

•Name: This field must be unique among Signals.  It is the string that is shown when a signal is displayed in a TestCase (unless an alias name is defined for the signal).

•Classification: There is a classification tree for the format or type of Signal data. This hierarchy is described in detail in Signal Classification.

•Data Flow: Indicate the direction of data flow.  Stimulus means an input to the harness and the SUT. Response means an output from the harness and the SUT back to MxVDev.

•Connector Automatically set by MxVDev:  The field shows if the Signal is defined in the MxVDev Project or in the AppIF file of an MxVMC.

•ByteLen: Length of the signal in bytes.  This field contains N/A for signals of the class Task.

•Alias: The Alias field replaces the name of the Signal when it is displayed in a TestCase. It may be used, for example, when the name is too long or obscure. This field is optional.

•Description:  The Description field is a place for information useful in maintaining and working with the signals. This field is optional.

Message Signals have a couple of additional fields:

•MsgID: Identifier of the message in hexadecimal notation.

•BusName:  The network bus which will carry and transport the message (Network buses can be created using Network Config under Project on the main menu).

hmtoggle_plus1Tabs

Events Tab

Use the Events tab to access Event/Task signals.

CAN and LIN Tabs

Network messages are displayed under the CAN and LIN tabs. These signals are defined during Network Configuration and cannot be edited using the Signal Dictionary.

 
hmtoggle_plus1Adding/Editing/Copying Signals

Adding a Signal can be accomplished by clicking the Add button in the Signal Dictionary window. This brings up the Edit Signal Definition window. This window also gets displayed when the Edit button or the Copy button is pressed (a new suggested Name is entered when copying signals).

Changes made to the MxVDev Signal Dictionary are not propagated to MxTransIt. To ensure that Signal properties are identical in MxVDev and MxTransIt, define the ports (Signals) in MxTransIt and export them. See Exporting Ports.

You can always modify and delete Signals from the Project Connector. There are limitations on what you can do in the Signal Dictionary to Signals from other sources.  For example, if the Signal is defined in the MxVMC:

•You cannot change whether the Signal is a Stimulus or Response, or the Classification (Numeric, Message, or Event).

•You can change Numeric Signal Properties (Floating-point, Fixed-point, or Discrete).

•Some of the optional fields can be overridden, such as Engineering Units, minimum and maximum.

•Changes made in the Signal Dictionary do not propagate to the Harness, but the properties in the Signal Dictionary take precedence over properties defined in MxTransIt or in an AppIF.c file.

When adding, editing, or copying a signal, you need to:

•Provide a unique name for the signal

•Select the Classification of the signal: Numeric, Message or Event (Task). You should review the topic on Signal Classification before making this selection.

•Select the Data Flow of the signal (except Task): Stimulus (Input to SUT) or Response (Output from SUT)

Based on the Classification you are prompted for further information as follows:

SigDict-Edit

For Numeric Signals, the fields to be completed are:

•Display Format: Controls how the number is displayed in TestCases. The Hexadecimal format is available for Discrete Signals only.

•Units: This is a string label that describes the engineering units. The label might be PSI, meters/sec, miles per hour, or another appropriate string. Units are used with continuous Signals only.

•Minimum: This is the lower limit for the Signal. When checking is enabled, a failure is indicated if the actual Signal value goes below this minimum. See Min/Max Ranges.

•Maximum: This is the upper limit for the Signal. When checking is enabled, a failure is indicated if the actual Signal value goes above this maximum.
 
For more information on the Min and Max settings, see Signal Properties—Display Settings.

•Init (Initial Value):

oStimulus Signals: Prior to execution of a Scenario, most stimulus (input) Signals included in the Scenario are set to this initial value. The exception is Signals that have null data at the beginning of a TestCase, that is, if there is no transition at time zero. They remain at null data until the first transition. The MxV Input Reset System Signal also sets input Signals to this Init value.
 
Note: After a rewind, Signals retain their previous value unless they are reinitialized with an MxV Input Reset. (See System Reset.)

oResponse Signals: For response (output) Signals, the initial value is the default expected value. The actual value of an output signal is set by its source Transform.

•Signal Default Value Tolerance: This property is available for continuous response Signals only. By default, these values are used as the value tolerances in all TestCases that use the Signal.  The value tolerances can be overridden in the Signal properties and the DataBlock properties.
 
Time tolerances are set in the TestCase properties. For more detail, see Tolerances.

For Continuous Signals, there are Scaling and Offset fields to provide the conversion between the value in Engineering Units and Counts (the value that will be used in the VMC).  Enter the Scale and Offset first.  You can then enter the initial value, min, or max in either column and the conversion is made automatically.

The Signal Dictionary is populated from many sources. When it is populated from MxTransIt, the Min and Max are imported to the Signal Dictionary from the Harness. The values can be subsequently modified, however sending values into the test harness that are out-of-range for the port may produce warnings.

You can associate enumeration sets with a Signal.  In general this is done only for Discrete Signals, but it works for Continuous Signals also.  The Enumeration List drop-down list allows you to establish this association. Refer to Working with Enums for more information.

EditMsg_1

See Message Signals for a review of what these Signals are used for. Set the Message Signal Properties:

•Variable Length Message: A message is either fixed length or variable length as controlled by this option. For variable length messages, the message length is the maximum message length.

•Message Length/Maximum Length: The length of the buffer of data specified in bytes.

•Display Format: This controls how the message is displayed in MxVDev by default. This setting my be overridden in the Signal Properties set in a TestCase.

For more information, please refer to Automatic Message Transmission and Editing Message Fields.

If there is no value associated with the events, set the Minimum and Maximum to 1. Optionally, an Enum set may be associated with Event Signals. See Editing Test Patterns–Events.

SigDict-Event

When you click the Apply button, new tabs are added to the Edit Signal Definition form:

•Data Routing - For single-VMC projects, this allows you to define simple Routing to the MxVMC without needing to use MxTransIt.

•Inline Transform - You can define Inline Transforms, again without using MxTransIt.

•MxVMC Transforms -  This tab allows you to associate the Signal with a Handler Function in the MxVMC.  It is present only when you have an MxVMC in your test environment.

 
hmtoggle_plus1Deleting Signals

Click the Delete button to remove the selected Signal.

The Signal Dictionary shows Signals from the Project Connector, from the SUT Connector, and from Transforms.  You will be able to delete Signals in some cases and not others, for example:

•If the Signal is shown because it exists in an external Signal Database (such as a CAN DBC or LIN LDF file), you will not be able to delete it.

•If the Signal is defined in the MxVMC (in the AppIF.c file), you will not be able to delete it.

Deleting a signal requires that the signal is not used in the current test scenario.
hmtoggle_plus1Troubleshooting

If the Signal Dictionary becomes corrupt or faulty, you can delete the file (.mxd) and regenerate the Signal Dictionary from the Harness (MxTransIt). Signals entered into the Signal Dictionary manually will have to be reentered. CAN and LIN Signals are defined in the DBC or LDF files and not affected.

 

Related Topics

Architectural Concepts—Signal Dictionary

Signals

Signal Classification

Connecting Signals

Exporting Ports

Importing Signals and Constants

Handler Function Transforms

Configuring a Transport Layer

Working with Enums