Month: September 2020

Stop Cursing at Recursion

Published on by Michael BurkeLeave a comment

A recursive function (1) is a function that calls itself until an exit condition is met (2) or until a bounded number of iterations has passed. (3) This is extremely useful when the problem involves a nested branch searching with an unknown number of branches.

Meanwhile(4) in Model-Based Design…

In general, safety standards(5) frown upon recursive functions due to their unbounded nature. Determining if recursion can be used in your algorithm is a 2 step process (with some recursion involved).

  1. Determine the memory use and execution time of the recursive function
  2. Determine the “worst case to solution” input data
    • Calculate time and memory usage
    • If this is acceptable for your system then exit
      Otherwise
    • Go back to step 2…

Note, in this example, worst case means that you are looking at how many interactions are required to reach an acceptable solution. Acceptable is not the same as fully converged; you want a solution that is close enough to correct for your controller’s requirement.

Credit SMBC Comics:

When?

Most traditional control problems do not require recursion to solve; however with the onset of adaptive controls and more importantly networked controllers, the need to exhaustively cover all branches in the solution come into play. Again, it comes down to 3 questions

  1. Is there a closed form solution: Can you mathematically solve the problem in either a known number of steps or directly?
    If “no” continue on
  2. Is there an unknown depth or branch issue: Is the final path known ahead of time?
    If “no” continue
  3. Do you need it now: In some cases you can perform recursion the slow way, e.g. the same function is called once per time step maintaining state information.
    If you “need it now” you need recursion!

Footnotes

  1. I had multiple typos (and misleading auto-corrections) when writing this
    • re-cursive: a note about handwriting
    • re-cur-son: a note about a dog’s puppy
    • …
  2. When you meet an exit condition do you say hello or goodbye? Perhaps Aloha, or Ciao, or Shalom, or Annyeong or Salām is the correct word to use.
  3. This is critical in an embedded system where consistent timing and memory limitations are critical.
  4. While loops are similar to recursion in that they execute until an exit condition is reached, they do not enable branching determination.
  5. By default in Simulink the recursive code generation is prohibited for this reason. It can be enabled as shown here; the rest of this blog is about when to consider using it.

Standing up for Model-Based Design: Agile Workflows

Published on by Michael Burke2 Comments

For the past 8 years I have been helping customers adopt agile workflows as part of their Model-Based Design process. As acceptance of agile processes grows I have seen a corresponding growth in MBD / Agile best practices. With 5 points, I will illustrate how Model-Based Design and Agile Development workflows fit together.

Continuous Integration: The opposable thumb

Model-Based Design and Continuous Integration (CI) go together hand in glove; the central nature of continuous testing to agile development processes is why I consider this the “thumb” of MBD / Agile workflows. And as for why Model-Based Design with Simulink is so powerful for CI systems? Built in access to simulation and therefore testing.

Rapid iterations / system integration: Pinky

One of the goals of Agile workflows is to allow engineers to work independently while being able to collaborate seamlessly. The key to this is the use of integration models or system architecture tools. The individual engineer works on their component while having an integration framework to validate against.

Why pinky: Because testing (thumb) and integration are the boundaries of Agile.

Making the most out of Stand Ups: Ring

Stand up meetings, or check-ins are intended to be quick reviews of outstanding issues. Having effective tools to aid in the review is critical. The graphical nature of Model-Based Design (and the ability to easily generate plots / graphs) means that the information required can easily be conveyed. (Note: bad stand up meetings can seem like they last for 24 hours. I would recommend this site for best practices)

Why ring: In stand ups we all stand around the table

Cross group collaboration: Middle

Working across groups is one of the higher order objectives of Agile workflows. Model-Based Design, with the use of architectural models, allows groups to not just design the control algorithms but the system level architecture, the physical requirements and hardware interfaces as well.

Why middle: Because this is the center of all the work.

One model, many uses: Reuse: Index

Chose the “right” one

In an ideal Agile workflow your work product is iterated throughout the design cycle. In a standard Model-Based Design workflow, you reuse the same model from the start to finish.

Why index: because the one concept indexes into the other.

Final thoughts / lack of footnotes

In writing a post about “the hand in glove,” footnotes didn’t seem right, so the final thoughts will have to do. Agile workflows, like the waterfall or test driven development (TDD) or one of many others are good practices to follow assuming that the work environment is following rational design processes. Know when to bend and when to hold fast to the process. For another view on Model-Based Design and Agile workflows I highly recommend this post.