The OpenECU project makes use of a naming convention to help make names and variables more readily understandable by humans. It is required that you adhere to this convention in your own models to make them consistently comprehensive to anyone else who may use your model (and to the Pi support engineers, should you need to talk to them about your design).
All names consist of a prefix, a descriptive body, and an optional suffix, separated by underscore characters:
A three letter prefix code identifying which group of functionality the named item belongs to.
A single letter identifying the type of the named item (not used for displayable signals). See Table 8.1, “Variable naming convention” for a list of types.
The item type letter is as follows:
Table 8.1. Variable naming convention
| Named item type | Type letter |
|---|---|
| Displayable signals | (no type letter) |
| Constant scalars | k |
| Calibration scalars | c |
| Calibration maps | m |
| Arrays | v |
| Local variables | l |
| Subsystems | (task rate code) |
Subsystem task rate codes are defined on a per-project basis.
The following conventions should be adhered to when designing variable names:
A suffix is used on names of parameters of blocks such as lookup tables, where the parameters have the same name as the block with a defined suffix appended.
Names are case sensitive, but no reliance shall be placed on this. All names should be lower case except where otherwise stated below.
The sense of any boolean variables should be clear from the name of the variable.
All names must be valid C language identifiers.
Where there are multiple words in the descriptive body of a data name, the underscore character '_’ should be used to separate the words.
Subsystems and Stateflow machines all have unique names. The name begins with the library prefix followed by a one letter code to define the task rate associated with that subsystem, and an underscore.
Where there are multiple words in the descriptive body of a subsystem or Stateflow machine name, each word should begin with a capital letter.
Axes and data for lookup tables should be given the name of the table, followed by a suffix. 1-d lookup tables have two parameters as follows:
Table 8.2. 1-d map lookup naming convention
Simulink parameter Suffix Example Vector of input values _x vaim_fuel_cell_temp_xVector of output values _z vaim_fuel_cell_temp_z2-d lookup tables have three parameters as follows:
Table 8.3. 2-d map lookup naming convention
Simulink parameter Suffix Example Row _x sffm_base_fuel_xColumn _y sffm_base_fuel_yTable _z sffm_base_fuel_zGiven that it is unlikely the data will be manually edited in MATLAB, the drawing convention above is adopted.
If a constant is literal (not a calibration item), its name will be in upper case and need not have the prefix. It is recommended, however, that the library prefix is retained (in upper case) for literals which relate only to one feature.
All calibration items and literals should be defined and have values assigned in the MATLAB base workspace.
Simulink ports are named as variables. Except for generic library blocks, the naming of ports should be consistent throughout the entire model hierarchy, such that differently named ports are never connected directly together.