Model access tab¶

The simulation model runs as simulation environment on real-time hardware, e.g. of dSPACE. ecu.test can control that model by means of the model access tab. This is done through variables which are displayed as a selection tree.

If variables are mapped which are to be found in the model at model root the paths are adjusted automatically by dSpace multiprocessor systems.

There is the additional possibility to put in model test steps without having to choose a particular model variable. This can be looked up in chapter Generic.

A right click on a variable of the simulation model opens a context menu by which various actions can be started.

Read

A left click Read opens the dialog window Read model.

The input possibilities are described in chapter Read / Write / Execute / Stimulus dialog.

Write

A left click on Write opens the dialog window Write model. The upper part corresponds to the fields in the reading dialog. In the lower part, instead of evaluation, a variable of the simulation model can be assigned a particular value and so the model can be controlled.

However, you can always adjust only one variable at a time. If it is required to adjust several variables then several test steps have to be inserted.

Create global mapping

Selecting this option in the context menu adds the variable path of the simulation model to the global mapping list. That can be done as well by “drag and drop” from the list of model variables. The meaning and use of mapping names is explained in the section Global mapping.

If the simulation environment is a software which is used to create and run scenarios, a right click on a node opens a context menu which contains further actions.

Execute

This option opens the dialog for scenario execution. After selection of execution mode and closing the dialog, write actions may be appended to the inserted test step. During test execution, the execute test step activates the scenario at the simulation environment, performs the write actions and starts the simulation. It is important to take care, that the appended write actions solely assign values to variables, which are subordinate to the scenario.

Write

The choice of this option opens the dialog window Write model. In this case, a value will be assigned to a node instead of a variable. This causes a change of a sub tree in the containing scenario of the model during test execution. Because of that, It is important to assign values only to variables which are not subordinate to this sub tree. The change of a sub tree is temporarily during test execution and will not be visualized.

Signals can be added to signal recordings and thus be recorded during test execution.

Through the attribute Aquisition rate it can be determined in which interval the signal is refreshed. Via the setting “port default” the default interval will be used. The acquisition rate can be written manually as well, whereas ‘*’ and ‘?’ will be used as wild cards. If the tool doesn’t support the interval change, nothing happens with this statement.

Store model data in file¶

A right click on the model tree`s root opens a context menu by which the model can be stored in an Offline Model File. A dialog opens to specify the directory and name for the Offline Model File to be stored. If dynamic reload from model is activated, only the actually existing model in the model data view is stored in the Offline Model File. This generated Offline Model File can be used as model file on Platform tab for creating offline tests.

Refresh model¶

A right click on the model tree`s root opens a context menu by which the model can be refreshed. The model is then read in again. The context menu entry is only available if the underlying tool supports online query.

Generating virtual model variables via signal mappings¶

For certain use cases it’s possible to generate virtual variables for the model tree. With this feature certain variables, which represent a model’s inputs and outputs, are combined and added to the model tree as a new element. Depending on the action that is performed on that new virtual variable, a different signal is read or written internally.

To use this feature a special model structure is required:

There must be a “selector” variable, with which it’s possible to pass different signals to a central “out” signal. Depending on what value is written to “selector” a different signal is passed to “out”. E.g. if “selector” is set to 1 then the value of “const” will be passed to “out”.

The mapping of the separate model variables (const, out, stimulation, selector) to their virtual varible is defined in an *.sms file. This file can be added to the test configuration as an Tool specific additional file. The structure of an *.sms file shall be demonstrated with the following example:

{
     "signals": {
         "out": {
             "suffix": ".out"
         },
         "const": {
             "suffix": ".const",
             "selectorValue": 1
         },
         "stimulation": {
             "suffix": ".stim",
             "selectorValue": 2
         },
         "selector" : {
             "suffix": ".switch"
         }
     },
     "entryPath": "path/to/the/smsVariables/",
     "formatVersion": 2
}

The mapping utilizes suffixes in the variable’s names. With the above example all model variables that end with “.out”, “.const”, “.stim”, or “.switch” will be recognized as potential sources for a virtual variable. The name of that new virtual variable is derived from the original variable by removing the suffix. For example if there are model variables called “Exhaust.out”, “Exhaust.const”, “Exhaust.stim” and “Exhaust.switch” then a new model variable called “Exhaust” will automatically be created. The definitions of the signals “const” and “stimulation” additionally require a value for the "selectorValue" parameter (in the above example "selectorValue": 1 or "selectorValue": 2 respectively). This parameter determines to which value the “selector” signal must be set, such that the model will pass the values of “const” or “stimulation” to the “out” signal.

Depending on the action that is performed on the new “Exhaust” element, a different variable will be used internally:

• Read: The value of “Exhaust.out” is read.

• Write: The given value is written to “Exhaust.const”. Subsequently “Exhaust.switch” is set such that “Exhaust.out” will now deliver the value of “Exhaust.const”.

• Stimulate: The stimulus will be applied to “Exhaust.stim”. Subsequently “Exhaust.switch” is set such that “Exhaust.out” will now deliver the value of the stimulus.

• Reset: “Exhaust.const” and “Exhaust.switch” are reset to their original values.

The field "entryPath" defines the path for which this mapping should be applied. Only signals whose path begins with this string will be affected by the mapping. If "entryPath" is omitted, the mapping will be applied to the entire model tree.

Filters, aliases and model structuring¶

The display of the simulation model can be customised using filters and aliases. Filters allow you to hide model variables, whilst aliases enable you to display model variables under a different name or path. The latter thus also enables the restructuring of the model by grouping model variables under a common path. Both functions can be activated via tool-specific additional file by creating a Python file in the user Python library directory that contains the filter and alias definitions. This Python file must define MODULE_TYPE = “USER_MODEL_MODIFIER”. To have an effect, it needs to implement at least one of the two optional methods GetVariableAlias and IgnoreVariable in a class as shown in the example below:

MODULE_TYPE = 'USER_MODEL_MODIFIER'

class ExampleUserModelModifier:

   def GetVariableAlias(self, variablePath: str) -> str | None:
      return 'myAlias' if variablePath == 'path/to/the/variable' else None

   def IgnoreVariable(self, variablePath: str) -> bool:
      return True if variablePath == 'path/to/the/variableToBeIgnored' else False

In this example, the variable with the path ‘path/to/the/variable’ is displayed in the model tree under the name ‘myAlias’. Any actions performed on ‘myAlias’ affect the variable ‘path/to/the/variable’. The variable with the path ‘path/to/the/variableToBeIgnored’, on the other hand, is completely hidden from the tree view and therefore cannot be selected for actions.