Model-Based Design: Part 8: Penultimate + 1 (My MBD Philosophy)

This post is the last (number 8) in a series of 8 video blogs, walking through the fundamentals of Model-Based Design. When taken as a whole, these videos provide the foundation stones for understanding and implementing Model-Based Design workflows I will be using a simple Home A/C system for my example; however the principals apply to everything from Acting cue generation to Zip-Zap-Zop entertainment.

  1. Requirements
    1. Requirements Management
    2. Writing clear requirements
    3. What I’m expecting: writing requirements
  2. System Architecture
    1. Modeling architecture: Fundamentals
    2. Model architecture decomposition for hardware and close loop testing
    3. Is your system architecture “Lego Legal”?
  3. Initial (shell) models
    1. Modeling architecture with room to grow
    2. The Model-Based Design Workflow…
    3. Defining your initial Model-Based Design workflow
    4. Plants resting on a table
  4. Defining and managing data
    1. Managing Data
    2. Understanding Data Usage in Model-Based Design Part I
      and
    3. Understanding Data Usage in Model-Based Design Part II
    4. The Simulink Data Dictionary
  5. V&V
    1. The 8 commandments of V&V
    2. Levels of testing
    3. Modular testing environments
  6. Refining the models
    1. Defining your initial Model-Based Design workflow
    2. Best Practices for Establishing a Model-Based Design Culture
  7. Code generation
    1. https://www.mathworks.com/solutions/embedded-code-generation.html
  8. The grab bag…
    1. A road map for Model-Based Design
    2. The next generation of Model-Based Design

Buzz-Buzz: when you are the feedback loop

A number of years ago my wife and I had a chance to try out a friends augmented reality, virtual reality (AR/VR) system. Deborah proved to be graceful in the artificial world(1). On the other hand, I had a dramatic fall when “running” down a virtual mountain(2). In hindsight this is an example of a problem arising from open loop system.

Closing the virtual loop

Feedback is not enough, the feedback needs to be synced to the environment. This means that models of the person and the physical world are accurate to a degree that it fools our highly tuned sensor. As a starting point, \games have given us accurate physics models of the real world (3), however they fall short as they do not close the loop on the person in question.

A bespoke AR/VR suite

How do we seriously Taylor(4) the AR/VR to the individual? This is where an adaptive Deep Learning system can come into play. Giving the persons “overshoot” as inputs the system can learn to provide the correct feedback for any situation, “increasing” the force needed to lift an object, or by making the ground come up at a proper rate.

Avoiding “God Mode”

Video games often have a concept of “God Mode”. In this mode the player has unlimited powers, can’t be hurt, can run 1,000 km/hour. This is why an observer is needed for the Deep Learning system, to prevent feedbacks going in the wrong direction. Here is where traditional “bounded” values can be observed for any and all objects in the virtual world; e.g. the “force” to lift a 1kg object will always fall between X and Y, with the final value tuned for each user.

Learn the guitar!

As a child learning to play guitar my instructor tapped her finger on my shoulder to help me learn the rhythm of the song, saying the name of the note to play as it came down the staff. As I got better she tapped less and said less. I can now imagine a AR/VR/DL/CL(5) system that

  • Watches my eyes see the notes
  • Gives light pressure to the fingers to guide towards the string
  • Learns when to step back…

Helping me relearn the guitar (or any other physical skill) much more quickly…

Footnotes

  1. As she is in the real world.
  2. The world was real enough that I “knew” I needed to jump and that, since I was going down hill I would have 1/10 of a second more before I landed.
  3. Accuracy going up if the model is of something being shot or blown up; the “seeing water flowing past you as you tube down a river” simulations are a bit further behind.
  4. You can curve fit the first parts (e.g. a Taylor series) but the fine tuning requires…
  5. Going for the longest set of abbreviations I could, Augmented Reality, Virtual Realty, Deep Learning Closed Loop system.

