Month: February 2019

Sometimes, when you wander the web, you come across a story that makes you think about your job in a new way. This one, about “legal Lego builds” did just that.

Lambrecht describes “the model that forever changed LEGO,” an Audi TT that was difficult to put together, required the user to deform components for them to fit, and came with no instructions.

The article (or more accurately the linked PDF) is interesting for three reasons.

1. Change came after failure: Lego’s are a famous brand and, having been around for 80+ years you would assume the have their bricks together(1). However, entering the brave new world of “build sets” the found that they needed to adopt standard building rules
2. Unit test to find system problems: Some integration issues can only be detected in the full system, however upfront consideration of interfaces and tolerances can prevent large scale issues.
3. Legal but on the boarder: The PDF shows legal / illegal and “boarder” cases. Sometimes the “boarder” is the only solution to the problem; but when you find yourself in a “it’s the only way” case, spend some time to figure out if that is really the only way.

Small rules

With Model-Based Design what are the “small rules” that I would recommend following?

1. Adopt a style guide: For MATLAB and Simulink Models consider the use of the M.A.A.B. Style Guidelines.
2. Speed counts: A slow small function slows down your system. Each additional system slow system (or repeated instances of the same system) add up to a slow integration.
3. Self contained: Models should be able to execute on their own, e.g. not requiring external infrastructure to execute. This is the distinction between a functional and an integration model.
4. Swiss army knife: When I’m out hiking a Swiss army knife is a reasonable lightweight tool to bring to handle unexpected issues. Models should serve a purpose, not 100, that is why we have systems.

Footnotes

1. No apologies for the bad play on words.
2. Google image search can return things you would never expect
3. Yes this is a real

If you find this material interesting, please subscribe to the blog for regular email updates

The area under the curve, infinitesimally small slices, the integral is integral to control algorithms. With that in mind I wanted to point out a few “edge cases” in their use with in the Simulink environment.

Case 1: Standard execution

The standard execution would be inside of a continuously called subsystem. From calculus, remember that the integral of sine = cosine + C; which is what we see when we plot the results. So far so good.

Case 2: Execution context

Let’s look now at what happens when your execution context is not contiguous; in this case a conditionally called subsystem. In this case I will use an enabled subsystem to periodically call the integrator.

For this first example I reduced the sample rate by 50%. (E.g. the ramp function toggled between 0 and 1). As a result while the shape of the output is correct (a cosine) the amplitude is 1/2 the original value. I could correct by adding a gain factor on the output (or in the integral).

Note: when sampling data it is critical that the minimum sampling frequency is at least 2X faster than the frequency of the signal. This is know as the Nyquist Frequency

Case 3: Non-periodic

In some case sampling is event based. In this case it is critical that the events are more frequent than the Nyquist Frequency. However, since they cannot be assumed to be at a simple periodic frequency you cannot use a gain factor to correct for the sampling bias.

The simplest solution is to increase the frequency of the sample, the higher the frequency the more accurate the results.

Baring that a custom integrator can be applied that interpolates off of the last N data points and the temporal gaps; however this approach will not work if the temporal gaps are large or if the data is rapidly changing…

Case 4: Function called integrators

The final case to consider is when the integrator is part of a function call system. In most cases this will act like the periodic instance show above; there is however a special case, when the same function is called more than once in a single time step. In this instance only the first signal passed into the function will be “integrated”. Why?

Remember that integration can be expressed as a sum of slices multiplied by the time step. For the first call to the function the delta in time is the time step. For subsequent calls the time delta is zero.

If you need this functionality consider passing in the DT value as an external variable or performing the sum of two different function calls.

If you are enjoying these posts, please consider subscribing to them.

Handing a model off between developers, or from developer to user, is one most common tasks in Model-Based Design.  So what steps should you follow to insure that the hand-off is successful?

Step 0: Agree upon the requirements

A few weeks ago I made muffins, lemon poppy-seed; while my wife was happy to receive the muffins she had requested chocolate-chip muffins, a classic requirement error.

In the much simpler world of model hand off the following items need to be defined

• The functional interface: inputs, outputs and rate of execution
• Behavioral characteristics: what behaviors does the model cover; what are the “corner cases” that it does not cover.
• Supporting files: most models require models, libraries and data. For parameterized models the same “model” will act  differently with different data.
• Acceptance criteria: a set of defined metrics that define what is required; these should be derived from the behavioral characteristics.

Step 1: Model validation

Assuming you have acceptance criteria the model validation is the process of validating the model against the criteria.  Ideally the methods for validating the model are established at the start of your project and are run routinely as the model is developed.

Step 2: Wrap it up!

Delivery of the model is important, there is nothing more frustrating then getting your shinny new model only to find out you are missing a library or a data file.  There are several methods for addressing this

1. Version control software:  If the model is checked in as part of a project the end user can check out the full repository (note: this can result in file bloat)
2. Use of  Simulink Projects: A tool from the MathWorks that allows for the definition of model projects.  It will analyze the required files for you and create a package for distribution.

If you find this content useful, please consider subscribing