In my last post, Execution order and Simulink models, I promised a look at scheduling best practices using Stateflow; in this post I hope to deliver. Simple periodic scheduling In our first example we will… More

## Is your system architecture “Lego Legal”?

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.

**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**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.**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?

**Adopt a style guide:**For MATLAB and Simulink Models consider the use of the M.A.A.B. Style Guidelines.**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.**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.**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

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

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

## Everything is our sum

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.

## Best practices for Model Handoffs

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

**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)**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

## PID Life

If you work in the controls design space then the PID (Proportional, Integral, Derivative) control element is an old friend. For those of you who do not work in the domain here is a quick overview.

## Observe and correct errors

A PID controller can be viewed as an optimization function with three terms. The system attempts to minimize the error between the observed and desired values.

**P term:**The greater the relative error the stronger the command**I term:**The longer the error goes on the stronger the command**D term:**The greater the change in the error the more the command changes

## All wound up**I**

**Integral windup** refers to the situation in a PID feedback controller where a large change in setpoint occurs (say a positive change) and the integral terms accumulates a significant error during the rise. This results in overshooting the target. Over time the error (now negative) will drive the integral to zero however this will result in an extended period of time in error. There are several solution, including this one as documented by The MathWorks

## Derivative work

The derivative term in the PID control “dampens” the rate of change of the error term. However, due to difficulties in tuning systems with derivative terms this is often left out of the control algorithm

## Overview of all terms

**Rise time:**How long it takes the system to reach the target value**Overshoot:**How much the model goes “past” the target value”**Settling time:**How long it takes the system to zero out the error**Steady state error:**What is the final error (can it reach zero?)**Stability**: Effect of noise on the system

As you increase value the term…

Parameter | Rise time | Over shoot | Settling time | Steady state error | Stability |
---|---|---|---|---|---|

P | Decrease | Increase | Small change | Decrease | Degrade |

I | Decrease | Increase | Increase | Eliminate | Degrade |

D | Minor change | Decrease | Decrease | No effect | Improve if D is small |

If you find this content useful, please consider subscribing

## What really matters…

Recently I was talking with a co-worker about an image detection model and they mentioned the now “classic” question of how do you deal with weather obfuscation of data.

We quickly moved from static obstruction (the snow covered stop sign) to the dynamic obstruction of rain and snow.

Starting from first principals you can quickly out line the factors that contribute to the model

**Rain / Snow density**(drops / flakes per m^3): This is a measure of storm “intensity”**Size**: How large are the snow flakes / rain drops**Wind speed:**This effects how the flakes / drops move, it is complicated by wind gusts.**Camera velocity:**Is your camera moving?**Depth**: How far away is the object that you are viewing

There already exist a number of interesting papers that examine these parameters in full. My real question is “Do I want to model the rain or the effect of the rain on my algorithms”?.

In some cases it may be necessary to fully model a the behavior. In others a simplified characteristic model can be used. Let us look at what we determined was important.

## What really matters…

Given that objects, in general, don’t change their shape(1) it is possible to filter out the noise of rain or snow. What we need to understand is how rain or snow *obscure * objects.

**Interposition**: Every drop of rain and every flake of snow acts as a “point barrier” between the camera and the object.

Take the simple example: for an object 10 meters away the extent of “obscuring” is a function of the rain density and the droplet size; further the distance between the camera and the object (depth) determines the extend of the obstruction. What then should we do with with the wind? How should we model the movement?

It turns out, not much. When I compared the effect of random movement of the patterns with the wind models the effect on obstruction there were negligible difference for the vision application.

## The moral of the story…

- Modeling systems is a question about what is required for your analysis. Knowing this I can create the minimal model that is required to perform my tests.
- Developing simplified models start with an understanding of the “real” system

**Footnote**: 1: The profile of the object may change as the relative angle is changed.

If you find this content useful, please consider subscribing

## Consulting ethics:

For most of the last 25 years I have worked in a consultative capacity; during that time I have come to a set of principals that define what I consider an ethical frame work as a consultant.

## Honesty: Time, Talent and Tools

In all interactions with a client honesty is the foremost byword. This shows up in three areas.

**Time:** Projects take time. Estimating how long a project takes is a skill that develops with experience. When providing an estimate to a client always use your best judgement as to how long the project will take enumerating the tasks to be completed and the potential unknowns. If an accurate estimate is not possible due to a lack of understanding you should consider if this is the correct type of project for you to be working on.

**Talent**: When I speak about talent I am thinking about the sum of the things that you or people you work with have a strong understanding of. When starting a project my rule of thumb is that my team should understand at least 80% of the project scope. Why 80% though and not 100%? My assumption is that for any project, outside of turn key implementations, there is project specific knowledge that my customer has that my group will need to learn to best help out. A critical early part of any project is coming to terms with that unknown 20%.

