Is there a better way to organise my data dictionary and still have acces in Simulink and Stateflow?

Hello there :)

I have just started working with data dictionaries as I am currently building my first larger Simulink model. My first thought was to create a struct with different parameter objects for different submodels in order to get a structured division of my dictionary and not run the risk of losing the overview.

Unfortunately, I then realised that many object types such as Simulink.LookupTable objects within a struct in the data dictionary are not recognised in Simulink.

Here is an example code:

ModelDictObj = Simulink.data.dictionary.open('ModelDict.sldd');

dDataSectObj = getSection(ModelDictObj, 'Design Data');

lut = Simulink.LookupTable;

lut.Table.Value = someValues;

lut.Breakpoints(1).Value = someBreakpoints;

someStruct = struct();

someStruct.lut = lut;

addEntry(dDataSectObj, 'someStruct', someStruct);

saveChanges(ModelDictObj);

ModelDictObj.close();

Like this, the Lookup Table Block can not access the LookupTable object inside the dictionary in the Simulink model (using this code inside the lut-Block: someStruct.lut). It can only do this if the lut has been stored in the dictionary without the nesting in a struct.

My question now is whether there is a best practice solution to store different object types, including LookupTables, SimulinkParameters, MatlabValues and in the best case also SimulinkSignals within a dictionary in such a way that you get a hierarchical overview that fits my model hierarchy (a ‘folder’ for each subsystem for example).

I also have similar problems when accessing data dictionary data within a Stateflow model. The nesting of the files in structs does not seem to work there either. Currently I use ‘data store memory’ blocks for the necessary constants or signals. As a result, I have the problem that I can change values at different points in my model. Is this necessary or is there a way to directly access the values stored in the data dictionary within stateflow?

I would be very grateful if someone could give me some advice on best practice.

Many thanks in advance and best regards,

Danus Rawert

Answer 1

[Githin George]

Hi Danus,

Managing data dictionaries in Simulink can indeed be challenging for large models. But you could try out the following tips in order to improve the management of your "Desgin Data" for Simulink.

1) Flat Structure with Naming Conventions:

• Since Simulink does not support accessing nested structures directly in blocks, consider using a flat structure in your data dictionary.
• Use naming conventions to simulate hierarchy. For example, use names like Subsystem1_LUT, Subsystem2_Parameter, etc. This approach maintains clarity and organization without nesting.
• But for very large models, this may not be very relevant.

2) Custom Data Types and Buses:

• For grouping related parameters, consider using Simulink.Bus objects. Buses allow you to group signals logically without nesting them in a struct.
• Define a Bus object for each subsystem and use it to bundle relevant signals.
• The following MATLAB answers post suggests a good way of managing the Simulink.Bus objects as well: https://www.mathworks.com/matlabcentral/answers/229389-bus-objects-using-multiple-data-dictionaries-in-large-models

3) Separate Dictionaries:

• If your model is large and consists of multiple subsystems, consider using separate data dictionaries for each subsystem. This can help in managing the data more effectively and maintaining a clear structure.
• The following MathWorks documentation is a very good read if you are using a lot of Model References in your model: https://www.mathworks.com/help/simulink/ug/compose-dictionary-hierarchy.html
• For information on "reference dictionaries" you can refer to: https://www.mathworks.com/help/simulink/ug/partition-dictionary-into-reference-dictionaries.html

The above tips should resolve the issues with Stateflow as well, since you can directly access the data from SLDD if it is defined as "Data"

To summarize, I think your next steps would be to explore how you can manage your "Design Data" using multiple dictionaries instead of making your design data itself a complex one.

I hope this helps.