Month: August 2020

Going down the rabbit hole

Bring down the wall

How this keeps you whole

Reflecting back to the start

I am now waltzing into a short 1-2-3 posting on scheduling. Multi-rate systems exist for two reasons, either the calculations do not need to update frequently, or the calculations take too long to fit them all into one rate. In either case the “offset” is a valuable tool.

Lets take the hypothetical case of a 3 task system

• Task 1: Runs at 0.2 sec rate
• Task 2: Runs at 0.4 sec rate
• Task 3: Runs at 0.4 sec rate

The first way of arranging these would be (a very simple dance with a high probability of stepping on your partner’s toes).

If the total execution time of T₁, T₂ and T₃ is less than your base rate (0.1 seconds here) you are fine but if not, you have overruns. The next option is to introduce an offset (and in this version of the waltz, you have no chance of toe stepping).

In this case, each task is running at a different time and the order of execution is the same (1, then 2, then 3). Everything is good right?

What about incoming data?

When everything runs at the same time step, then everything is using data from the same time step, e.g. T₁, T₂ and T₃ are all using T(0), then T(0.2), then… input data. In the offset case for the first execution it looks like

• T₁ uses T(0) data
• T₂ uses T(0.1) data
• T₁ uses T(0.2) data
• T₃ uses T(0.3) data…

In many (if not most) cases, using the freshest data will not cause an issue. However if there are synchronization issues then using a “sample and hold” approach to the data may be required.

What is a testing interface and how is it different from a test?

• A test is: A formalized measurement and objective comparison to validate the behavior of a system
• A measurement is: A repeatable operation in which a quantifiable result is returned
• An objective comparison is: An operation in which a pass / fail result can be returned
• A test interface is: A generic method for calling a test(s)…

Good versus ok interfaces, USB-C and USB-B…

It is for the developer

• Consistency: you will have multiple test interfaces; keep the calling format consistent between them. For example if the unit under test is always an input argument, don’t have as the first argument in some and the last in others.
• Error handling: If there are common errors then the interface should check for and if possible, correct the errors.
• Fast: Introduction of an interface has some overhead; however, done properly there can be an overall reduction in execution time.
• Informative: The testing interface (and infrastructure behind it) can implement error handling and messaging that would represent a burden for an end user to implement.

Footnotes

1. USB-C data transfer rate is even greater then most people realize, e.g. the 15 seconds lost each time you try and connect a USB-B port is time you are not transferring data.

On August 23^rd, 2020, I woke up with a voice mail from Jack Little congratulating me on 15 years with The MathWorks. Honestly, it seems like yesterday that I started there. I thought today I would take some time to reflect on what I have learned in the last 15 years.

The Workflow Engineer

M.A.A.B. Starting off with Style

Making MathWorks MISRA-able

Product development

I did a brief stint of time in the MathWorks product development group, working on what is now called Simulink Check and the Requirements Traceability tool (Simulink Check still looks a lot like it did when I worked on it, though the requirements tool has greatly evolved). It was during this time that my connection to software verification deepened. Over time, I began to understand the difference between verifying software versus control algorithms; the root difference is in the constraint on control algorithms, no one ever passes a string into your velocity controller.

Onward: Consulting

The last 9 years have seen me in a consulting role, driven by a desire to directly help varied customers while expanding my own knowledge. During this time I branched out from my Automotive background to enter into Industrial Automation, Aerospace, and Medical Devices. About 5 years ago, the “itch to teach” also sprung back up and this blog was born.

Next 15 years?

If the past is any indicator, 15 years from now, I will be writing about the new, new best practices for Model-Based Design and helping to define what those boundaries are.

Last Thoughts

I hope you will forgive a more “personal” blog post. I will return to the normal content on Wednesday. For all of those of you who I have worked with and learned from over the years, thank you and I look forward to working with you again.

Michael

Somewhere between the famous Henry Ford quote of “Any customer can have a car painted any color that he wants so long as it is black” and near infinite clothing options of the video game world lies the reality of most finished⁽¹⁾ software projects; half a dozen main variants with three to four sub variants, some of which are mutually exclusive.

