Good point, Alex - and the number one point of contention comes from the leading priorities of the two groups. With the engineering group, they focus on the final product with such things as optimal design, efficiency and / or easy of use. It is these types of concerns that their performance is judge on. On the other hand, IT tends to focus on security, because if there is a breech, they are the ones whose job in on the line. Unfortunately, security and effeciency do not necessarily go hand in hand.
First, the large interest in IT careers is that they pay well and they are secure. When the IT person develops a reputation for being able to solve all problems and answer all questions he quickly becomes a very valuable asset, and also, usually, a well paid one.
Now as for the predominance of software, it has become a case of, outside the custom million gate chips, the electronic design has become simpler, requireing only a mastery of the mysteries of electromagnetic physics to be right most of the time. That leaves all of the logic portions of the challenge to the programmers, a race dedicated to taking over the world by softening everybodies thinking abilities.That is why so much of everything is now done in software.
The clash between what's been happening in IT networks versus those on the factory floor is a long-standing one, going back at least to the 80s when the first proto-IT networks were built and attempts were being made to integrate them with "silo" type automation and control protocols and systems in the factory. In the late 1980s I worked at a company doing app development for automation and control systems using a version of Forth. Of course the programmers had to DIY build their own in-house IT-type system for all of us, and it kept breaking. To be fair, though, there wasn't much in the way of alternatives at the time.
Another conflict that's emerging is between IT personnel and industrial and mechanical engineers who run the factory. In many cases, traditional IT is now being tapped to set up in-factory wireless networks. These folks adhere to IT practices, and as such are set up for the get-go to be non-collaborative with their users (the factory engineers). It's a pain point and a source of conflict for both, and is certain to get worse as wireless nets proliferate in the automation sector.
@Naperlou: I think that's a really succient way of summing up the role of the mechatronics engineer. Traditional IT is a long way even from embedded software engineers and developers so there are a lot of bridges to cross and connect, both from a technical and cultural standpoint.
At one time, the electrical engineers had as a dream the elimination of Software Engineering. They would do everything in hardware, either custom logic or FPGAs. Of course, this has completely reversed itself. At the last FPGA class I went to there were several teams of a hardware engineer and one or more software engineers. We were sitting down with a PC and the FPGA board spending most of our time in a tool based on the Eclipse platform. This is a software development platform that has been adopted by most of the vendors our there becuae of its openness.
I have, as an IEEE member been asked to help judge student projects at a local univeristy. These were EET and CET programs. All of these devices, including a wire cutter, had a processor and software involved. Some of it was extensive. I noticed that the students were often somewhat overwhelmed by the software aspect of their projects. The school will be including more software training in the future.
To bring this post back to the subject of the article and Beth's reply, I looked up the definition of Mechanatronics on Wikipedia. It is very extensive. In fact, I find that it is too broad. What you really need is a multidisciplinary team that includes the various disciplines. It is a lot like Aerospace Engineering. Since aerospace projects (spacecraft especially) include most disciplines, it is impossible for one person, or field, to cover them all. Thus it is appropriate to include IT as a driving technology. On the other hand, the IT professional cannot be expected to learn all of the other disciplines as well. There is a lot to handling the information in a system. So, to move forward with the analogy to aerospace engineering, I expect that a mechanotronics engineer wil be working at a higher level, concentrating on the interaction between the mechanical and electrical, while more specialized engineers work in the details of various parts of the system.
As software (embedded or otherwise) becomes a critical element of a product's design, it makes sense that there's a heightened focus on IT disciplines like networking, human interface design, and Web services. As you well point, however, it does require a certain mindset shift when it comes to thinking about IT's core role. Making the transition from hands-on implementator to strategic problem solver is something IT professionals and the industry has a whole has been grappling with for the better part of a decade. Definitely interesting food for thought.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.