I used to enjoy watching Star Trek, but not because I was a sci-fi buff. Most interesting to me were some of the technological assumptions made by the scriptwriters.
My favorite examples are the plot twists that hinge on taking complicated equipment designed in another solar system and getting it to work somehow with earthly gear. If the Hollywood depictions are accurate, engineers two centuries hence will routinely take stuff devised by threeeyed creatures with gills and connect it seamlessly to the technology that happens to be at hand. Moreover, they will be able to accomplish such tasks seemingly without exasperation or even breaking a sweat.
What I find humorous about this is how it so sharply contrasts with my own more mundane adventures trying to get 20th century test instruments to talk to each other. My travails in this area took place during the 1970s. The process of making connections between electronic devices back then used to be at best time-consuming and at worst a can’t-get-there-fromhere nightmare.
That era did, in fact, have standards governing communication protocols for controllers and peripheral equipment, but there were generally big gaps in what they covered. Most such standards didn’t extend much past what are now called the physical and data link layers. Significant aspects of control schemes used to be left to the imaginations of software developers. This meant that similar instruments that came out of two separate design groups at the same manufacturer might obey commands in completely different ways. Individual instrument vendors would define their own proprietary communication protocols, but even these were not always adhered to strictly. In many companies they were basically just gentlemen’s agreements. It was not uncommon to find that designers had treated their own firm’s protocols as prescriptions that were to be followed unless it was inconvenient to do so.
Even getting instruments manufactured in two different parts of the same factory to exchange data could be trying. I still vividly recall struggling with a frequency synthesizer that just wouldn’t respond to any commands it received over a “standard” instrumentation bus.
We finally got through to a knowledgeable application engineer who revealed the secret. The instrument wanted to see binary strings that were the exact inverse of those understood by every other device in that particular vendor’s product line. The reason: This mode of operation had enabled the instrument’s designer to eliminate a resistor from one of the circuits, for a savings of about ten cents. This in an instrument that would go for roughly $10,000 at today’s prices.
Fortunately we have progressed far beyond those dark ages of communication protocols. Manufacturers in a variety of industries now realize that interoperability has wide ranging benefits. End users increasingly vote for open connection standards with their pocketbooks, demanding that vendors provide ways of connecting to their control equipment by means of readily available interface components that obey openly published protocols.
This movement continues to gain disciples. One indication of its strength was the strong attendance at an open-control meeting this past spring in Paris. Called the PC & Automation conference, it was hosted by the Interbus Club, an organization of vendors and users of the Interbus industrial bus. The conference promoted the idea that PCbased products and services could serve as open standards for factory automation.
Behind this movement is the idea that suitably equipped PCs will be able to run software from a variety of sources without needing any modification. Also part of this scenario is the concept of configuring industrial equipment so that it can communicate over a standard bus. The conference organizers hope Interbus will be this standard. There are now more than 1,000 different industrial devices available on the Interbus from over 300 different suppliers, and it is widely applied in Europe.
The definition of more uniform software interfaces for control hardware is one key development in this area. It lets suppliers of software revise only one interface to make their packages work with different hardware. A few conference speakers reported they have indeed integrated software from one source with hardware from another.
Manufacturing engineers from several large automakers who spoke at the conference voiced their expectations for PC-based automation. They see industrial control networks eventually communicating seamlessly and in a straightforward manner with general business applications, a view promoted by venders of software in this area that also spoke at the Paris conference.
All in all, the idea of open controls is increasingly catching on. Today most largescale factory automation projects still come from a single vendor. Nevertheless, users have started asking as a matter of course that automation vendors install controls and software that adheres to an open standard with published protocols.