All engineers use computers, but do all engineers write computer programs? Could they? Do they really need to be able to?

The essence of modern engineering design is integration and simultaneous optimization of all the elements in the multidisciplinary engineering system. And computer software, whether it is for modeling and analysis or for real-time application, is an essential element. It is often the most costly element in terms of complexity and development time and can also be a major source of system failures. So if engineers only just use programs like Excel, MATLAB or LabVIEW and then rely on software specialists to write customized analysis programs or real-time application programs, aren't they failing in their integration and optimization mission?

At most universities, freshman engineering students take an introductory computer programming course usually taught by a non-engineer using a programming language like C or Java to solve non-engineering-type problems. Students do little, if any, computer programming over the next two years, usually as a last resort. When it comes time for the senior-year capstone design experience, all the computer programming gets handed off to the computer geek on the team. Where is the integration? Why should we then expect something different when our graduates become practicing engineers? Engineering educators are responsible for this situation and immediate changes are needed!

Let's first differentiate between conventional computer programming and real-time computer programming. Real-time software is at the heart of multidisciplinary engineering systems. It differs from conventional software in that its results must not only be numerically and logically correct, they must also be delivered at the correct time. It must embody the concept of duration, which is not part of conventional software. Real-time software used in most physical system control is also safety-critical. Software malfunction can result in serious injury and/or significant property damage. And asynchronous operations, while uncommon in conventional software, are the heart and soul of real-time software. The hardware interrupt, the capability to stop the current execution of a program and service some device or some sensor outside the program, is the nitty-gritty of real-time software.

Dr. Fred Stolfi, a mechatronics' professor at Columbia University and long-time industry practitioner, says working engineers use computer programs like Excel for data analysis. They are also familiar with CAD software for both mechanical design and electronic circuit analysis. However, they fear traditional code - like C and Assembler - which can perform real-time operations. So while they are comfortable doing computer analysis, they turn computer control over to a software expert. In his view, the problem is also generational. Older engineers often do not trust computer analysis and prefer to design by the "seat of their pants." Younger engineers seem to trust computers too much and do not think about what the computer results are saying. In general, control is a lost art and with it real-time programming. The situation is the same at the university. When students are asked to design an original system as part of their capstone design experience, they realize they want a real-time microcomputer or computer to control their system and do not know how to implement it.

In the next article, I will offer some solutions to the problem I have described and suggestions for effective computer programming, both for analysis and for real-time applications.

For more information on designing for mechatronics and mechatronic collaboration tools, visit The Mechatronics Zone.