Downloaded 09/09/15 to 130.237.29.138. Redistribution subject to SIAM license or copyright; see http://www.siam.org/journals/ojsa.

php

Chapter 10

Conclusion: Thoughts
about Broad-Based
Knowledge

I hope that you have reached this point in the book with a much better understanding of the
power of a visual programming environment. I also hope that you can see how an integrated
system-engineering environment can improve your designs.
In the process of working through this text, you should have become familiar with a
large number of different disciplines—perhaps some that you had not previously learned.
This was partly my goal. One of the major attributes of a good engineer (or mathematician
or any other discipline you would like to insert here) is both breadth and depth of knowledge.
As I was completing this book, I read a marvelous editorial in the New York Times by
Thomas Friedman, entitled “Learning to Keep Learning” [12]. In the editorial, Friedman
makes the case for better and broader education. He quotes Marc Tucker, who heads the
National Center on Education and the Economy: “It is hard to see how, over time, we are
going to be able to maintain our standard of living.”
Friedman then adds: “In a globally integrated economy, our workers will get paid a
premium only if they or their firms offer a uniquely innovative product or service, which
demands a skilled and creative labor force to conceive, design, market, and manufacture—
and a labor force that is constantly able to keep learning. We can’t go on lagging other major
economies in every math/science/reading test and every ranking of Internet penetration and
think we’re going to field a work force able to command premium wages.”
A little later in the editorial, Friedman again quotes Tucker as saying, “One thing we
know about creativity is that it typically occurs when people who have mastered two or
more quite different fields use the framework in one to think afresh about the other.” The
goal of Tucker is to make “that kind of thinking integral to every level of education.”
Tucker thinks that this requires a revamping of our educational system, designed in
the 1900s for people to do routine work, into something different. The new system must
teach how to “imagine things that have never been available before, and to create ingenious
marketing and sales campaigns, write books, build furniture, make movies, and design
software, ‘that will capture people’s imaginations and become indispensable for millions.”’
In the last part of his editorial, Friedman tempers the nationalistic sound of the state-
ments by noting that innovation is not a zero-sum game. It can be win-win. He says, “We,
China, India and Europe can all flourish. But the ones who flourish the most will be those

289
 290 Chapter 10. Conclusion: Thoughts about Broad-Based Knowledge
Downloaded 09/09/15 to 130.237.29.138. Redistribution subject to SIAM license or copyright; see http://www.siam.org/journals/ojsa.php

who develop the best broad-based education system, to have the most people doing and
designing the most things we can’t even imagine today.”
It is my hope that this book and the products and processes we described here go some
small way to making Friedman’s thoughts real for you. It is clearly possible to learn multiple
disciplines, to bring them to bear on complex design problems, and to create devices using
more automation. It is also possible, working with the visual programming paradigm that
Simulink exemplifies, to work faster, smarter, and more accurately. I truly hope that this
book helps to further that process.
As a final footnote, one of the reviewers of this manuscript made the prescient ob-
servation that using Simulink or any modeling software without care can lead to disasters.
This is very true.
However, I am old enough to remember engineers who, after they graduated, used
only handbooks for the models in their designs. The result for these engineers was often a
disaster, too. Because what they selected from the handbook was not valid in the context of
the design they were developing, their conclusions were wrong. Simulink does not solve
this problem. In fact, no tool can.
How many times have you seen someone using a wrench as a hammer? Workers
always have the opportunity to abuse their tools. The main reason for this book was to
show you how to use Simulink the tool, not by simply learning how to build models but by
showing you how the numerical methods in the background work. Along the way, we have
emphasized the design process and the fact that modern design is a team effort. If you are
new to this world, or if you are a student looking forward to working as a design engineer,
remember that your colleagues want to help. Use their expertise. Share the Simulink
models with them—early and often. Get their feedback and use it. If you are an engineer
with experience in the design of systems, work to incorporate a visual programming tool
into your design process. If you do, do not forget to train the engineers that will be new to
this process. Also, ensure that your design teams have an ample number of old-timers who
know when something looks wrong.
Finally, remember the various tricks and comments that I have made in the text:
• Annotate your models.
• Use subsystems to keep the diagram simple.
• Vectorize the model where you can (and let the user know that you have done so).
• Make neat models; avoid spaghetti (very messy) Simulink models.
• Run the models with the verification and validation tools to see if the results of the
simulation make sense.
• Check the data you are using against the real world by seeing if the simulation produces
results that match experiments.
• If you replace a block in a model with a new block, run the model with both the old
and new block, subtracting the outputs of each to verify that the differences between
them is essentially zero.
In other words, be a good engineer.