However, one common mistake in the software development process is a tendency to plan for all outcomes or in other words, have 101⁽²⁾ variants.

How do we get here?

Hold on to your requirements

This is where requirements traceability shines. If engineers as they work have a clear definition of what they need to be working on, and that definition is always present than the outcome is predictable.

What happens when you let go?

Adding additional variants adds costs in 3 ways

1. Additional testing required: Not only does the additional variant need testing in a stand alone mode, but it needs to be tested in an integrated system.
2. Adding complexity to interfaces: Unique variants often require unique interfaces. The more interfaces that are added the more likely that there will be integration issues
3. Speed!: Each additional variant adds in overhead for each step of the development process, from testing to code generation.

Footnotes

1. “Finished” with software can be a problematic concept; there can always be patches and updates. For the purpose of this article, finished refers to the first shipment of the product.
2. When I write “101” here I am not saying “0b101”.
3. Often “scope creep” occurs when there are poorly defined requirements, but it can also happen when the requirements are not well understood or enforced.
4. These questions are in decreasing order of possible variants, unless you work for NASA then it is something you should consider.

Regressions ~= Approximations

Simple illustrations

• What range do I need to cover: The larger the range of the regression the more terms are required to keep the error level down. Understand the range of your inputs when designing the regression.
• What resolution do I need: To hit 99.999% accuracy requires a more complex regression then requiring 98% accuracy.
• Are there spikes: Validate there are no spikes (i.e. large errors) in the range under consideration.
• Are errors cumulative: One trick to speed up regressions is to use last pass data, 99.999% of the time this does not introduce errors, but look out for the 0.001%.
• How expensive is my regression: Finally, make sure the regression you come up with is less computationally expensive than the equations you had.

Connecting the dots: the power of Physics

Requirements, ICD, and Models

What is “new” with Models

1. What are the model configuration settings
2. How do you store data (parameters)
3. What is your architectural approach
4. Modeling standards…

I have a secret

Auf Deutsch!

Ja, es ist die Zeit fur eine Deutsch sprachige Version des Blogs. Die Frage von Heute ist, “Wie arbeite Büro “A” mit Büro “B” und Model-Based Design?” Wie teilen Sie Modelle und schützen gleichzeitig das geistige Eigentum? Können Sie dies tun, ohne die Vorteile des MBD zu verlieren?

Anforderungen, ICD, and Modelle

Was ist “neu” an Modellen?

1. Was sind die Einstellungen der Modellkonfiguration
2. Wie speichern Sie Daten (Parameter)
3. Was ist Ihr architektonischer Ansatz?
4. Modellierung von Standards…

Ich habe ein Geheimnis

Footnotes

1. As I think about “translation,” for languages or code, I ponder what is lost in translation, through miss communication, transcription errors, and “missing content”. The value of the “Model-Centric” approach to development; without the chance for those errors, becomes clear.
2. More often than not, when requirement documents are handed off it is an iterative process with several back and forths before the requirements are finalized.
3. I highly recommend taking a look at the NASA site on model rockets, not only is it a very good primer on rocketry in general, it is also filled with a joy of understanding.
4. I remember playing “3 or more” in middle school, eventually we realized it was a solved game and had to invent our own rules.
5. The model should not be treated as the only requirement document, rather it acts as a supplement or derived requirements document. It is possible to use the model as the only requirement document, however in that case the requirements model is not what you use for the production.
6. It may be more accurate to say there is different information required; when exchanging Code you need to define coding standards, calling rates….

I understand where Actor 2 was coming from despite the day I lost to debugging their issue; to run the full test suite on their local machine (which would have exposed the issue) would have taken 2 hours during which they would not have been able to perform other tasks. At the same time the CI process, due to heavy loading, would have taken roughly the same amount of time. They took a common approach of verifying their component worked without examining its impact on the rest of the system; but for them as an individual, the productivity cost was too high. This could be seen as a case of unaccounted externality).

Identify your bottleneck: Moore’s Law is not enough(2)

Bottleneck #1