**Tools**: There an old saying “when all you have is a hammer, everything looks like a nail”. Selecting the correct tool for any job is important. Not forcing a tool because you work for a company or it is something you are familiar with is ethical. In the end select tools being aware of the cost (both of the tool and in time spent to work with the tool) versus the functionality (what percentage of the issue does the tool address.

## Understand what customer needs…

A story I have often told is about the first consulting contract I worked on over 20 years ago. The customer requirements were well written, scoping things out fully. I had the required skill set to implement what they requested and the tools were available “in-house” for the customer. After 200 hours of work (out of an estimated 220) I handed over the finished product and the customer went away happily. However, in hindsight what the customer asked me to do wasn’t what they needed me to do; I solved the symptom, not the problem.

There are two things to take from this, first during the initial interview it is critical to get to a solid understanding of what the root issue the customer is trying to solve. Second it is important to be able to convey to the customer why a proposed solution may not address the underlying problem. (If you already know how to solve the problem then you are hiring a temporary employee, not a *consultant*).

## Stand behind what you deliver

For most consulting projects the works is completed within a handful of months. The customer will continue to use what you to taught them and delivered to them for years. In the 25 years I have been working I have always been ready to speak with old customers about what I did to help them with the unexpected curves they hit.

If you find this content useful, please consider subscribing

## Math! Solving problems, making friends…

A few months ago there was an interesting article about AlphaGo and deep learning. What made the solution interesting is that AlphaGo determined a new strategy for playing Go, e.g. it wasn’t just replicating the best of current players, it was creating something new.

So this got me thinking about sensor placement. Let’s say you are building an autonomous vehicle; you give it radar, LIDAR, cameras, heck even a person walking 5 feet in front of the car with a red flag. But how do you know what the best configuration of those sensor is? This is where math and deep learning can come to the rescue.

## It’s research, dam the budget!

With research vehicles it is common to go high end with the sensors and processors. Often the number of sensors are far in excess of what the final vehicle will have; the question then becomes “If you train your controller using 10 sensor and the final vehicle will only have 3 do you have to retrain?”

So here is the insight, in regression there is the concept of a synthetic variable. E.g. you can take the raw data X and put X^2 into the equation. What if, for sensor data, you optimize for sensor position?

**Step 1:** Train your model using the full set of sensors. Train it until you reach the highest confidence level you can.

**Step 2: **Define the set of equations that will take your original sensor data and use them to create “artificial” sensor at arbitrary locations. E.g. if you have 10 LIDAR sensors, then it could be that

AS_1 = func(X1,Y1,Z1) = func(L1,L2,L4,L6)

AS_2 = func(X2,Y2,Z2) = func(L3,L4,L7)

AS_3 = func(X3,Y3,Z3) = func(L2,L6,L9,L10)

**Step 3:** Using the already trained data train the new sensor array

**Step 4:** Optimize the models as a function of the sensor placement and number of sensors

## Sensor fusion before the sensors…

I think of this approach as “sensor fusion before the sensors”. What is interesting about this approach is that it is possible that we could discover a combination of sensors (and yes this should be done with multiple sensors) that has a higher accuracy and lower costs than we expect.

If you find this content useful, please consider subscribing

## 11111100010 to 11111100011 Every bit makes a difference

Welcome to the year 2019, the first post of the year (or last post of the year) generally are places for retrospectives/forward looking visions. I shall keep to the form.

## Excited: 2018

There are multiple things to be excited about this year, the following are what I a found most exciting

- .
**Simplified methods for integrating C with models:**MATLAB and Simulink added new functionality to improve the integration of C code and Models, either by including code in the model (C-Caller block) or by simplifying the function interface definition. **Projects, data dictionaries and testing:**MathWorks continues to work on the integration between Simulink Projects and the supporting tool chain, these improvements coupled with version control software integration make the tool powerful for team based development**String support:**For better or for worse, strings are a part of control systems, after many years Simulink has native support.

## Looking forward: 2019

**Machine learning:**Ok, sure I just got started but already there are a number of interesting question (and lovely math) that I am enjoying.**Systems of systems:**The scope of Model-Based Design projects continues to expand, the analysis of system of systems is an area I’m excited to move into.**Statistical validation:**As our systems become more complex statistical analysis (DOE) becomes more and more important

If you find this content useful, please consider subscribing

## Apples and Oranges

There is an old saying that “You can’t compare apples to oranges”; but frequently as an engineer, one of our jobs is to compare apples to oranges. Why and what does that mean?

Frequently, when systems are built the actual system does not yet exist. As a result, we need to draw analogies between the two items. So if we are going to compare apples and oranges how do we “juice” them for the correct data?

## The mapping between objects: first principals

One objective with these mappings is to reduce the volume of first principals modeling that needs to be done; e.g. instead of building up a complex system of equations, use a modified data reduction of an existing system modified for the new system. However, to do that, we must first validate that the fundamental behavior of the systems scale between each other. For example, scaling a 4 cylinder 1.8L engine to a 2.1L engine is straight forward. To go from a 4 cylinder to an 8 cylinder is also straightforward if a slightly different problem.

## What is the same? What is different?

You selected the reference model because there are things that they share in common. At the same time, there will be things that are different. In our example of the 4 cylinder to the 8 cylinder engine, there are differences in total displacement (an easy mapping) torque output excetra. The thing that may not be easy to map is the change to the in the vibrational aspects of the engine. The questions to ask are

- What physical aspects of the system am I concerned with?
- Torque
- Fuel consumption
- Max rpm
- …

- What aspects am I not concerned with?
- Vibration
- Heat transfer
- ….

If you find this content useful, please consider subscribing

## The truth about regression…

So my first step into machine learning is examining supervised learning and my old friend curve fitting. This was a fun trip down memory lane as my numerical mathematics background had me well prepared for this topic. Further, in the 25 years since I graduated, the basic tools for performing regression analysis have greatly improved, I was able to use the built-in curve fitting tool in MATLAB to perform these operations directly. At the same time, I quickly remembered the “gotchas” about regression…

## Starting points

As a starting point, I thought I would see how well the tool would do with a known polynomial equation. I defined a simple 3rd order equation and added some noise into the signal. I then ran the results through the curve fitting toolbox…

As a sanity check, I first tried it out using the “real” X and Y data. As would be expected the tool spits back out the coefficients that I expected. When I ran it with the noise (and telling it to use a 3rd order polynomial) it returned coefficients fairly close to the “real” things.

Coefficient | Original | Regressed “Real” | Regressed “Noise” |
---|---|---|---|

P4 | 0.0 | -3.79e-14 | -0.745 |

P3 | 1.5 | 1.5 | 3.05 |

P2 | 1.2 | 1.2 | 0.8709 |

P1 | -0.5 | -0.5 | -0.522 |

R-Square | NA | 1.0 | 0.9939 |

Within the defined range we have an R-squared value of 0.9925, pretty darn good. But, the question quickly becomes, how does it hold up outside of the known range?

So depending on how you want to look at it, as an absolute error or a percentage error you may be doing “O.k.” or not. But what if I didn’t know what the underlying equation was? A power function would seem like a reasonable. If I try a first order power equation

y = a * exp(b * x)

or second

y = a * exp(b * x) + c * exp(d * x);

Order | R-square |

1st | 0.9852 |

2nd | .9961 |

Within the original bounds, the R-Squared value is close to the actual polynomial. If we used the 1st order equation just in that region it executes faster then the 3rd order polynomial so we may want to go with a “fake fast fit”. (say that three times fast).

## Why do we try to “fit-in”?

There are several reasons why regression is performed. Sometimes it is because the underlying equations are unknown, are too computationally expensive, there isn’t an equation. Regardless of the reason when I am trying to perform a regression I perform the following steps

**What are the fundamental physics:**Use this to pick out which terms and functions to use. (Note: The curve fitting toolbox has an wonderful “custom equation” option that let’s you try these equation based approaches out)**Boundaries?**I try to understand how the data outside of the known data set? In my example the exponential function does not perform well much outside of my known data.

## Disclaimer:

Roughly 30 minutes after I finished writing this blog post I stumbled across this post

“Explore Runge’s Polynomial Interpolation Phenomenon” by Cleve Moler. I would be amiss to not include this link for three reasons

- Cleve’s post clearly articulates the mathematical underpinnings of interpolation
- As the creator of MATLAB, his work is why things are “greatly improved”.
- It’s a post about Runge, and since I had a cat named Runga-Kutta (RK) back in college well…

## Warning: Bad aerospace engineering pun follows:

When I was in grad school and had that cute cat I was working on a simple project, a device to determine the terminal angle (stall) for a kite. For the most part, I worked on this project in my apartment, and Runga loved to attack the kite’s tail, jumping at it attacking it. That was well and good in the apartment.

Well at the early testing stages I was flying the kite off of my back deck. One day while flying RK managed to get out. In a leap of excitement she jumped onto the kite’s tail (knowing from experience she would land happily on the carpet). Except, this time, the kite was 8 feet off the ground. Needless to say, both the cat and the kite crashed to the ground proving that for this case the Kutta condition did not hold.

If you find this content useful, please consider subscribing