For the 1/4 of my readership in Germany, I am going to try something new; a video blog in German. For my non-German readers I provide the original transcript. Upcoming posts will dive into the system engineering concepts.
Cooking Thermodynamics
This year for Christmas, knowing my love of comparative cooking methods, my wife Deborah got me an Air Fryer; the results have been delicious.(1) This got me thinking about the thermodynamics of cooking(2) and what it would take to model both an air fryer and a past present (the instant pot).(3)
Physical (modeling)
Cooking is a heat transfer problem; move the energy from the cooking device into the food.
- Pan cooking: conduction
- Oven cooking: conduction and radiation
- Air frier: conduction, radiation and convection
- Instant pot: conduction
However there are limitations. The maximum temperature of an oven is limited to the energy of the heating method (gas or electric), boiling liquids are “capped” at the boiling point of water; this then is the “trick” to both the air fryer and the instant pot. The air fryer combines 3 methods for transferring heat, while the instant pot increases the pressure in the “pot” which raises the boiling point of water.(4)
Three simple rules
Cooking with an air fryer has three simple rules:
- Pre-heat: Heats the basket, giving conduction cooking
- Space out: Aids in convection
- Shake: Gives all sides a shot of conduction
From this we can determine that when you cook there is browning in the contact in the pan, that the air blows around the food from all sides (and the bottom) and that to get brown all sides of your food need to touch the bottom. So what would the physical model look like and how do we optimize the results?(5)
| Parameter | Effect | Trade off |
| Pan thermal mass | Browning effect | Longer warm up time |
| Grate arrangement of pan | Airflow (convection) between food | Reduces thermal mass |
| Blower speed | Increase convection | Energy usage |
| Food packing | Impact convection | Volume of food to be cooked at one time |
| Temperature | Rate of food temperature increase | Energy usage |
Equation time!(6,7)
For now let’s assume a Platonic solid French Fry, e.g. cube 1 cm x 1cm x 1cm.(8) In this case the equations for the heat transfer could be written as…
- Conduction: Q/Δt = -k * A * ΔT/Δx (9)
- Convection: Q/Δt = A h(Tp – Tpf)(10,11)
- Radiation: By evaluation O(10-3): dropped
By further inspection we can see that Q is the energy from the heating unit. If we assume that the thermal mass can be treated as an infinite sink (and if we have Platonic Fries we can allow this) then we can reorder the equations as so…
Tpf = Q/(Δt) * ((1/k*A1) + (1/h*A2)) + Tp
Extensive field work is now ongoing to determine by experiment the values of k,h, A1 and A2 for Platonic fries (and other foods). The formula for “browning” is also under development, but as I hope this article has shown you, it is possible to determine through analysis and simulation.
Footnotes
- The biggest surprise is how good the “air fried” carrots are; they are a reliable “go-to” afternoon snack.
- The control algorithm for this device is very simple, a boolean for the fan on or off, and a predictive element for the temperature.
- I find it most interesting to alternate between new kitchen gadgets and experimenting with just a pan, bowl and knife.
- I just had a thought; when you flambe food or cook with alcohol in general it boils off due to the lower boiling point than water; what would happen in the instant pot?
- In this case optimizing the results means crispy exteriors and internal temperature cooked to “done.”
- “Equation time” sounds like a kid show that I would like to see produced.
- Despite the image we will not be covering solar roasters today.
- When I picture this it sounds more like Platonic Hash Browns
- The thermal conductivity of a potato should be similar to that of water due to the high water content of the potato.
- Tp is the pan’s temperature and Tpf is Platonic fry’s temperature.
- The “A” term in this equation is affected by the crowding of the pan; the more crowded the food the lower the A.
Testing Requirements Part 4: Let’s talk about tests!
In today’s video we cover the concepts underlying how I talk about tests.
Testing Requirements: Part 3
In part 3 of this series, we look at how and why we create test harnesses.
Post credit thoughts
MathWorks provides stellar documentation on the creation of test harnesses; the key thoughts should be on why we create them (to avoid modifying the UUT) and how we call them (from test runners!)
Types: Not just for fonts…
Typographically inclined people can debate for hours the importance of font selection in the presentation of a message; a proper font(1) sets the right type of message.(2) With programs, data type is used to specify range and resolution of the data as well as determining the total memory and speed of your program.
I is for integer, at least in FORTRAN
In modern programing languages there are three primary data formats; integer, fixed point(3) and floating point. The range of integer data types is determined by the size of the data, e.g. 8, 16, 32 or 64 bit data types and the signed / unsigned nature.(4)
Floating point data represents information as a combination of a sign bit, an exponent component and a fractional component. This gives floating point data a greater range and resolution; however this can lead to issues when performing operations on data of significantly different orders of magnitude. For an overview of floating point data I would recommend this Wikipedia entry.(5)
What is the “point”?
Memory usage is easy to understand,(6) using all 32 bit integers in your program will use twice the memory of 16 bit integers; the same idea applies to floating point data types. The trade-off then comes with accuracy and speed. Integer based arithmetic is computationally faster then floating point; likewise, 64 bit floating point takes longer then 32 bit. The objective should be to use the smallest data type that fully represents your data after completion of the operation.
Tips and tricks!
- Overflow, underflow and precision loss can be detected through the use of simulation or tools such as Polyspace
- Disable range checking and overflow options for generated code to create more efficient implementations
Footnotes
- Here in this blog I lack the control of what font you see in your browser or in your email; for all I know you are using Wingdings (🕈︎♓︎■︎♑︎♎︎♓︎■︎♑︎⬧︎).
- And of course typesetting is part of the act of printing, the precursor to publishing electronically.
- Fixed-point could be considered a special case of integer data type, we will look at it in a future blog post.
- E.g. an 8-bit unsigned integer would have a range of 0 to 2^8 (256), while a signed 16-bit integer would have a range of (2^15 – 1) to 2^15 (-32767 to 32768). In every case they have a resolution of 1.
- There is a conceptual overlap between fixed point data floating point operations work; this link provides a general overview of fixed-point data.
- There is a caveat here; all hardware has a “smallest data type.” If you specify a data type smaller then the smallest data type you do not see any memory savings.
Testing requirements: Part 2
In this final video we are going to tackle the “Must never” and “Must always” cases for requirements. To do so, the use of mathematical analysis is employed to determine if the conditions hold.
Afterword
In some instances “never” and “always” cases cannot be definitively proven; when this happens there are three alternatives. First, subdivide the model into a smaller unit under test and attempt to prove the condition at that level. Second, determine under what conditions the requirement cannot be proven and then implement guards against those conditions. Or finally, explicitly guard against the condition in your model.
Port in a storm
“It is not enough to know how; it’s the when that is key.” With all projects, at some point in the development cycle problems arise.(1) When they do, questions of refactoring or porting should land on your shores. Often simple bug fixes or in-language refactoring is enough to resolve the issue; however when the impact crosses a critical threshold the answer is to port.
Port:
noun: a town or city with a harbor where ships load or unload.
verb: to transfer between two locations or environments
When it’s not right: port(2)
Porting software can be a major endeavor. Prior to this action a 5 part assessment should be made:
- Will this software module be in use for the long term(3) (e.g., will it exist in code deployed in the field; what is the life span of that product?)
- What is the criticality of the error? Is it: life threatening, product unusable, product behavior degraded, or is it a minor usability issue?
- What are the other issues facing the product and their criticality?
- If fixed now in-language will a later porting be required?
- What is your deadline?
Assuming that the metrics for 1 ~ 4 are high enough, and assuming that there is enough time before your deadline, it is time to port.
Estimating port fees
How do you estimate the time it will take to port your module, e.g. what is your “port fee?”(4) Ask yourself the following questions:
- How long did it take the first time around; of that time how much was spent on determining what to do versus implementation?
- Is the new language better suited for the implementation?
- Is there existing testing infrastructure and can it be repurposed for the new environment?
- Is the module unique or similar to existing code in the new environment; e.g. how well do you know your new environment?
The last question, how well do you know your environment is key. If you are just starting out in a new environment, the recommendation is to learn on non-critical applications. Learning an environment should never be a high stakes game.
Footnotes
- Problems can
- arise: e.g. float up from the buried issues in a poor design
- fall: e.g. come from outside sources as new information or requirements are given
- saunter in from the side: e.g. issues of integration with teammates
All in all, problems are three dimensional in nature
- Assuming you are moving forward, port is left.
- Stones from pyramids and other monuments have over time found their way into other construction. It is possible that stones from the pictured are part of someone’s house. When determining if a software module will be in use “for the long haul” it is not enough to look at the full systems but all the stones that make it up.
- While free trade ports are a hot topic in economics, they do not exist in software.
Testing Requirements Part 1
This is part 4 in my video series on Model-Based Design testing. Today I look at how to test requirements of the form “When X happens the response is Y.” Follow these steps and then you too can enjoy testing.
Post movie credits…
In the video I state there are two basic types of requirements, when X happens Y occurs and X never occurs. In the final video in this series we are going to look at how we can prove the “never occurs” case.
Hindsight is 20/20: Looking back and forward
Most years the “year in review post” seems like a good time for a lighthearted review of what has been and what is to come; with the events of this year some amount of gravity seems in order.
A safety critical life
With one of my my earliest mentee I described the job of an engineer as “trying to find the minimum in Murphy’s equation and its first derivative.”; that is to say, design for the best outcomes and protect against the worst. The blog posts this year have focused heavily on Verification and Validation methodologies (finding the minimum) and writing requirements (protecting against the worst). It is easy to see the parallels between these tasks for Model-Based Design and for life during Covid times.
The pendulum swings
With the introduction of COVID-19 vaccines there is an understandable desire to “go back to normal”; in fact some studies suggest that post events we will swing in the opposite direction; depending on how you look at it, this could be seen as embracing life or throwing caution to the wind. They key as I see it is to embrace life while remembering the lessons learned as the pendulum will swing back.
Looking forward 2021
If hindsight is 20/20, and yes I have been waiting all year to make that joke, as a ratio (20/21; 20/22;…20/99) our view into the future is less clear. In 2021 this blog will be moving to a bi-weekly update (Tuesday / Thursday) and I will be writing more “multi-part” posts to go into greater depth on topics of interest.
I want to wish everyone a safe and happy 2021; I look forward to your comments in the coming year.
Michael
Engineering Process: Fault Lines (P3)
Welcome to the home stretch! In today’s post we finish up the engineering process for the fault insertion. We left the last post with three outstanding questions; in todays post, I will walk through the design decisions that I made in implementing this solution.
- How much of the tool should be automated?
- What is the end user responsible for implementing?
- How do we make this scalable?
Automation and scalability
The weak point in this solution revolves around the naming and maintaining the fault injection names; e.g., as the end user adds new “faults” into the system there is a need to create and define the global data, ensure that it is unique, and add it into the test harness.
Check and define
The first two tasks are accomplished using a masked subsystem and a setup script; when the user double clicks on the fault subsystem they are prompted for a fault name. Closing the dialog will then launch a script that checks and defines the fault data.
The first step is to check to see if the variable already exists; this is done by evaluating the base workspace to see if the data is already defined. If it is a warning, dialog is generated.
If the data does not exist, we assign the names of our fault data to the data store read and data store writes inside the library subsystem.
Finally, we assign the data to the base workspace. As part of this task we inspect the incoming signals to determine the data type and dimension.
But wait!
This code takes care of what happens when you add a block. However, in the long term you are just opening up your model with the data already in place. The next step is to provide a method for saving off the data and adding it to the test harness. In the design stage I tried out methods for auto-triggering this save and add step; however all of them had potential data conflicts. In the end the solution was to provide a script that the user could run to generate the data for themselves.
What remains?
At this point with this code, our end users have the basic functionality that is required. Additionally, because of how we implemented it, the fault blocks can be inserted anywhere in the model, not just between referenced models which was one of our “stretch goals.” What remains now is the “error checking” or ruggedization tasks required to have a product out in the field standing on it’s own. That, however, will be a future set of posts.