Intended Re-definition of parameters in simulink, overshadowing of parameter values

3 次查看(过去 30 天)
In C-Code there is a way to define a parameter using the #ifndef pre-processor directive. Is there a way to replicate this mechanism in Simulink, using data dictionaries?
For example, assume a vehicle system consisting of various subsystems. For this example assume a brake control system and an engine control system. To perform their calculations, both systems require to know the parameter "VehicleMass", so they define it as a parameter in their models. However, when they get integrated in a higher level vehicle model, the "VehicleMass" should best be described on the vehicle model level, to avoid incompatible / inconsistent definitions. But if it is define on vehicle model level, from my understanding it is currently required to first delete the lower level definitions, in order to avoid re-definition failures.
That causes another issue though, because if either of those lower level models is meant to be re-used, it can not be guaranteed that the top level integration model will always provide this value. What if the lower level model is meant to be standalone?
In C-Code, #ifndef checks if a value is already defined. If yes, that higher value is used. If no, a definition is done at this level. This mechanism prevents the issue described above.
In addition to parameters, I am experiencing the same issue with datatype definitions, so the lower level models use a given enum, but that enum might also be available in an integration environment.

回答(1 个)

Aabha
Aabha 2025-2-10
Hi @Marius,
To efficiently manage shared parameters and data types in Simulink, similar to the “#ifndef directive in C, you can use a combination of common and component-specific data dictionaries. A common dictionary stores model-wide data, that can be accessed by all independent components in the model. Each component in the model can have its own data dictionary as well, to organise data in a better way, and avoid redefinition of shared parameters.
To use this in your model, you can try the following steps:
  • First create a common data dictionary at the top-level model, through the “Model Explorer” dialog to store project-wide data that needs to be accessed by all subsystems. Migrate the shared data from the base workspace to this common dictionary.
  • Then, for each component, create a separate data dictionary, by clicking on the “New” tab inside the component properties.
  • Go to the component data dictionary, click on “Add” and select the common dictionary file to link the common dictionary to the component dictionary.
  • To migrate data from the base workspace to the component dictionary, select the desired component and click on migrate data. This will migrate all the data used by that component to the component data dictionary. During migration, any data already defined in the common dictionary will not be duplicated, thus preventing redefinition conflicts and allowing each component to operate both independently and within the integrated model.
The above actions can also be performed programmatically using the command line APIs that Simulink provides. You can refer to the following documentation for more information:
Additionally, enumerated types used by a model can also be migrated and managed using a data dictionary. Please refer to the following documentation to read more about how enumerated types can be handled in data dictionaries:

类别

Help CenterFile Exchange 中查找有关 Simulink Environment Customization 的更多信息

产品


版本

R2023b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by