Model-Based Design Walkthrough: Part 7: Code Generation

This post is number 7 in a series of 8 video blogs, walking through the fundamentals of Model-Based Design. When taken as a whole these videos provide the foundation stones for understanding and implementing Model-Based Design workflows I will be using a simple Home A/C system for my example; however the principals apply to everything from animal control to animal containment (e.g. Zoos).(1)

When I first started working in the area of Model-Based Design the topic of code generation dominated the work e.g., the need for custom TLC(2) and storage class to configure the generated code to match your requirements. However, in the last 10 years with few exceptions, the tools have evolved such that the required interfaces can be generated using standard built-in functions. This means that engineers can spend more time focusing on their project and less on the tool.

  1. Requirements
    1. Requirements Management
    2. Writing clear requirements
    3. What I’m expecting: writing requirements
  2. System Architecture
    1. Modeling architecture: Fundamentals
    2. Model architecture decomposition for hardware and close loop testing
    3. Is your system architecture “Lego Legal”?
  3. Initial (shell) models
    1. Modeling architecture with room to grow
    2. The Model-Based Design Workflow…
    3. Defining your initial Model-Based Design workflow
    4. Plants resting on a table
  4. Defining and managing data
    1. Managing Data
    2. Understanding Data Usage in Model-Based Design Part I
      and
    3. Understanding Data Usage in Model-Based Design Part II
    4. The Simulink Data Dictionary
  5. V&V
    1. The 8 commandments of V&V
    2. Levels of testing
    3. Modular testing environments
  6. Refining the models
    1. Defining your initial Model-Based Design workflow
    2. Best Practices for Establishing a Model-Based Design Culture
  7. Code generation
    1. https://www.mathworks.com/solutions/embedded-code-generation.html
  8. The grab bag…
    1. A road map for Model-Based Design
    2. The next generation of Model-Based Design

Footnotes

  1. Zoos, and their role in animal management have evolved considerably over the years; perhaps my favorite “zoo-like” place is the Duke Lemur Center, a place my wife Deborah surprised me with for my birthday one year, it was so much fun!
  2. TLC (Target Language Compiler) is a programing language used by MathWorks to customize the generated code. Over the years when I have been asked what TLC stands for my default answer has been “Truly Lovely Code” as that was the desired outcome.

Model-Based Design Walkthrough: Part 6: Refining the model

This post is number 6 in a series of 8 video blogs, walking through the fundamentals of Model-Based Design. When taken as a whole, these videos provide the foundation stones for understanding and implementing Model-Based Design workflows I will be using a simple Home A/C system for my example; however the principals apply to everything from chase Avoidance controllers featuring to Zig and Zag dodging. (1)

Having a clear refining and elaboration process is key to an organized development process. The “test-as-you-go” methodology (also known as test-driven development) that I describe here provides a natural framework for ensuring that the system is in alignment with requirements throughout the development process.

  1. Requirements
    1. Requirements Management
    2. Writing clear requirements
    3. What I’m expecting: writing requirements
  2. System Architecture
    1. Modeling architecture: Fundamentals
    2. Model architecture decomposition for hardware and close loop testing
    3. Is your system architecture “Lego Legal”?
  3. Initial (shell) models
    1. Modeling architecture with room to grow
    2. The Model-Based Design Workflow…
    3. Defining your initial Model-Based Design workflow
    4. Plants resting on a table
  4. Defining and managing data
    1. Managing Data
    2. Understanding Data Usage in Model-Based Design Part I
      and
    3. Understanding Data Usage in Model-Based Design Part II
    4. The Simulink Data Dictionary
  5. V&V
    1. The 8 commandments of V&V
    2. Levels of testing
    3. Modular testing environments
  6. Refining the models
    1. Defining your initial Model-Based Design workflow
    2. Best Practices for Establishing a Model-Based Design Culture
  7. Code generation
    1. https://www.mathworks.com/solutions/embedded-code-generation.html
  8. The grab bag…
    1. A road map for Model-Based Design
    2. The next generation of Model-Based Design

