The model identification block specifies which ECU hardware to target and information to be recorded in the built model and calibration image.
None (Main library). (See Section 2.3, “Licensed Features”.)
The model identification block is usually placed in the top level Simulink diagram of the model. It contains a mask entry which can be used to display a description of the model.
The model identification block also specifies the following information which is recorded in the built calibration image:
model version numbers (major, minor and sub-minor);
copyright description.
In the case of the copyright description, the information is placed in the model image and the calibration image.
The model identification block also selects the target hardware the model will expect to run on. This parameter should be selected when the model is first created. Changing the parameter later on has consequences (see the Notes section for the put_Identification block for more details).
Specifies the name of the ECU that the model will run on. Selection of the ECU type changes the possible inputs and outputs on other blocks. The parameter should be selected at the start of the model but if it must be changed later (for instance, moving to another hardware platform to reduce costs) then consult the Notes section for the put_Identification block for more details.
Value type: | List | ||
Calibratable: | No |
Specifies the hardware part number that appears on the ECU casing, followed by a hyphen and a three-character suffix. This suffix denotes the option. Only those options that require special software support are explicitly listed. If the option is not explicitly listed, then option 000 should be selected.
Value type: | List | ||
Calibratable: | No |
Specifies the issue or revision number of the ECU that the model will run on. This is the first number that appears after the hardware part number on the label of the ECU. For example, if "2m4" appears after the hardware part number, then the issue number to be entered is 2.
Value type: | Integer | ||
Calibratable: | No |
Specifies the type of names used for pin and channel identification. Generic pin naming uses the following terms for each pin.
Table 5.4. Generic pin naming convention
Name | Description |
---|---|
AIN | Analogue input |
AOT | Analogue output |
DIN | Digital input |
DOT | Digital output |
Monitor | Feedback signal from output driver circuitry |
Powertrain pin naming uses a scheme that shortens the typical application naming given in the target specification tables linked to in Section 1.1, “ECU hardware reference documentation”. The default selection for this drop-down is Powertrain pin naming to maintain backwards compatibility with existing models.
Value type: | List | ||
Calibratable: | No |
Specifies the name of the model/application. The name has no functional effect on the model but is used when generating ASAP2 files and in response to the CCP EXCHANGE-ID message.
The name can include tokens which are automatically converted during model build. Tokens
are single words starting and ending in the “%
”
character. For instance, the string “Application for
%target%
” contains one token named target,
which is converted to the target ECU name during a model build. The following table
lists the available tokens:
Token | Replacement |
---|---|
%copyright% | Replaced with the string from the Copyright parameter. |
%target% | Replaced with a string representing the ECU target and option. |
%ver-major% | Replaced with the string from the Major version number parameter. |
%ver-minor% | Replaced with the string from the Minor version number parameter. |
%ver-subminor% | Replaced with the string from the Sub-minor version number parameter. |
The name can be read from the target at run time by displaying the
mpls_app_name
automatic ASAP2 entry.
Value type: | String | ||
Calibratable: | No |
Specifies a description of
the model. The description is displayed in the block.
This has no functional effect on the model. The
description can be read from the target at run time by displaying the
mpls_app_description
automatic ASAP2 entry.
Value type: | String | ||
Calibratable: | No |
Specifies the major
version number of the model. This has no functional effect on the model. The
version can be read from the target at run time by displaying the
mpl_app_ver_major
automatic ASAP2 entry.
Range: [0, 255]
Value type: | Integer | ||
Calibratable: | No |
Specifies the major
version number of the model. This has no functional effect on the model. The
version can be read from the target at run time by displaying the
mpl_app_ver_minor
automatic ASAP2 entry.
Range: [0, 255]
Value type: | Integer | ||
Calibratable: | No |
Specifies the major
version number of the model. This has no functional effect on the model. The
version can be read from the target at run time by displaying the
mpl_app_ver_subminor
automatic ASAP2 entry.
Range: [0, 255]
Value type: | Integer | ||
Calibratable: | No |
Specifies a copyright string
that is embedded in the generated image. This has no functional effect on the model. The
copyright can be read from the target at run time by displaying the
mpls_app_copyright
automatic ASAP2 entry.
Value type: | String | ||
Calibratable: | No |
The Description parameter text can usually be split into multiple lines
to make it more readable. As the edit box of the description provides for a
single line only, a new line can be inserted by added the characters
\n
where a new line is required.
Changing the ECU type parameter affects which inputs and outputs are selectable in other blocks. This is also a risk when changing the parameters Part Number and Issue Number. If a model contains such blocks, then when the target hardware is changed, the inputs and outputs change when the model is next loaded or when a block is updated. If a change in hardware is necessary, then the user should work out how the inputs and outputs will change between hardware targets, then open the model, change the hardware selection, save and close the model, then reload the model and modify each block input or output appropriately.
Accidental changes to the hardware target may leave the block inputs and outputs in an undefined state.