In previous posts, I have covered data attributes and data usage. In this post, I cover data management. Within the Model-Based Design workflow, and traditional hand coding environments, there is a concept of model scoped and common data. This blog post will use Simulink specific concepts for Data Dictionaries to show how scoped data can be achieved.
What is in common?
Deciding what goes
into the common versus the model specific data dictionary is the primary question that needs to be asked at both the start of the project and throughout the model elaboration process. There is always a temptation to “dump” data into the common data dictionary to “simplify” data access. While in the short run it simplifies access, in the long run, doing so creates unmanageable data repositories. So, again, the question is “what goes in there?”
Common data type specification
The common data types consist of four primary entries, each of which is created as a separate sub-dictionary.
- Structure definitions
- Enumerated data types
- Data type aliases
- Model configurations
In all 4 cases, these bits of information should be used in a global scope. For example, structures used as an interface definition between two models or an enumerated data type that is used for modal control across multiple models. In contrast, structures that are local to a single model should not be part of the common data types sub-dictionary.
Common data
Like the common data types, the common
data consists of sub-dictionaries. In this case, there are three.
- Physical constants
- Conversion factors
- Common parameters
The first two are simple to understand; instead of having the engineer put in 9.81 (m/s) for each instance of the force of acceleration a physical constant (accelGravMetric) can be defined. Likewise, instead of hard coding 0.51444 you could have a parameter Knots_to_meter_p_sec. (Note: in the first case, 9.81 is a value that most engineers would know off the top of their head. The second case most people will not recognize and it results in “magic numbers” in the code. This is compounded when people “compact” multiple conversion factors into a single conversion calculation and the information is lost)
The final sub-dictionary, common parameters, is the most difficult to scope. Ideally, it should be limited to parameters that are used in more than one model; or more than one integration model. To prevent the “mushroom growth” of data in the common parameter data dictionary regular pruning should be applied.
Pruning your data
Pruning data is the process of examining entries in a data dictionary and determining if they are needed in the common data or in a model specific dictionary. Within the Simulink environment, this can be accomplished using the model explorer or programmatically
Model and integration model data dictionaries
In the section on model architecture, we discussed the concept of “integration models.” An integration model consists of multiple sub-models, which, in turn, may contain sub-models.
The pattern for the integration model data dictionary mirrors the pattern that was shown in the initial diagram; the “twig” of the model tree references the branches, which in turn reference all the way back to the root.
Final thoughts
The use of scoped data dictionaries allows users to logically organize their data while minimizing the amount of work that individual contributors need to take to maintain the data. This approach does not eliminate the need for data maintenance however it does provide tools to aid in the work.
Like this:
Like Loading...
