The OpenECU build mechanism relies on particular settings for the model, e.g., that it can be solved with a discrete solver not a continuous one. The following simulation settings should be configured when converting any model for R2015a.

or the following simulation settings for R2015b:

or the following simulation settings for R2016a:

or the following simulation settings for R2016b:

or the following simulation settings for R2017a:

or the following simulation settings for R2017b:

or the following simulation settings for R2018a or R2018b:

or the following simulation settings for R2019a, R2019b, or R2020a:

The pre-load and post-load hooks are settings in a Simulink model which are executed before the model is fully loaded and after the model has been fully loaded. OpenECU uses these hooks to perform extra actions that Simulink does not normally perform.

These settings can be set using the following commands when the model is selected:

set_param(bdroot, 'preloadfcn',  'openecu_make_rtw_hook(''model_load'', ''mn'');')
set_param(bdroot, 'postloadfcn', 'openecu_make_rtw_hook(''model_loaded'', ''mn'');')

where mn is replaced by the name of the model.

If in doubt, it may be easier to create a new model using the

command and copying the systems and blocks to this new model.

OpenECU provides a put_Identification block which identifies the target hardware the model will run on. Before a build can complete, this block must have been added to the model. Without this block, a RTW build of the model will fail.

When adding a put_Identification block to a model for the first time, it is best to set the block's target hardware parameter then save, close and reload the model. This ensures that any other OpenECU block in the model is adjusted for the newly selected hardware target.

The OpenECU device relies on a discrete solver and therefore any block that relies on a continuous solver will not work on OpenECU. Each of these blocks must be replaced by a discrete equivalent. E.g., a continuous transfer function block to a discrete transfer function.

Some MATLAB and Simulink tools exist to help perform these transformations, for instance, the tustin approximation.

The OpenECU device is based on a commercial engine controller and therefore uses a commonly available processor to execute the model. Processing power is therefore a resource that must be managed well and it is important to refactor your model so that computation is spread over various model rates.

For instance, when reading a slow changing analogue input and processing its state, it is often best to place the analogue input block to a model rate which is reflects how quickly the analogue input can change. This avoids iterating portions of the model on a frequent basis that produce similar values to previous iterations. If the slow changing analogue input is subsequently used by a faster portion of the model, this can be accommodated using Simulink blocks (an example of how to transfer information between different model rates is given in the multi-rate demo, see Section 3.2, “Installed examples”).

OpenECU provides information about how long each of the model rates takes to run as well as the percentage processor loading that can be viewed over CCP (see Section 5.2.5, “Application and library task timing information”)

OpenECU requires information about display variables and calibration variables in order to generate files required by calibration tools. This information is supplied to OpenECU via a data dictionary. For further information, please see Section 4.2.2.2, “Data dictionary files”.