Simulink is a powerful tool for developing application logic for an embedded system. Developing software using Simulink has numerous well-documented advantages over hand coding. However, as a model grows in size and complexity, the data connections that link the various sections of the model become more and more difficult to manage.
Common solutions to this data problem include increasing the number of m-scripts and implementing complicated networks of Simulink buses directly connecting data between modeled components. Even with the most well-architected model, determining basic facts about the data can be challenging – What should the data type be? Which part of the model “owns” the data? Where is it actually used? What is the exact name of a particular piece of data? Many engineers have gotten derailed looking for basic information such as this, when all they really wanted to do was get their work done. There must be a better way.
Imagine you have a Simulink model that consists of several interconnected features. You are tasked with updating one of these features (let’s call it Feature X). Starting from the existing model, you are about to replace Feature X with the latest baseline version developed elsewhere in your organization.
Easy, right?
Well, not so fast.
Much of the interface to this feature is the same, but there are several new inputs that have been added, and a few outputs as well. And some of the pre-existing inputs have slightly different names than before. Is that important?
What information would you need to be able to confidently connect this new feature with the rest of the model? For each new or modified interface to the feature, you need to determine:
The Signal/Parameter Name, its Data type, the Units, the Scope (is the Feature allowed access?)
The Old Way
So, what tasks need to be done to determine that information? Assuming common approaches to data management, the workflow would be something like this:
The Better Way – UniPhi
If your organization uses UniPhi, the process is much simpler. UniPhi allows for the definition of not only the data utilized by a system, but the interfaces between components of the system. The workflow would then look more like this:
The scenarios described are, of course, specific to a particular set of circumstances and assumptions. As always, your mileage may vary, but the assumptions made here are based on the collective Model-Based Design expertise built up at SimuQuest over the past 19 years – and we believe in continuing to push the envelope of what embedded software development through model-based design can achieve.
