Stateflow scheduling: Examples

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 look at simple periodic schedulers. Let’s assume we have a system with three rates, 0.01 sec, 0.1 and 0.2 seconds. This can easily be implemented in Stateflow with the following chart.

If we look at the “activation” for each of the task sets we would see the following.

Yellow = 0.01, Blue = 0.1, Red = 0.2

In this case you can see that each of the tasks are being triggered at their given rate, at 0.1 second both the 0.01 and 0.1 activate; at 0.2 all three are active. In many cases this is fine, the order in which these tasks is set by the order in the chart (e.g. 0.01, 0.1 then 0.2). However you may want to “space out” the activation. In that case a Stateflow chart like this would be the solution.

In this case three parallel states are created. The 0.1 and 0.2 rates have “offsets” so that the execute out of sync with the each of the tasks as shown in the resulting execution graph.

Offsets on the charts.

Mode based scheduling

Beyond rate based scheduling mode based scheduling is the next iteration of the scheduling examples.

Stateflow after dark…

In this example the scheduler is decomposed into three parallel states, the “Main” or rate based state; a mode based state and an event based state. The main state is similar to the two previous examples so lets look at Mode and Event.

Feeling the mode

There are three things of note here; first within this state we start the system off in the “Initialization” state. This is a safe selection as most systems start off in “Init”. Next, movement between the states is controlled by the input variable “Mode”. Use of the ‘hasChanged’ method gates the transitions between the different modes allowing the user to switch from any of the modes without having complex routing logic. Finally the mode “Emergency” is for the non-critical scheduling responses to emergencies. Any actions that fall into the true emergency mode should be event driven so their execution starts immediately.

The main event

Our final example here is event driven scheduling; within this chart we have the “React” states and a “Null” state. The null state is present to provide a “no-operations” mode when the events are not active. Two things of note, in this example events are mutually exclusive; this does not need to be the case. Second, the current example exits the “React” states after one execution. The exits could be guarded to continue execution until the event is resolved.

If you are enjoying what you are reading consider subscribing to the email version of this blog.

Execution order and Simulink models

When you program in the textual language execution order is directly specified by the order in which you write the lines of code.

  1. My Function
    1. Do A
    2. Do B
    3. Do C

With multiple functions, a threaded OS or event driven interrupts this is more complex, but at its’ heart it is directly specified in the language. In contrast Simulink determines execution order based on Data Flow.

Which executes first, Chicken or Egg?

The principal of data flow based execution is that calculations are performed once data is present. We will start with the simplest example possible, one path direct feed through.

