When you read about how to cook you will often read the phrase “when cutting, let the knife do the work.” There is, however, a single word missing that changes everything; it should read let the sharp knife do the work.” One word, big difference.
The right tool, set up correctly
During this pandemic I have finally learned how to sharpen knives(1) by hand for when I cook something yummy for my wife and I; let’s talk about how to “sharpen your models.”(2)
Model configuration: every model in Simulink has a set of parameters that defines how it executes and how code is generated.(3) Fortunately there is a simple utility that allows you to configure your model parameters for your target behavior.
You must specify basic behavior such as time domain, step size, and the target hardware. But once that is done, the balance of your configuration is handled through the specifications of your objectives.
Data settings: from your parameters to your signals, configuring your data creates more efficient and more controlled generated code. Consider setting the data type, storage class, and possibly units.
Block selection: mixing model domains such as discrete and continuous time blocks can result in sub-optimal performance. If multiple domains are required, partition the domains off using atomic boundaries
These are of course just a slice(4) of the type of configuration you should consider when setting up your model. Ideally there is a group that is responsible for the basic set up and maintenance of your working environment. This should extend to all of the tools in your development process. For more in depth information on these tools, take a look at the CI, and version control posts in this blog.
Please note, this is not a product endorsement, it is a process endorsement. Also, we don’t have the “stropping block” but I always thought it looks more fun to have the corded strop.
Note, this isn’t a perfect analogy as when you sharpen your configuration you are done for the project, unlike knives that need regular re-sharpening.
When we were first developing this tool I asked the question: How many configuration parameters does a Simulink model have, 113, 178, 238, 312? The correct answer was all of the above depending on the baseline configuration settings. As you can see, this tool is very useful.
Okay, I couldn’t resist one last knife reference for the post.
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
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.
You could say that in doubting this you are going against the grain.
In the 2% case, you should milk it for all it is worth.
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.”
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?
Starting around 2015, Simulink provided a methodology for doing this (e.g., creating test harnesses from an atomic unit within the full model).
Set up the inputs and outputs to the subsystem under “test” for logging.
Simulate the full model through one of the scenarios that causes the issue.
Use the logged data as inputs to the test harness.
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.
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?
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.
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.
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…
As she is in the real world.
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.
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.
You can curve fit the first parts (e.g. a Taylor series) but the fine tuning requires…
Going for the longest set of abbreviations I could, Augmented Reality, Virtual Realty, Deep Learning Closed Loop system.
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.
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!
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.
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.
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
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.
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.
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)
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.
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.
The “four to the floor” disco rhythm is easy to dance to but lacks the complexity of other drumming styles.
There are projects with this sort of well defined interval; they tend to be instances of the same work being repeated.
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 Zambonide-icing.(1)
Today we will look at three V&V activities: guideline compliance, coverage and requirements based tests.