[sidebar id="2"]Imagine Rockwell Automation's surprise back around 1994 when the auto industry, immersed in the OMAC push, allegedly said that it wouldn't use Rockwell's new connectivity protocol, DeviceNet, unless it was "open" and available to all.
As a result, the Open DeviceNet Vendors Assn. (ODVA) was formed. DeviceNet is an I/O network that allows various form-factor devices to communicate with a central protocol adapter. The original idea was to simplify the installation of I/O, similar to remote I/O but with smaller concentration.
With a proprietary protocol, Rockwell was counting the bucks, since processor prices were coming down with more distributed control and open PC-based control movement(s). Rockwell's Rich Ryan talked about Rockwell's foray into open control in an ISA session then. One slide said it all: "All control vendors will ultimately become I/O vendors."
I remember a big Ford expansion that used DeviceNet. Cutler-Hammer received the lion's share of the I/O purchase, while Rockwell maintained its grip on the processor and software side. But it was a telling sign. If anyone can develop DeviceNet interfaces, then anyone can use them.
This was between 1995 and 1998. Fifteen years later, we are still somewhat hostage to I/O brands.
The fieldbus market is big. The protocols are varied, and they are all supposed to play nicely with the others. In most cases they do. But as users and OEMs, we should be able to pick best of breed for our applications and not have to pay a king's ransom for the privilege.
Dennis Baca of Ford Motor's manufacturing team wrote in 1997: "With a DeviceNet control system in place…" He didn't say a Rockwell or Siemens control system. A thought shift was underway.
A year earlier, Mike Lane of Wago made a presentation about open I/O options. The message: PLC vendor and I/O (modules, not devices) vendor do not have to be the same. So we move forward, and in most control systems there is an integration of vendor I/O modules from various disciplines.
So why would you want to incorporate Rockwell-, AutomationDirect- and Invensys-connected I/O in the same control system? Although price is always a consideration, you might think that using an Opto 22 DeviceNet interface is better because of size limitations. Invensys or a similar DCS vendor might have onboard valve control. Festo might have an I/O patch board for pneumatics, which just makes things easier. How about your drive supplier? Does it support any type of direct interface?
A Rockwell strategy paper from the early 2000s indicated the company knew that the behavior of its customers was changing, and were looking for a "roll your own" system. It wasn't surprising to see that the strategy was to entice users with what they want, then convince them to move to Rockwell architecture. A captive customer is the best customer.
Having worked for Rockwell, I get it. I also understand that there are compact cars and luxury cars, and so you have to be careful when you select an I/O supplier you are unfamiliar with. It's your decision whether you introduce various I/O vendors into your ecosystem. It is imperative, however, that you treat that decision seriously.
Support, inventory, availability, reliability and so on are important. Equally important are the specifications on the modules and interfaces themselves. The availability of a specialized module could be a selling point, or not.
Technically speaking, fusing, isolation specifications, removable wiring components and the like could make your choice easier. Maximum current per output module is a real stickler, and has kiboshed many a project.
I sometimes wonder if thinking we have a choice is just as powerful as actually having one. We have come from a proprietary world in automation, into a different proprietary world of "Yes, it might work, but stick with us because we guarantee it."
The benefits of mixing and matching I/O suppliers on the module side can be substantial. Though there can be downside risks as well, the up might overshadow the down.
Use other I/O? Just be informed. Heaven forbid someone claim one thing and deliver another.
