Reinvent the wheel, not the road…

For every cliché there a grain of truth and a seed of doubt.(1) First, why is this advice given and knowing that, when can you go against it? Now, let’s talk about what in this example is “the road.”

Where the rubber meets the road

When I am developing a product, I am developing that product. Any work done on tools and infrastructure beyond it takes away from my core objective. Following this analogy, the “road” is a common infrastructure developed and maintained by many; meaning that it will be a fit environment for running our tires along. We can focus on making the best tire, not worrying about potholes.

When the road doesn’t go where you need…

In 98%(2) of software development practices, the existing infrastructure will take you all the way to your goal.(3) The primary objective here should be to triage the tool chain. Ask what functionality…

  • … is sufficient: for these portions to use-as-is
  • … is near: see if existing work arounds and extensions exist
  • … is missing: determine if the functionality is truly needed and if so implement extensions to the existing tools

Popping wheelies

Joy and job satisfaction comes from those times when for good and just reasons you do re-invent the wheel. Today I’m here to say, let us do it one wheel at a time until the world turns around new.

Footnotes

  1. You could say that in doubting this you are going against the grain.
  2. In the 2% case, you should milk it for all it is worth.
  3. Mind you, I look at this photo and think “If I were the road runner I would paint something on here and run right through.”

Divide and Solve

Sometimes when you are trying to solve a problem the model is just too big to figure out where the problem lies. You may know the subsystem where it occurs, but the problem is, how do you test that subsystem apart from the whole?

Test harnesses!

Starting around 2015, Simulink provided a methodology for doing this (e.g., creating test harnesses from an atomic unit within the full model).

  1. Set up the inputs and outputs to the subsystem under “test” for logging.
  2. Simulate the full model through one of the scenarios that causes the issue.
  3. Use the logged data as inputs to the test harness.

Dig deeper!

The logged data provides the baseline for your exploration; e.g., it provides a basic valid set of inputs. The objective now is to vary those inputs to determine the root cause of your error, and once that is accomplished to validate your solution. (Note: This image shows that getting to the root is to keep the “tree” alive)

Save the test

A pass/fail criteria should be defined for the test harness. While the test harness may have been created as part of a debugging exercise, it should be saved as part of the regression testing suite.

Reuse is a State(flow) of mind…

I’ve written multiple posts on when and why you should reuse software components. Today I want to look at the specific use case of reusable Stateflow Atomic States.

Simple example

The most common example of reusable states I have worked with involves fault detection and management. In this simple example we start off with “NineOclock” and “all = well.” Based on an input “errorCon” we can move to “all = soSo” and finally, if we don’t recover, “all = endsWell.” In this example the transition conditions are inputs to the system (e.g., we are calculating the value of “errorCon” and “recCon” outside of the system. This works for simple examples, but what if the condition logic is more complex? What should we do then?

Parametrized Transitions!

The answer is the use of parameterized function calls. In this example the function “errorCheck” takes 3 arguments, inst, arg1, and arg2. The argument “inst” controls which branch of the switch/case function is used to calculate the transition logic. (Note: you do not need to use all of the input arguments for any given case, however they all must be passed in).

Reuse is still reuse…

Reuse with Stateflow charts has the same limitation of any other reusable function; e.g., the data types for the inputs / parameters need to be consistent across each instance of the chart. Additionally if you want to use the function based method for transition, the MATLAB functions need to be set as globally visible.

Finally, while global data can be used between instances of the chart, since it can be written to in multiple locations, care should be taken that the information is not overwritten. The most common solution to this issue is to use “bitand” functions to turn on or off bits.

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