Mission possible: Control and IT integration

Use technology to enforce policies.Policies alone can’t ensure communication networks remain stable and authorized. Need proof? In the 1990s, a number of DCS engineering workstations were connected to “unauthorized” modems. The argument was that these modems allowed the automation engineer to login from home and help the operator in the middle of the night. Eventually many of those automation engineers were “right-sized” out the door, or they simply moved on. Some of those DCSs are still in use, and those unauthorized modems remain connected.

Today corporate IT policies may include a list of approved brands and models for switches, servers, etc. Sophisticated network configuration management technologies exist to monitor network health as well as help prevent unauthorized connections. IT departments use “sniffer” software that knows what brands and models are permitted, checks their configuration, etc. If an unauthorized brand or model is installed the, sniffer software will detect and alert the network police—often within minutes of the device being connected. Likewise, if someone configures an approved brand or model incorrectly, or an unauthorized change is made to the configuration, the network police will be calling.

Embrace ISA S95 IT departments have been integrating business applications, such as ERP, using software models and templates for more than a decade. ISA 95 can provide a similar structure for integrating process and enterprise systems. Integrating process with enterprise systems will be easier if familiar terminology, models, and templates are used. Users who look at ISA S95 “standards” for the first time are surprised to find that they aren’t specifications for defining messages and/or programming interfaces. Instead they learn that S95 is a specification that defines alignment processes. It encourages control-system and related product manufacturers to incorporate S95’s terminology and use one or more of its many models as part of their products’ integration architectures. Even though S95 doesn’t define a formalized protocol for information exchange, organizations such as WBF, formerly World Batch Forum, have created royalty-free implementations of the S95 specification using XML schema definition language. The result is integration models that enterprise IT folks are likely to recognize and more quickly embrace.

Use familiar designs. Designing Large-Scale LANS by Kevin Dooley describes a standard network structure that has been widely adopted by many IT departments. In a paper called “The IT Implications of ISA S95 and ISA 99,” Brandl expands the three-layer network architecture described by Dooley to work in conjunction with the ISA S95 specification. Brandl takes an IT architecture that’s familiar and widely accepted by IT engineers, and explains how to extend the architecture to include automation and control systems (See Figure 1 above).

Communicate with one another. Verhappen adds, “Communication is always key to improving relationships. For example, once folks understand why a required level of reliability is necessary, they gladly will work together to develop truly creative solutions. As a result, both groups gain wisdom that they can reuse for the good of the company.”

Rezabek adds, “For the most part, I think both IT groups should ‘tread lightly’ in each others’ domains, and we should do our best to play well together.”

The bottom line is that plenty can and should be done to integrate plant and enterprise IT responsibilities. Just don’t forget there’s also a need to address process control.

Peter Martin, vice-president of performance measurement and management at Invensys, has a way of making you look at things differently. That’s just what he did when we talked to him about the issues associated with plant and enterprise IT.

Martin believes that for far too long IT, and to a lesser extent I&C departments, have been preoccupied with technology when, in fact, both groups should be working together to create real business value for their company using existing technology investments.

He says business leaders are digging in their heels, declaring, “It’s not about connecting DCS and ERP systems or the latest Microsoft this or that; it’s about running the business better! If you want more money for upgrades and new technology gizmos, build a business case with tangible numbers that you’re willing to stake your job on!”

“I know that sounds harsh,” says Martin, “but in today’s economy, business leaders must put a stake in the ground. They must make their companies behave differently than in the past, or else they—both the executives and the company—won’t exist. That’s where automation professionals can deliver solutions. It’s the motivator for melding IT domains into a unified culture.”

When Martin says automation professionals have an advantage, he’s talking about the control aspect of automation—performing measurements, analyzing those measurements with business objectives in mind, and initiating actions that bring the measurements and objectives into alignment—all in real time, by which Martin means at least daily.

Automation professionals understand control, but probably only in terms of pressure, level, flow, etc. They probably haven’t considered how they might apply their knowledge to implementing business control, but when they do, they’ll find they need better connectivity with business systems. That’s where the automation and IT partnership comes in. To achieve what Martin is suggesting requires:

• Eliminating cultural islands
• Learning to use and express things in business terms (productivity, not availability, reliability or utilization)
• Understanding the processes to be controlled (influencing variables)
• Identifying measurable business goals (set points)
• Establishing critical process indicators (key manipulated variables)

One other major hurdle must be overcome—the self-perception of people working in automation.
More than 25 percent of respondents to an online poll conducted in conjunction with the Control magazine salary survey (June 2006) replied, “We’re more of a set of tools than a profession. I think of myself as an engineer, not an automation professional.”

By definition, professionals are people that have or demonstrate great skills in a particular discipline, are experts in a field, and who are getting paid for what they know.

Answer this: Who in your company knows more about identifying the causes of so-called “uncontrollable variables” than people working in the field of automation?

You are professionals. Stop making excuses and get in the game!

Dave Harrold