This article was printed in CONTROL's October 2009 edition.
You already know you're busy. I know both technical and non-technical professionals who get jitters about what they have to do Monday morning on the previous Thursday. This can make it a little hard to enjoy the weekend. Historically, because all technical pursuits have so many details, doing them better meant knowing ever more about ever smaller bits and pieces. Because there are only so many hours in a day or life, specialization in science, medicine and engineering was the only logical path to expertise and mastery. The joke among the physicians I used to cover was that hyper-specialists will research more and more about less and less until they know everything about nothing. Heh.
Pretty funny, until someone loses an eye, or in this case, starts to miss some critical facts in a slightly higher-level or neighboring technical area that they've long since left behind by focusing all their attention on their specialty's particular minutiae. And sometimes technical folks add that they tend to lose sight of the original motivation for their work, not to mention the reminders and readjustments their mission may need to respond to new circumstances. Also, many specializations are cemented in place for many years, especially in huge and far-flung organizations where it's already hard for the right hand to know what the left is doing.
Sadly, this one reason why mechanical engineers don't talk to electrical engineers, who don't talk to controls engineers, who don't talk to software engineers. Of course, the old joke here is that only "civil" engineers are polite.
Interestingly, I've noticed that some aspects of professional engineers sort of translate into the components, systems and networks they design and build. It seems inventions really do mirror the minds of their inventors. Unfortunately, some devices also have drawbacks that reflect how their developers fell short on logic and creativity, while other solutions are held back to protect short-term revenues.
Certainly, the different fieldbuses grew out of proprietary communications, so they didn't talk to each other much until recently, when several protocols began to cooperate on Electronic Device Description Language (EDDL), and then invited in Device Type Manager (DTM) methods with help from the OPC Foundation. In fact, the fieldbuses now seem poised for some serious data sharing, if not plug-and-play interoperability yet. (See this issue's "Breaking Through" cover story on fieldbus architectures.)
So, if technology can reflect and mimic some habits of their developers, then is it possible for people to take a lesson from how fieldbuses and other technologies are learning to interact and cooperate?
First, maybe lift up your eyeballs from your usual grindstone. Next, go and talk to a few neighboring specialists about what they're doing, or give someone a hand with an unusual, but still job-related activity. It can't hurt for specialists to take a short field trip to more generalized areas, and it could be very helpful and therapeutic. Then, look back at your usual space and tasks, start to reestablish the overall context for your routine work and incorporate any needed updates in it. Of course, you may already be interacting with colleagues and well-aware of your context, but I'll bet you're not doing it enough.
In addition, if you're a manager or occupy another decision-making position, set a good example by taking a few similar outings to unfamiliar areas. Then, recruit your staff to break from their usual concentrations for a short while and go on similar excursions.
I typically find so many connections between so many of the control and automation fields I cover that I figure it's got to be useful for others to do it. You know, fieldbus does hardwiring's job. PCs take over from PLCs. P&ID drawings evolve into function blocks and CAD-based simulations. Most physical and software-based devices are becoming generalists. Their engineers should try it too.