Footnotes

  1. Zig/Zag dodging being the preferred method for not getting tagged in the game of “tag.”

Disco beat or syncopated rhythm: Finding the Review Cycle

Weekly standing meetings are the “disco beat” (1) of review cycles. For projects that march forward at a well defined interval (2) regular meetings are the correct way to go. But what about for the more common project with irregular updates?

The ideas behind Agile Development (3) seem like the perfect counterpoint to the “set” review cycle, a syncopated rhythm. The short daily stand ups and sprint wrap ups seem like the way to review when you need to review. However, in practice, people come to the stand up meetings less prepared than they should be for a formal review.

Event triggered reviews

One approach is to move to “event triggered” reviews. The event is tied to one of 3 things

  1. Completion of one or more requirements: This is a logical review point as the completion of requirements should be verified as part of the validation process.
  2. Update to requirements: When requirements change, a review of the model should be performed to determine the impact of the change. If they exist at this point in time, the associated test cases should be updated.
  3. External trigger: This is generally when a “real world” bug is discovered; you are reviewing because there is a need for a major change

Model size: absolute and % change

A change in the model size alone is not a valid trigger for a model review, if I have added in 1,000 new blocks but the functionality is the same, there is nothing new to review. At the same time, developers should use the change in model size as a caution. If you have added in 100 blocks and the functionality has not changed then most likely you are working in an unfocused fashion.(4)

Testing…

When tests fail, and if the developer cannot get to the root cause, it is a clear sign that a design review is in order. For these reviews the full test failure diagnostic logs should be part of the review, both pre-and post failures. If possible, the deltas in the model and model data should be presented as well.

Informal reviews

As a final note, not all reviews need or should be formal. Informal reviews are helpful for those “I’m just stuck here” moments in the development process that everyone faces. More often than not, the simple process of talking through what you are doing will help you resolve the issue.

Footnotes

  1. The “four to the floor” disco rhythm is easy to dance to but lacks the complexity of other drumming styles.
  2. There are projects with this sort of well defined interval; they tend to be instances of the same work being repeated.
  3. There are few animals more agile then a ring-tailed lemur.
  4. The exception would be in the case of a model architecture reorganization. In general this should reduce the number of blocks but there are instances where the model size could grow.

Model-Based Design Walk Through: Part 5: V&V

This post is the fifth in a series of 8 video blogs, walking through the fundamentals of Model-Based Design. When taken as a whole, these videos, provides the foundation stones for understanding and implementing Model-Based Design workflows. I will be using a simple Home A/C system for my example; however the principals apply to everything from Alpine ski sharpeners to Zamboni de-icing.(1)

Today we will look at three V&V activities: guideline compliance, coverage and requirements based tests.

  1. Requirements
    1. Requirements Management
    2. Writing clear requirements
    3. What I’m expecting: writing requirements
  2. System Architecture
    1. Modeling architecture: Fundamentals
    2. Model architecture decomposition for hardware and close loop testing
    3. Is your system architecture “Lego Legal”?
  3. Initial (shell) models
    1. Modeling architecture with room to grow
    2. The Model-Based Design Workflow…
    3. Defining your initial Model-Based Design workflow
    4. Plants resting on a table
  4. Defining and managing data
    1. Managing Data
    2. Understanding Data Usage in Model-Based Design Part I
      and
    3. Understanding Data Usage in Model-Based Design Part II
    4. The Simulink Data Dictionary
  5. V&V
    1. The 8 commandments of V&V
    2. Levels of testing
    3. Modular testing environments
  6. Refining the models
    1. Defining your initial Model-Based Design workflow
    2. Best Practices for Establishing a Model-Based Design Culture
  7. Code generation
    1. https://www.mathworks.com/solutions/embedded-code-generation.html
  8. The grab bag…
    1. A road map for Model-Based Design
    2. The next generation of Model-Based Design

