Open doesn't always mean interoperable

EVERYONE TODAY is relying on the appli­cation of open and, in some cases, de facto standards to connect and operate modern automation systems. Everyone using these products also can relate at least one story of how they had difficulty connecting the parts of an apparently open, standards-compliant automation system into a whole.

Adherence to open standards inherently should imply interoperability. Yet this often isn’t the case. I’ve seen this happen many times in my career. One of the biggest causes is manufacturers trying to protect market share.

Even so, open standards should be open stand­ards. So, how is this prevented from happening? The three main culprits, not necessarily in order, are as follows:

• Inadequate testing—The problem might be because the standards themselves are so loose that they can’t be properly tested, or they aren’t verified by impartial third parties. This “looseness” occurs because the standard’s developers don’t want to exclude anyone because it’s often the manufacturers who provide most of the membership revenue, technical input, and staff for the standard’s development. These vendors also want to ensure they don’t lose their investments.
• Layers upon layers—Just as the OSI model has several layers, so do operating systems. Sometimes the layers seen by the user adhere to the standard, but there are proprietary layers underneath that might restrict the level of openness the system can support. To paraphrase a well-known logo, “proprietary inside” will certainly have an impact on what’s on the outside.
• Enhancements—Problems arising from “improving” a standard might be innocent, or a known potential for problems might be masked by the promotion, “We made this even better for you.” Sometimes, unless the standard has a mechanism to support and interpret these extras, as Foundation fieldbus does with Device Descriptions, it really means we no longer adhere to the standard, and, as a result, no one else can connect with us anymore. This sounds like proprietary technology to me.

The biggest issue—and the reason less-than-open openness is a bad thing—is that few people understand these technologies well enough to identify the cause of the problems. They end up blaming the technology when, in fact, “We have found the enemy, and he is us.” The enemy really is our complacency and reliance on others to prevent problems with open technology from happening.

Of course, with increasing outsourcing of non-core automation technologies and the aging of the workforce, there are fewer people available to do more than keep many plants running. Even facilities that still have in-house engineering staffs are using them more for maintenance, rather than learning about new technologies and how they can save their companies money.

But not all is doom and gloom. Most manu­facturers truly and fully support the open concept. But not everyone is perfect, including we end users for accepting and allowing infractions to happen. So, how can you make open standards work better?

• Continue to use the resulting technology and then provide feedback and input to the supporting standards organizations. (Even though it’s not a standards organization, Microsoft does this with its products.)
• Tell your automation supplier you expect open to mean open, and that means not having to prepare any extra files or special items to work with someone else’s open product adhering to the same standard.
• Get involved. It is easier to influence something early on in the process, rather than at the end when your project is well underway. There are many ways to get involved. Join the OPC Foundation, the organizations for Foundation fieldbus, Profibus, Modbus, etc, or professional societies such as ISA and IEEE. Try to make a difference.

Whom should you blame the next time you get called in the middle of the night because of a problem that involves an open system being less than truly open? The main person to blame is looking at you in the mirror.

Ian Verhappen