Thanks, and regards.
Marcos.

@Walid F. - Thanks for the link! I like thy focus on abstraction from the implementation details (like targets!)

@Paul - Your comment gets to the heart of what I think is important, process, and improvement on the process. Success in Model-Based Design means adapting the process to allow engineers to focus on the engineering!

At a former job, I kept hearing that we must “design it right the first time” and we must reduce the number of prototypes. This was the path to increased profitability and productivity.

Of course as any engineer knows, especially those involved in Software Engineering, the development of complex and highly interactive systems requires many design iterations to get it right. I used to tell my old boss that rather than getting it right the first time what we needed was a safe environment where we could get it wrong a thousand times. We needed to do more design iterations and do them more rapidly. That is what engineers are good at! They keep grinding away on problems making incremental changes (or sometime wholesale reworks) until they get it right. What was it one of the Japanese car companies says - “the relentless pursuit of perfection” - pursuit being the key word here. There really is not finish line - we just keep pursuing.

Model-Based Design promises the engineer the ultimate playground to try every idea out rapidly, on their desktop or in a lab, safely, and thoroughly exploring their design space. Model-Based Design is the lubrication to “do it wrong” a thousand times so that, when real hardware and expensive prototypes are built, they just work. The tools that live in a Model-Based Design workflow are accelerants on the design process enabling rapid evolution to occur.

One final point: Just like the products being designed with Model-Based Design will never be perfect and the engineers will be in pursuit relentlessly, Model-Based Design itself is never finished. Layers of abstraction will continue to be added to the design process to allow engineers to do engineering instead of syntax checking or tool interfacing.

BTW, was math ever not cool?

@Jim - I like how you put it. What are the most important tasks to do in Model-Based Design? You gave a great example about creating and tracking requirements for the design.

@Guy Rouleau - X-In-The-Loop simulations move the results of our pure simulations closer to the real-world, either by testing the algorithm with the physical system, or verifying the actual controller with a model of the system.

This brings me to what I see as the most important practice made possible by MBD, the “In-The-Loop” simulations. On one side, teams designing hardware subsystems can validate their work by placing their hardware part in a “Hardware-In-The-Loop” simulation. On another side, teams creating control software does not need to have access to the real hardware to be controlled. They can develop and test algorithm using “Software-In-The-Loop” and “Processor-In-The-Loop” simulations.

This reduces the dependency constraints between subsystems and speedup development time.

function y = myfunnyfunc(u)
if any(u == 0)
y = ones(size(u));
else
y = 3*u;
end

This will ensure input and output are always the same dimension. I suggest looking at Level 2 M-file S-Function for more complex things that are not supported by the MATLAB function block.

That being said, I often tell people that what you get from Model-Based Design depends in large part on what you put into Model-Based Design. If you put 10 minutes into an Excel spreadsheet, you may learn that your requirements are correct (or not). This is valuable and can save significant development time. However, if you put 10 days into detailed, closed-loop modeling and testing, you may end up with fully tested, fixed-point code that implements your true requirements on your production controller.