In this example we have a data flow from left to right (Inport #1 to Outport #1). The calculation is
Output = Input * Chicken * Egg

In this example we have introduce a Unit Delay block. This changes the execution order
Output = LP * Egg
LP = Input * Chicken

In this case the “Egg” calculation takes place first since we have existing information from the unit delay allowing calculation of the output value.

In our next example the execution order is arbitrary; since there is no data dependencies between “Chicken” and “Egg” output 1 or output 2 could be calculated first. (Note: Simulink provides a “Sorted Execution order”; these are the red numbers you see in the image. The lower numbers are executed first.

In this case the “Egg” came first

Controlling execution order (avoiding egg on your face)

In the last example we showed that with independent data flows execution order is resolved by Simulink; however, there are instances where the execution order will matter (1). The “obvious” and very wrong solution is to add a data dependency to the path.

Noooo never ever do this…(2)

By adding a “Zero value gain” and sum block to the “Egg path” I have forced the “Chicken path” to be executed first (4). For reasons that should be obvious this is a bad idea. Anyone who looked at the model would think “Why are they doing that” and they would be correct in asking that question. The recommended approach is to make the execution order explicite using a Function driven approach

In this case the “Egg” is executing second; this is known from the “B” number in the block, “ChickenPath” is BO, while “EggPath” is B1; the lower number executes first. For more complex execution orders a Stateflow chart can be used to define the execution order

Yes, I went for “eggs came first because chickens are evolved” as the solution to this issue…

In this “tongue in beak” example we see that “eggs” only execute during the “WeHaveEggs” and the “Dinosaur” states. Once we hit the “WeHaveBoth” state (after many eons) the Chicken executes first. In my next post I will give examples of best practices for controlling execution order with Stateflow charts.


  1. Within the subsystem the execution order does not matter. However there are several cases where it can matter.
    1. Time limited execution: If the given function has a limited time for execution allocated and it is possible that all of the calculations may not be able to be performed in that time period. In that case you would want to control the execution order
    2. Consumption by parallel process: If the data from one (or more) of the paths is used by a parallel process and that process needs data “first” then you want to control the execution process.
    3. Determinism: For some analysis locking down execution order will simplify the execution task.
  2. I debated even showing this image, however I have seen many “cleaver”(3) engineers come up with this solution.
  3. Yeah, I realized I was autocorrected to “cleaver” as in something that cuts or chops . It was an error at first. Then I realized that I liked that more, they are not really “clever” rather they are just chopping apart a problem.
  4. This could be considered a form of “playing chicken”
I love Google image search…

Please consider subscribing for regular email updates

Newton’s Method

Newton’s method is one of the foundational concepts in numerical mathematics; it is a method for finding the minimum value of real-valued functions through a series of successive approximations.  While the approach has limitations (it can be “trapped” in local minimum, it can be slow, …) it is the gateway algorithm(1).

Newton in Action

Newton and Model-Based Design

Aside from the equations of motion, integration, theory of gravity (to start a long list) the children of Newton’s method are found in optimization problems. Optimization problems seek to find the minimize (or maximize) a value for a set of equations (or input data) based on the system input. Let’s consider an example of my Chevy Volt and optimizing energy use during my daily commute to work.

Apparently you to can have a “Newton’s apple tree”
  • Distance to work
  • Range of battery
    • Effect of starting battery temperature
    • Driving conditions (highway / surface streets)
    • Cabin climate control (heating / cooling)
  • Cost of
    • Charging the vehicle (at home / at work)
    • Gas (in the Volt the gas engine charges the battery)
  • Externalities
    • Carbon emissions from the different energy sources.

When I frame this equation I set the commute as a “From-work-to-home-from-home-to-work” route. This, and thank you MathWorks, because there are free charging stations at my office, therefore any charging there is “free” (2).

  • cost = C1 + C2 + C3
    • C1 = Cost_per_Kilowatt_Work * Charge + E1
      • C1 is at work co Cost_per_KW = 0 + E1 * Charge
    • C2 = Cost_per_Kilowatt_Home * Charge + E2
      • C2 = (0.12 + E2) * Charge
    • C3 = Cost_Per_Gallon * Gallons_Per_Kilowatt * Charge + E3
      • C3 = (3.50 * 30 + E3) * Charge

In this case the E1, E2 and E3 are the external costs for use of power. I don’t directly pay these costs(3) but from an ethical standpoint let us remember them.

Wrong type of charge

The total charge is a function of distance, driving conditions and environmental conditions (do I run the heat or AC).

  • Charge = F(Distance,DriveCond) + F(Cabin,Environment)

Skipping the analysis here to the conclusions. Since heating a car from the battery is very energy intensive, and since driving above 40 has a hit on fuel economy the “target” for short drives is to pre-heat the car (while at work) and to drive in a most sedate fashion. For medium drives the key is to use the engine heat the car and battery up at the start of the drive…

The “costs” of our decisions:

In the equations above there are “E” terms assigned to each of the costs, the “externalities” in economic terms. These “E” terms can be used to “weigh” the optimization function to push (or pull) the outcome towards a given solution. In some cases the value of the weights can be calculated, other times they are assigned based on a desired outcome. For example, if I was creating an optimization equation for the “ultimate chocolate bar” I would have a heavy penalty against coconut; there is nothing inherently wrong about coconut I just can’t stand it.

Integrating content in this post (4)

This post was written due to N simple observations

  • Complex problems can be first understood using “base” methods: Real world optimization routines rarely used a Newton’s method due to efficiency issues, however for understanding optimization the simplicity of a Newton’s method can’t be beat.
  • Concepts are Queen / King: The concept behind the Newton’s method, that successive approximations can lead to a numerical solution underpins multiple fields, optimization, feedback loops for controls, noise reduction…
  • Reviewing “base” methods can lead to new understanding: In writing this post, and reviewing information on optimization and the basis of calculus (5) I have figured out solutions to a few problems that are plaguing me now, that of course will be in a future post
I wish it was still called the “science of fluxions”


  1. The gateway numerical method: Next thing you know you will be diving into implicit and explicate solutions to P.D.E.s
  2. There is still an external cost for charging at work, that energy is produce somewhere so some amount of greenhouse gas is being produced. This sort of “local” or self optimization can be seen as a leading cause of global climate change.
  3. This isn’t completely true, since I breath I do pay a direct cost to my health due to air pollution.
  4. What post featuring Newton would be complete without integration
  5. Calculus: from Latin, literally ‘small pebble’, with enough “small pebbles” you can “rock” the mathematical world.

If you find value in these posts, consider subscribing

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.

  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.
Image result for legos
A large scale Lego build (2)

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.
The 16999 Swiss Army Knife (3)


  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

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.

50% sample rate…

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 blue line is the continuous integral

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

Green: 100%, yellow 80%, blue 50%, red 20%

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.

Integration by Parts
In the end numerical integration means we never have to remember these formulas…

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?

Image result for steps

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.

Image result for muffins

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.

Image result for validation coffee
Note: You can be a coffee person and a validation engineer.

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.
Image result for Wrap

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 upI

Image result for all wound up

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

Image result for 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
PDecreaseIncrease Small
IDecreaseIncreaseIncreaseEliminate Degrade
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.

Image result for stop sign with snow
You know it says “Stop” but does your algorithm?

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.
What happens

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?

Image result for wind blowing
All we are is…

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
Image result for aesop's fables

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.

Image result for three Ts

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.

Image result for Talent

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.

Image result for when all you have is a hammer

Understand what customer needs…

Image result for microscope telescope

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.

Image result for AI 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?

Image result for multiple angles
Trig and Geometry!

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.

Image result for sensor fusion

If you find this content useful, please consider subscribing