Log In Register

Jump Start IT

How you can use XML and Web Services to empower business systems with plant information

03/19/2003

1 vote
Text size: - +

The cost of programming often drives people to purchasing broker software, such as process historians, frameworks, and other intervening packages that make the IT connection for you. Clark explains that although the cost of software may appear to be outrageously expensive, it often is priced much less than the cost of doing it yourself.

Clark warns about relying on your IT department for help in this matter, especially for programming support (see sidebar, "Rules for Working With IT").

As for .Net and Web Services, this may be the most inexpensive solution of all. "The .Net architecture includes Microsoft's implementation of Web Services," explains Clark, "and it works very well if all of a plant's control and IT software runs under Microsoft operating systems." It is still a DIY solution, and one you may not be ready to tackle just yet. The programming languages of Web Services, including Java, C++, and C#, may not be known to your staff.

Do It Yourself

The woods are full of control engineers who have made their own connections to IT. One of the most common ways is to use the capabilities already built into your plant's existing HMI/SCADA or historian system. Tony Murray, director of information technologies at Washington Quality Foods, Halethorpe, Md., is connecting his plant-floor system to a Baan ERP package. "We will use Wonderware FactorySuite scripting to log data collected by plant floor devices to the Microsoft SQL Server database," says Murray. "We'll use SQL Server as common data storage to integrate the plant floor with our Baan ERP system."

Larocca of Solutia is doing the same to reach IT systems. "We use SQL hooks into our data historian system to pull data into higher-level IT software," says Larocca. "Our data historian pulls data from plant floor controllers with OPC or proprietary drivers."

Even with existing historians or HMI/SCADA systems, you might have to write some code yourself. "I've personally used custom OPC code with Visual Basic programs to pull data into enterprise applications directly," says Larocca.

Products are rapidly becoming available to help you make direct connections from the plant floor to the top floor. Opto 22's (http://www.opto22.com) Snap-M2M system connects process I/O to higher level software via an Ethernet connection and XML coding. Bayer AG is using the system for a supply chain management application that gathers data from a customer's chemical and gas storage tanks and loads it directly into an Oracle database and SAP SCM system.

Wago (http://www.wago.com) has teamed up with Advanced Production Systems (http://www.teamaps.com) to produce a similar system. It combines Wago's I/O system with APS' I/Gear software. The combination collects data from plant floor I/O and sends it in real time directly upward to IT systems such as ERP software and databases.

Omron Electronics (http://www.omron.com) has CX-Server OPC software that can connect PLCs to any ERP or IT system that supports OPC servers. Other Omron PLC support includes its CX-Supervisor HMI with OPC connections to any ODBC database.

Alas, you can't just send data upstream willy-nilly. You need a plan of some kind. For example, you may be faced with problems like this one: "The process control system monitors the flow of raw material, so you set up a totalizer and, when you reach the target, it stops the flow," says Loar. So far, so good. "The final transfer then needs to get shaped into a raw material consumption transaction for the ERP system. So you need to trap the totalizer value and move it into the ERP system. But what is the totalizer target? Is it the recipe value or the ERP bill of materials value? Are the units of measure different? Who converts them? Who translates flowmeter FQI123's tag into the ERP item number 789? What if the transfer finishes in the middle of the month-end blackout period?"

Somebody in your group has to answer questions like that. If it's not your group, then you'll have to call in a roomful of ERP consultants, pay them $200-plus per hour each, and have them solve the problem for you.

Every other IT system, from SCM to MRP to WMS, has similar unique needs for data. Just because they are getting more open doesn't mean they all think alike. It becomes your job to determine what to send, what package to send it to, and what format the data should be in. With luck, XML schema and document type definitions (DTDs) will solve many of these problems for you.

Broker It

Your IT folks may be familiar with "message brokering software," because they have probably purchased some of it for enterprise applications integration projects. They may very well throw names like IONA Orbix, BEA Weblogix Integration, Mercator Integration Broker, SeeBeyond, and Microsoft BizTalk at you.

As near as we can tell, based on the inputs from users and vendors alike, none of these IT message brokers will do the job for a process control system. We mention them only because your IT department probably will.

In the process control industry, we have our own broker software that connects plant floor systems to IT. These are called apps, HMI/SCADA systems, process historians, frameworks, and several other names.

You may find it comforting or less painful to use a broker package, so here's a quick rundown on what's available, starting with simpler systems:

1 vote

Read more about

ControlGlobal.com is exclusively dedicated to the global process automation market. We report on developing industry trends, illustrate successful industry applications, and update the basic skills and knowledge base that provide the profession's foundation.