When I pointed out the speed difference, they thought they would see a 6% speed improvement in their test cases by making the change; in reality they saw close to an 11% speed improvement due to the way the same function was used in multiple locations. If you are using MATLAB for your development environment I would recommend using the profiler features to identify where you have unnecessarily (3) slow code.

Bottleneck #2

• Dependency analysis: In this instance tests are associated with a model and then the model’s dependencies are determined. If any of the files that the model depend on change then the associated tests are run.
• Meta data: In this case a test is considered to be of a given “tag/type”; tests of the given type are run as a batch. The tags can be related to a system (such as engine or battery) or a common task (like standards checking).

Bottleneck #3

The final bottleneck is unneeded or redundant tests. Sometimes this is when tests exist in the system for projects that are no longer active; sometimes it is when there are redundant tests. Regular pruning of the tests can take care of this issue.

Footnotes

1. One day as a self challenge, I am going to try to post Model-Based Design using a Patter Song format. “I write the intro Models for the modern MBDer”
2. Moore’s law should really be called Moore’s Observation.
3. Unnecessarily is an important word. Remember, if you have a choice between robust & correct versus fast, then choose robust & correct. Or better yet, find the cases where you can take the fast path and those you cannot and run the correct routine for the situation.
4. This should be considered a safety critical test; too hot and you burn yourself, too cold and well then, your shower isn’t good.

Plant models are the virtual reality of the Model-Based Design world, they allow you to take your controllers to worlds you could not otherwise reach.

My second semester in graduate school, fresh off of the introductory Computational Fluid Dynamics (CFD) course, the experimental methods Professor posed the following problem:

Assume you have a wall with 8 layers, each with a different insulating material, h_i.  At the start of the experiment, the temperatures at the boundaries are T_lower and T_upper.  Assuming the experiment runs for 1 hour, what are the final temperatures at each layer, assuming no additional heat input?

Most of the class members proceeded to implement a “simple” (1) CFD algorithm to solve this problem.  On the day of submission, the professor demonstrated his solution to the problem, a simple series of differential equations solved using a Laplace transformation, something we had all learned as undergraduates.

What he demonstrated simply and easily is that often basic methodologies provide simple and robust solutions to problems.

Bridging the old to the new

In a blog dedicated to Model-Based Design, a “new” technology, why would I take the time to write about “old” technologies?

1. Provide a map between old and new: When you are learning a new area, understanding how it maps onto previous domains speeds up the learning process.
2. Old and new are really the same: This primarily relates to design patterns and development workflows.  While the tools to do the work may change the task remains the same.
3. The new is an evolution of the old: In software development, this is frequently the case that the new solution is really an evolution of the old solution.  As a result,the approaches that you learned from the old can be used in the new.
4. Old methodologies provides insight into the fundamental nature of the problem:  It is common that after multiple iterations, fundamental issues inherent to the problem are understood and encoded in the solution
5. Sometimes old is better: There are times when reinventing the wheel should be done; but in other cases, well, you have a fine wheel.

Old methods, new domain: what has changed?

The primary change that we see in the migration between traditional and Model-Based Design processes is the degree to which processes can be automated natively in the design tool-chain. Lets look at the highlights

• Requirements: Like all software design processes everything starts with the requirements document. With Model-Based Design it is possible to fully automate the traceability and requirements checking into the development process.
• Development: One of the primary advantages of Model-Based Design is the ability to perform experiments (simulations) natively in the development environment. This greatly simplifies the design process as the developer can easily generate the stimulus / response information.
• Implementation: In the MBD environment the creation of the target software is from the development models through to the code generation process.
• Verification: Since the implementation is from the development model the verification process is simplified, the tests on the development model provide the baseline for the release tests
• Release: Here, the integrity checks that would have been manual can be offloaded to build in automation.

Footnotes

1. A “simple” CFD algorithm meaning about 2,000 lines of code not including calls to LINPACK(2)
2. Take a look at the 3rd contributor to LINPACK, e.g. Cleve Moler, the inventor of MATLAB. Little did I know at the time, the company I would be working for.
3. The phrase “Don’t reinvent the wheel” misses the fact that there are times when your existing wheel isn’t doing everything you need. When that is the case, it is time to reinvent it.