Model-Based Design

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.

Foundations and core competencies

At later stages in the adoption of Model-Based Design

processes task-specific groups will emerge (development, verification, and systems.) However, at the start of the Model-BAsed Design process users from all groups need to determine the “common language” that will be used to develop their project (1).

Architecture and data sure, but why testing?

The identification of architecture and data as foundational concepts is generally well understood.

Combined they define how people will develop the model through interfaces and clear communication. So why testing in the trinity? It returns to the core concept of Model-Based Design that models are at the center of the development process. To ensure that the model can be used consistently through the development process they need to be “locked down”(2) with test cases.

Driven by this objective, the testing environment is designed at the start of the development process. The requirements of the test environment should be addressed within the architectural and data infrastructure. The good news is that best practices for the three “legs”(2) of the MBD stool are already in the well defined; it is a matter of honing them to your specific project and environment.

Footnotes

(1) I may start using this graphic as my tag for MBD adoption. Crawl = investigate. Walk = initial. Run = validated. Flying = optimizing.
(2) Tests cases are elaborated as the model is developed. The “lock down” is achieved through the use of a continuous build and test server.
(3) The metaphor of a tripod or stool can be overused. But, to push it one last time, this is your stepping stool to the next round of MBD tools and processes. Build it well and it forms a strong foundation.

Tag: Kittens