Footnotes

  1. Qui transfert terminos glacies et gelu de auferentes?
  2. Additional links for how to use…
    1. Simulink Design Verifier
      1. From MathWorks
      2. From this blog
    2. Simulink Test
      1. From MathWorks
      2. From this blog

Model-Based Design Walk through: Part 4: Data

This post is the fourth in a series of 8 video blogs, walking through the fundamentals of Model-Based Design. When taken as a whole, these videos provide the foundation stones for understanding and implementing Model-Based Design workflows. I will be using a simple Home A/C system for my example; however the principals apply to everything from Active suspensions to Zonal control.(1)

With this post I cover the basics of data management, both for the model and configuration settings.

  1. Requirements
    1. Requirements Management
    2. Writing clear requirements
    3. What I’m expecting: writing requirements
  2. System Architecture
    1. Modeling architecture: Fundamentals
    2. Model architecture decomposition for hardware and close loop testing
    3. Is your system architecture “Lego Legal”?
  3. Initial (shell) models
    1. Modeling architecture with room to grow
    2. The Model-Based Design Workflow…
    3. Defining your initial Model-Based Design workflow
    4. Plants resting on a table
  4. Defining and managing data
    1. Managing Data
    2. Understanding Data Usage in Model-Based Design Part I
      and
    3. Understanding Data Usage in Model-Based Design Part II
    4. The Simulink Data Dictionary
  5. V&V
    1. The 8 commandments of V&V
    2. Levels of testing
    3. Modular testing environments
  6. Refining the models
    1. Defining your initial Model-Based Design workflow
    2. Best Practices for Establishing a Model-Based Design Culture
  7. Code generation
    1. https://www.mathworks.com/solutions/embedded-code-generation.html
  8. The grab bag…
    1. A road map for Model-Based Design
    2. The next generation of Model-Based Design

Footnote

  1. Stay in the zone, even when you zone out!
  2. Take it with a grain of salt but how you pronounce the word “Data” may be dependent on ST-NG

A few thoughts on the measurement of coffee?

I like a good cup of coffee, while my wife Deborah is partial to tea and we both enjoy sharing a cup of hot cocoa on cold winter nights. (1) Recently we needed to buy a new kettle for our hot brews, so we purchased one that had a thermometer built in. This enabled brewing at the proper temperature, but we couldn’t tell what difference it was really making.

In the field, or in the model?

For experimental data it is common to “over log”; that is, to log as many data channels as your system can handle. This ensures if there is an unexpected event(2) you have the best chance of capturing and understanding the event. By contrast in simulation, the environment(3) is controlled and repeatable so unknowns are of low probability.(4) This means that “over logging” just slows down the simulation time.

How to determine what to log?

In the ideal world you are able to understand the system based off of first principles physics.(5) However, it is often the case that the system as a whole has too many interconnected models that writing out the full system of equations cannot be realistically performed. In that case how do you determine what to log?

The approach I recommend in this case is “self and nearest neighbors”. In other words if you cannot determine the full set of equations that define your whole system, break down the system into components (perhaps at the model reference or lower level) and determine what are the inputs and outputs of those systems. Take the inputs of your Unit Under Test (UUT) and the units directly connected to the UUT and use that to determine what to measure.

Back to coffee

I’ve started experimenting with coffee (okay, not as rigorously as in the milk first/tea first tea experiments), to determine the factors providing the optimal cup? There are 4 primary factors in the outcome of the cup of coffee.

  • Water temperature, Rate of extraction, coffee dose to water amount, coffee quality

The question then is, what is the relative weight to assign to each variable

GoodCup = β(1)* WaterTemp + β(2) * dr/de + β(3) * CoffeeD + β(4) * CoffeeQ

