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.
When I attended college it had an EE department and a CS but not they are considered the same department. Oddly enough a lot of my EE friends now write software code. I write firmware (VHDL) but not software.
The article didn't really examine the blurry line of the EE. When microcontrollers became cheap enough to use in designs I slowly became what we now call a Firmware Engineer. Frequently we just call the Firmware Engineer a Software Engineer and in some companies the engineer is a CS major rather than a EE. I've hired both CS and EEs over the years, but I do prefer EEs that learned how to write code, rather than a CS major that knows how to solder. It seems that the troubleshooting skills of a EE are much better than the CS major. The code writing EE is a blurry line between the hardware and software world. Another reason to call it Firmware.
My college experience was that you were either a hardware engineer or a software engineer, with some overlap of course. It definitely paid to know as much as possible of the "other world".
I have been a Software Engineer for the past 18 years while my original degree and work was in Mechanical Engineering.
I have enough experience to realize that most Engineers should not be designing large complex software systems. Just becuase you can write a program in Java to solve some engineering calculations does not mean you are qualified to deisgn a complex control system.
It helps to have a good generalized ability and to also know when to get help.
I think you make some excellent points, Bob. On the lighter side, I solved the problem by marrying a handsome M.S.E.E.hardware guy. I am a test engineer with a basic working knowledge in hardware but where I shine is in software. Hubby knows some software but can run circles around me in hardware and circuit design. We make a great team although when anything goes wrong with the project we all know to blame the hardware ;)
This response has a huge danger of becoming way toooo long but I will try to condense my thoughts on this subject. First of all, engineering design and software programming are NOT the same or even that close. Both have unique training and experience needs AND they both require somewhat different types of personal characteristics. Yes, an engineer should be able to program a computer (that also means a uP). But most engineers do NOT make good programmers - the skill set is just too different. And likewise, good programmers do NOT make good engineers for the same reason.
But there are times when each (programmer and design engineer) need to intrude a bit into the other guy's world and certainly each should know enough to be able to do so, i.e. to at least understand a bit of the other guy's mystery world.
Given all of the above, there are obviously folks who can do both jobs superbly well. But for the average person, not so much.
Another thought - certainly an engineer has many tools that do require some level of computer expertise (e.g. using Matlab for simulation, using Labview for testing prototypes, using Excel for data analysis) and certainly the competent engineer should have a fair ability to use all of these.
And sometimes a design engineer has no choice - the project team is too darned small and he or she needs to be a 'jack of all trades'. Kind of fun but I'll bet the certain facets of the project suffer (e.g. the software part for an embedded uP).
Just one last thought (I promise!) - I think that a college education should provide exposure to everything that an engineer will require to be a good and successful engineer when he or she gets out into the REAL world. That does mean exposure to software programming techniques (yes, Virginia, there are both BAD and GOOD software techniques and procedures!)
I think that the colleges should teach and use engineering programming more in the classes. The biggest pet peeve of mine in college is how is what we are using applied to real world situations. I write my own code for the most part until it comes to something that give me a problem. Then I turn it over to the engineer programmer to solve my problem.
Our LinkedIn systems and product design engineering group discusses if they are happy with their decision of remaining a technical contributor instead of becoming a manager.
Against a backdrop of mounting product complexity and a need to keep a lid on development costs, companies are recognizing a need to make simulation a more integral part of the design process. In response, vendors in the CAD world are building out CAE functionality as part of their CAD suites while simulation vendors are building tighter integrations to leading CAD tools. Keith Meintjes, Ph.D., Practice Manager, Simulation and Analysis at CIMdata, Inc., joins Design News CAD Editor Beth Stackpole in this radio program to explore the new face of integrated CAD and CAE, how companies are benefitting from this tighter partnership between platforms, and how integrating CAE earlier in the development cycle pays off in optimized product designs.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
7 
