You can't be a good programmer without a deep understanding of the engines that the software uses and the limitations of the tools. A good ingerstanding of the hardware would be utilitarian as well. Plus physics, chemical and mechanical engineering etc. Well mostly the software guys just want to twiddle bits. At a high level.
I liked it better in the old days when harware engineers learned software and processors.
A computer engineering degree is distinctly different from a computer science degree. The degrees are similar but the computer engineering degree is much more hardware oriented. If I had my pick I would prefer the computer engineering degree. The pure computer science people tend to have a very difficult time with software as it relates to hardware.
Mechatronics has been introduced in a lot of undergraduate engineering programs to teach how Multidisciplinary design can be orchestrated by a few engineers instead of a large team. Electrical-Electronics, mechanics, and software are the three core elements of Mechatronics and traditionally it has been part of the Mechanical Engineering program at universities. Although I find Mechatronics to be an intriguing field of study, it doesn't replace the role of having individual specialists in the three core engineering fields (Electrical, Mechanical, and Software) who can resolve problems using conventional and creative design techniques for New Product Development.
I think part of it is the size of the company you work for and their resources. As a test engineer I was responsible for both hardware and software development, as well as for fixturing for the DUT, racks for the test equipment, wiring, computer selection with accompanying cards for communication tasks and whatever else was needed. In other words, where I worked, the test engineer wore all of the hats. We were blessed with a tool shop and a design group - but they worked off of our specifications and if we were going to get something done in a reasonable amount of time, we would have to have a "rough draft" of what we wanted for them to tweak. That said - it was an incredible learning experience and a lot of fun to cross over to other disciplines. I think you can have both designers and engineers - good solid functional robust engineering comes first - bells and whistles come last if time and money permits - and that lets your creative design juices flow. Ironically it is the bells and whistles that impress the uninitiated - but give me a good solid engineering design every time!
gsmith120; One of the projects that I worked on had an air compressor specification conflict. The specifications variations were 4 scfm @40 psi, 8 scfm @ 80 psi, 10 scfm @ 120 psi, and 14.7 scfm @ 175 psi. At several meetings I brought up this issue, and asked that the mechanical engineer(s) pick one specification. The combined cost of the compressor and electrical service required ranged from about $500.00 to about $1500.00, so there was a potential cost savings. The final specification was 14.7 scfm @ 175 psi,to allow some extra capacity. As you have noticed, the lack of rational thought put into this bothered me.
GlennA, you make a good point about ME fixes. I remember having and hearing the hardware/software disagreements but don't ever remember including MEs.
I strongly dislike the egos that seem to get in the way. Short but true story about a so called sr systems engineer. The way he had written at least one of his requirements cost his company (my company's partner) a lot of unnecessary money. Basically, he spec'ed a very expensive generator when it wasn't needed. His so call smart comment was "the manufacturer didn't complain". I was thinking why would they since they are selling you a Jaguar when all you need is a Toyota. Wasn't much a surprise when the project blow its budget.
Engineers and the process of design are often defined by the tools that are used. I started out in physics, and we thought of engineers as a lower life-form. I later became a systems and software engineer. I also often worked on the hardware side. One thing that I realized in the transition is that the engineer is the creative one. The scientist is trying to describe the world as it is. The engineer creates new things. Much of my experience is in the aerospace industry, and I often worked on systems that were very advanced and involved things that had never been done before.
As for "design" we had people who were titled Designer. These were generally senior draftsmen (remember them). They were the ones who took the engineer's concept and turned it into something that would work. They knew all the design rules and had lots of experience. It was a real joy to work with a talented designer. I was doing this on space systems, so the goal wasn't to make something look nice, but to make it work.
Much of what you talk about is interesting because I see it just starting in the commercial world. In the serospace industry we had a matrix organization. Programs would pull individuals as needed from the various engineering discipline organizations (e.g., structures, software, controls). We worked in interdisciplinary teams, each with our anchor in our discipline. We also worked with manufacturing. I track the embedded design world and do a lot of consulting there. These are mostly electronics types. They are just starting to talk about many of the issues I dealt with in the 1980s. It is sad, really, that this is so. Many of the issues they deal with are organizational and have been dealt with in the past, but there does not seem to be any memory in the engineering discipline.
Perhaps it is up to the schools to try and bring this together. I don't believe in a generic engineering degree. There are too many details in the various disciplines that need to be learned. We could do a better job of educating our young engineers in the cross disciplinary concerns and techniques that are important to today's products, though.
Hi, Rich. Fantastic column. You asked for my take, so here it goes...
The most recent phase of Design has moved passed "Multi-disciplinary" and onto "Inter-disciplinary" design. Interdisciplinary design differs from multidisciplinary design on the subject of "purpose." The fact that a product required knowledge from multiple traditional disciplines is an observation. A product that was designed with full knowledge that each component will need to seamlessly integrate with others to form a coherent whole is designed with the purpose of integration in mind.
Manufacturing continues to evolve through the multiple components of systems design:
Input - if you use the best ingredients, your output is guaranteed to be optimum.
Process - if you follow the tenets of Six Sigma and Lean processes, your output is guaranteed to be optimum.
Output - Quality is Job 1 - do everything to optimize each component.
The difficulty is that this Input - Process - Output view is linear and does not recognize the importance of feedback - the output of a subsystem is used as input to a higher-level system. The optimized output of the subsystem may be optimized to such tight tolerances that it is unable to accept the feedback from other subsystems.
A completely optimized system is static. One that is fault-tolerant can adapt and accommodate out-of-tolerance behavior from sub-components and continue to produce the desired output.
Interdisciplinary is the "Bad News Bears" analogy -- The All Star game in baseball is often not the most exciting or well-played game. Each of the All Stars is highly efficient at their own position, but without months of practice, the collection of multi-team players does not play as an integrated whole.
Design and Art are not the study of "Beauty". Design and Art are the study of "Membership". Engineering is the blend of disparate knowledge in Energy, Materials, and Information into a coherent whole for the purpose of solving a particular problem. When Engineering relies on the tenets of Design and Art, the individual components cease to be individual components from multiple disciplines and emerge into members of an integrated whole.
Your comment about 'fix it in the software' bothers me. Partly because I was told that by a mechanical engineer, who I could only surmise knew nothing about electrical controls ! There are some mechanical design flaws that can ONLY be fixed by a mechanical revision.
The biggest problem that I have experienced related to interdisciplinary design is egos. I have had to work with many engineers, from a variety of disciplines, that could not accept suggestions identifying flaws in their design, or fixes or improvements.
In an age of globalization and rapid changes through scientific progress, two of our societies' (and economies') main concerns are to satisfy the needs and wishes of the individual and to save precious resources. Cloud computing caters to both of these.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.