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.