Understanding data usage in Model-Based Design Part II

In the last post we looked at the characteristics of data now we will at how those characteristics define and support the model.

Data defines the model behavior

Let’s imagine a model “estimate time to debug software.”  The first thing we could consider is the following simple mathematical model

bugsFound =3 * exp(timeCoef * T) dT
where: T = [0 : 7.5] (half hour lunch break)
timeCoef = [-0.1 : 0.2]

And consider two parameter sets

  • Bored test engineer: timeCoef = -0.1
    • Bugs found in 7.5 hours: 15
  • Engaged test engineer: timeCoef = 0.1
    • Bugs found in 7.5 hours: 52


With this simple example, we see that changes to data affect the results of the model (equation).  In the actual model, we see multiple parameters associated with the “engaged” and “bored” test engineers.

Parameter Comment
BugsPerLine Common
LinesPerHour Engaged > Bored
GramCoffeePerHour Engaged < Bored
TimeAllocatedToFindBugs Commom

In a system level model, comprised of multiple integration models, there are multiple parameter sets.

Closed loop vehicle control algorithm and plant model

In this example, we have two top-level integration models, the controller, and the vehicle plant model.  Within those integration models, there are multiple parameter sets

  • Engine
    • number of cylinder
      • 8 cylinder
      • 6 cylinder
      • 4 cylinder
    • Throttle body
      • Standard
      • Turbocharger
      • Supercharger
  • Transmission
    • ….
  • Drive line
    • …..

Next steps

As this post shows the amount of data consumed by a set of models quickly grows in complexity.  In an upcoming post, we will look at best practices for data management.

One thought on “Understanding data usage in Model-Based Design Part II

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.