For software engineers who use Simulink to do Model Based Software Development (MBSD), the ability to manage variables, also known as signals and parameters in Simulink, has always been a challenge. It has been possible but not without shortcomings, especially when dealing with large software systems.
For those not familiar with Simulink, Here is a brief outline of what the past issues have been.
-
Data is Global – Anyone who writes software knows that global variables are generally bad news. Any part of the code can access the variable and write to it. The variable name is now reserved. Not to mention, there is no protection from issues like race conditions. It is not quite that bad in Simulink, as variables can be protected using mutual exclusion or described as parameters, preventing write access, however the other considerations remain.
-
Data is Not Encapsulated – Our data is not confined to particular rules, but generally guidelines are followed to make this appear better. Like in C we can define and use data anywhere, but adhering to guidelines causes us to create a data definition file for each model. Also, just like in C, developers are not constrained to this and sometimes a global file is created for all models in the system. This can get very large and hard to maintain.
-
Data is not Private – Even if a .m or .mat file is created for every model, several models may need access to the same variable. Caution must be taken for how the variable is stored, because it is possible to store it in multiple locations, and the last loaded has precedence on the definition. Another issue can be if two developers, working on two separate models as part of a larger system, both define a variable of the same name. If the parameter has different values, one model would work, and the other would not, leading to a lengthy debug session.
Based on my experience with the new Data Dictionary files in Simulink 2014A,(.sldd files) I believe they solve some of these major issues. Here is what I’ve found so far to help:
- Simulink now gives the ability to link a data dictionary. This is a good thing, however, I recommend using the reference dictionaries for any reusable models.
- The data dictionary is its own file, so if it is changed, these changes are identified, resulting in less opportunity for work to be lost. Additionally, changes are made to the file directly. This will help prevent inadvertent changes to the wrong files.
Mathworks has taken a much needed step in the right direction. I expect that the Data Dictionary will continue to evolve and help to promote good engineering practices in MBSD.
