By Steve Fowler
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. But 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 numbers of m-scripts, and often 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 a scenario…
You have a Simulink model that is comprised 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.
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:
So, what tasks need to be done to determine that information? Assuming common approaches to data management, the workflow would be something like this:
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 above scenarios 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 15 years of being on the cutting edge of what embedded Model-Based Design can be.