Data dictionaries are primarily used to store data that will be shared across models, and they do not actually lend themselves to encapsulation of data for a single model, or hiding it from other models.
From the following documentation link:
When modeling a Standalone hierarchy of referenced models, you should, store local model data in each model workspace and store data that the models share, such as bus objects and configuration sets, in a data dictionary and link all of the models in the hierarchy to the dictionary.
So turning to the example you presented, we have Bus Objects defining the interfaces between the models, and we have parameter data specific to each model. The Bus Objects are needed at the top level and by both of the 1st level models in the hierarchy. This is an appropriate place to use a data dictionary. Since all of the levels of the hierarchy need to know about the interfaces, they can all reference the same data dictionary which keeps the definition of the Bus Objects in a single location. That way if the definition were to change, it will automatically propagate to every model and model reference that draws from the data dictionary.
With regards to the parameter K that is specific to each model, these should be defined independently in the Model Workspace for each of the referenced models. This is how you encapsulate data that is specific to a particular model. The model workspace definitions will be honored above any of the dictionary definitions, and are kept local to the model they are defined in. Even lower model references will not be able to see the definitions inside of higher model workspaces.
Here's something that helped me understand what a data dictionary acts like. A data dictionary behaves like a snapshot of the base workspace. When you tie a model to a data dictionary you tell the model to look at this snapshot of the base workspace to find definitions for parameters instead of the current workspace. The other behavior, which I think is where the confusion comes in, is that a top level model, must be able to see all of the "snapshots" that lower model references are looking at. This is what prevents the encapsulation behavior and leads to the conflicting definition errors we have been seeing.
Think about the following scenario
- The top level model is linked to TopLevel.sldd which references the dictionaries ABS.sldd and EPS.sldd
- The top level model contains model references to ABS.slx and EPS.slx
- ABS and EPS are linked to ABS.sldd and EPS.sldd respectively.
- ABS.sldd and EPS.sldd reference some other data pool stored in Lvl1Shared.sldd
In this scenario, TopLevel.sldd has visibility into ALL of the sub-referenced data stored in the other dictionaries. It's essentially identical to the case where you run this model hierarchy without data dictionaries. Instead of all of the necessary data being stored (and visible to the top level model) in the base workspace, it is now stored in a chain of dictionary references. This mimics the behavior you would expect if you were to use the normal base workspace configuration. All data needed for the top level model and all of the references would be defined in one singular base workspace.
So it begs the question why even bother with data dictionaries? If the data visibility is identical for a hierarchy what's the benefit?
One benefit is that dictionaries allow you to build modular "base workspaces", instead of needing to remember to initialize your workspace with all of the needed variables and definitions, you can pull data together from an existing set of smaller workspaces in a predefined manner.
Another benefit comes in remembering that model references are meant to be their own standalone models as well. With data dictionaries, all the "base workspace" data the model being referenced would need is now neatly packaged into its own dictionary, with references to additional dictionaries as necessary. This allows it to run independently of the hierarchy without worrying about what data needs to be loaded by initialization scripts or similar functions.
It also serves as a "header file" for the model that says, "here are all of the definitions that you will need to know to run this model".
Finally it allows for sharing of definitions that might not be model specific, or might need to be shared across a lower level of the hierarchy like in the case of the fictional Lvl1Shared.sldd.
Best Answer