Through a few simple experiments I learned my personal weights heavily lean towards β(3) and β(4) e.g. the temperature effect was minimal. (6) In the same way when designing models, think twice before measuring once. (7)

Footnotes

  1. Perhaps one day we will buy this chocolate teapot for our hot cocoa
  2. The “unexpected” is what you most want to capture; expected data can often be calculated, it is when the dice role snake eyes that you learn the most.
  3. As an interesting side note, I often make 2 “plant” models. One that models the real world (the environment) and one that models the device I am controlling (e.g. the road and the car, air and an airplane, human veins and the I.V. system).
  4. Unlike the real world where unknowns are random events, the unknowns in simulation arise from modeling errors, and when that occurs, adding in additional logging is important.
  5. I was amused that the image of the book cover read “Note: this is not the actual book cover”! The use of a classical cover for fundamental physics seemed spot-on.
  6. There is a side benefit to brewing at the correct temperature, fewer cases of “wow that’s hot” on the first sip of coffee
  7. Unless you are cutting wood in which case it is design once; check your design and measure twice, cut once.

Model-Based Design Walk through: Part 3: Initial models

This post is the third in a series of 8 video blogs walking through the fundamentals of Model-Based Design. When taken as a whole, these videos provide the foundation stones for understanding and implementing Model-Based Design workflows. I will be using a simple Home A/C system for my example; however the principles apply to everything from Air filters to Zoetrope spin rate regulators.(1)

  1. Requirements
    1. Requirements Management
    2. Writing clear requirements
    3. What I’m expecting: writing requirements
  2. System Architecture
    1. Modeling architecture: Fundamentals
    2. Model architecture decomposition for hardware and close loop testing
    3. Is your system architecture “Lego Legal”?
  3. Initial (shell) models
    1. Modeling architecture with room to grow
    2. The Model-Based Design Workflow…
    3. Defining your initial Model-Based Design workflow
    4. Plants resting on a table
  4. Defining and managing data
    1. Managing Data
    2. Understanding Data Usage in Model-Based Design Part I
      and
    3. Understanding Data Usage in Model-Based Design Part II
    4. The Simulink Data Dictionary
  5. V&V
    1. The 8 commandments of V&V
    2. Levels of testing
    3. Modular testing environments
  6. Refining the models
    1. Defining your initial Model-Based Design workflow
    2. Best Practices for Establishing a Model-Based Design Culture
  7. Code generation
    1. https://www.mathworks.com/solutions/embedded-code-generation.html
  8. The grab bag…
    1. A road map for Model-Based Design
    2. The next generation of Model-Based Design

Footnotes

  1. As a kid I made a number of flip books; I remember trying to use an old coffee can to make a
    Zoetrope, it was of our pet hamster using its drinking bottle. It was riveting…

Model-Based Design Walk through: Part 2: System Architecture

This post is the second in a series of 8 video blogs walking through the fundamentals of Model-Based Design. When taken as a whole, these videos provide the foundation stones for understanding and implementing Model-Based Design workflows. I will be using a simple Home A/C system for my example; however the principles apply to everything from Arch welders to zygodactyl pickup systems.(1)

In this example I am laying out the system level architecture; in future posts I will go into the types of analyses that can be performed in this environment.

  1. Requirements
    1. Requirements Management
    2. Writing clear requirements
    3. What I’m expecting: writing requirements
  2. System Architecture
    1. Modeling architecture: Fundamentals
    2. Model architecture decomposition for hardware and close loop testing
    3. Is your system architecture “Lego Legal”?
  3. Initial (shell) models (TBD)
  4. Defining and managing data (TBD)
  5. V&V (TBD)
  6. Refining the models (TBD)
  7. Code generation (TBD)
  8. Odds and ends…(TBD)

Footnotes

  1. Having started an A to Z theme I will see it through for the remaining 6 posts!
  2. With the air quality in California impacted by the current fires, the windows open requirement may need to be adjusted.