MxVDev Signal Dictionary
To access it from the main menu, select Project->Signal Dictionary. The Signals are organized in a tabbed dialog box as shown below.
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.
•ByteLen: Length of the signal in bytes. This field contains N/A for signals of the class Task.
•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).
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.
The CAN-TP tab is used to configure an ISO 15765 Transport Layer for CAN buses. See Configuring a Transport Layer.
Use this tab to define named constants that can be used when creating transitions. If you change the value of the Constant, it changes in all TestCases and transitions where it is used. Also, see Importing Signals and Constants.
There are 2 ways to add message constants:
•Select the Constants tab and click the Add button.
•Select the Standard tab, select a message Signal, and right-click to select Add Constant to <Signal Name>. This ensures that the constant has the same format as the message Signal.
Adding a Constant to a Message Signal
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 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:
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.
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.
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.