Jump Start IT

Figure 1: Get Through the Cloud

Plant-floor control systems can reach ERP and other information technology (IT) software in several ways including do-it-yourself connections using OPC and Visual Basic; broker software, such as process historians and frameworks systems; or by adopting the .Net architecture.

Let's start with the infamous Internet "cloud." You've seen this on diagrams. The Internet (or any network for that matter) is portrayed as a cloud (Figure 1), because you don't really care how you get to the ERP or IT system. You can connect through the "cloud" via Ethernet, Internet, intranet, wireless, hardwired connections, or combinations thereof.

Your control system world, on the other hand, exists in a clearly defined and protected space. It has its own networks, such as fieldbuses and device buses, that connect field instrumentation and control elements to workstations, control modules, HMIs, and similar equipment. It is safe, secure, and understandable, and most of it is hardwired. No one can get into this system from the outside unless you let them. No clouds here. You know where all the links are.

Now you have to connect this secure system to the outside, cloudy world, to IT systems such as supply chain management (SCM), planning, scheduling, modeling, ERP, MRP, WMS, CRM, and a host of other software described by three-letter acronyms (TLAs).

It's important to realize that it doesn't matter where these IT systems are located. They can be in the next room or around the world. And even if they are in the next room today, they might be on a server 6,000 miles away tomorrow. Just assume that all connections to IT go through the cloud, and don't worry about the physical connection.

Go Inside IT

IT systems, such as ERP or SCM, run on PCs, workstations, midrange computers, and mainframes. They run the gamut from UNIX to Microsoft operating systems, and from Sun to IBM processors.

In general, IT systems do not talk to your control system; instead, you talk to them. Your system supplies what they want when they want it, and it is usually a one-way street. As Jim Loar explains, it's because your system is real time and ERP is transactional.

"One problem in the integration is making the connection between two opposing philosophies and organizational goals," says Loar, engineering group leader at Ciba Specialty Chemicals, Newport, Del. "On the process control side, the goal is 100% uptime, 24/7, real-time, get the pounds out the door, and don't blow up the plant. On the other hand, the ERP side is defined transactions at discrete times, no activity during month-end close, centralized control, and financial accountability."

Figure 2: Build With XML

An HMI/SCADA or historian prepares an XML document by using an open-system encoding program to convert real-time data to XML according to a public document type definition (DTD). When the ERP system receives the XML document, it decodes the data according to the same DTD.

Another problem is in actually talking to these systems. In olden days, IT systems were completely independent, and shunned any semblance of being open. To work with SAP R/3, for example, your system had to send it IDOCs (interchange documents) that were defined for each type of application. Every ERP vendor had its own way of demanding information. The same was true of just about every other type of IT software.

The third problem is that most IT departments are a mess. Or, as Sean Baker, chief scientist at IONA (http://www.iona.com), puts it, "The majority of businesses today are in an extremely dis-integrated state. Years of piecemeal IT development and investment have led to a situation [where] there are numerous noncompatible systems." IONA is a broker software company that links systems that have been developed on different platforms using different languages. "Organizations have created numerous barriers within their own IT organizations," he says.

Integrating to all this IT software was a bear of a job. No wonder most of you threw up your hands and turned it over to the consultants and systems integrators. Today, however, it's a different story. Software vendors are beginning to realize that if they make their systems easier to work with, they might actually sell more systems. To put it another way, you'll buy the software that is the easiest to integrate. The vendors better make it easy, or you won't buy.

Enter XML and Web Services. These are the keys to making IT easier to interface. Take a moment to follow the explanation in the sidebar, "XML and Web Services," and the diagrams in Figures 2 and 3.

As you saw, XML is the language of Web Services. It is also the language that modern IT software is using to allow connections to the outside world. Even SAP, the 800-lb. gorilla of the ERP business, is converting its IDOCs to XML.

"SAP is introducing a .Net connector," says Gretchen Schwenezer, product manager at OSIsoft (http://www.osisoft.com). "They are also introducing Web Services for data exchange. Other vendors we are working with are also introducing the Web Services options."

In January, SAP dropped a bombshell when it announced that its NetWeaver software will be using XML, Web Services, and .Net technology. SAP is not alone--in fact, the company is a little late to the game, as most enterprise software vendors have already announced Web Services initiatives. What makes the SAP announcement important is that it is the biggest enterprise software vendor to make a commitment to pursuing Web Services.

Kapil Apshankar, author of Web Services Business Strategies and Architectures, explains that ERP has gone through three waves of development. "The first wave of ERP was the onset of computers in manufacturing. This was followed by a wave where specialized ERP applications began to emerge," says Apshankar. "Web Services-based ERP solutions constitute what can appropriately be termed the third wave in ERP." Apshankar says that Oracle, SAP, and PeopleSoft are the leaders in adopting Web Services.

But wait, there's more. Yes, there are alternatives to Microsoft's .Net solution, which is the way most people in our industry will make their connections to Web Services. But we won't be discussing them here. Pat Kennedy explains it best: "As always, there is a UNIX/Open Sources/Java alternative--J2EE--but it is primitive for development compared to Microsoft's .Net." To put it another way, we don't see any effort to bring J2EE into our business.

Schwenezer says no one should consider anything but Web Services. "The options are COM for the Microsoft guys and CORBA for the UNIX guys," she says. "Neither one can properly handle a firewall, and they will die."

We'll limit our discussion to .Net here, but be aware that there are several other ways to implement Web Services, including IBM's WebSphere, IONA's Orbix, and BEA's WebLogic. We rarely if ever see any of our process control vendors discussing such solutions, so we won't either.

Connect IT

So how do you make the actual connection to high-level IT systems? Mark Clark, ex-Rockwell enterprise architect and ERP specialist, explains that there are essentially three ways to bridge the gap: Do it yourself with OPC and Visual Basic software; purchase "broker" software; or adopt Web Services, most likely by using the .Net architecture.

Clark, now a consultant in Cedar Rapids, Iowa, says you can make the connection yourself, provided you have some programming skill on staff. "Writing Visual Basic and OPC code is not particularly difficult, but it does take knowledge and experience," says Clark. "You'll definitely need an experienced, highly skilled programmer or two, which can be expensive."

Figure 3: Send It Up

A process control system's .Net architecture and its web server handles the actual message transmission. The server makes a SOAP call to UDDI to obtain the address of the ERP system, and then sends the message via Port 80.

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:

* Application Software: This means a program that provides a specific function. For example, if you need statistical process control and reporting functions, then NWA (http://www.nwasoft.com) provides its Quality Analyst software. Blue Diamond Growers, Sacramento, Calif., uses Quality Analyst to acquire data from PLCs and a Wonderware HMI/SCADA system, perform statistical analyses, and make reports available to interested parties via its company intranet. No ERP is involved.

Iconics (http://www.iconics.com) offers ReportWorX.Net, which can produce the kinds of detailed reports that once required IT, MES, and ERP systems. ReportWorX uses .Net and XML technology, so it can provide web access, wireless communications, and interfaces to other .Net systems.

Many of the HMI/SCADA packages also provide connections to reach upward in the IT hierarchy. For example, InduSoft's (http://www.indusoft.com) Web Studio V 5.1 provides web-enabled SCADA and HMI systems that support .Net, Web Services, and XML. Any other modern HMI/SCADA system from Wonderware, Intellution, Iconics, or several others may provide the connection you need to reach IT software via Web Services.

With a little bit of programming experience and some of this application software, you can do wonders. "When historical data and report generation are concerned, we'll use an SQL-compliant report generation package, or write our own application using Visual Basic in Excel or Access," says Randy Geist, engineering manager at Technical Systems Inc. (http://www.TSIcontrols.com). "Data reduction and compaction are done in another SQL-compliant package." Who needs ERP?

* Historians: Every process control vendor has a historian package, which is simply a large database that stores everything that happens in real time. The most famous and long-lived is OSIsoft's PI package, which integrates with just about everything from 25-year-old legacy DCSs to the latest SAP NetWeaver.

Getting to ERP via a historian is a very popular method, it seems. "If our customer requests an ERP interface, we recommend OSI's RLink or a similar product," says systems integrator Phil Murray of Feedforward (http://www.feedforward.com). Mike Paulonis, technical associate at Eastman Chemical, Kingsport, Tenn., also uses RLink. "It is a much better choice in the long run to use a supported commercial product to make this connection," says Paulonis. "Eastman uses RLink, which provides a bidirectional connection between SAP and OSI's UDS universal data server."

Any of the other commercial historian packages can also provide an interface to IT software, because they all support XML, Web Services, SQL Server, and .Net.

Schwenezer says that OSI recently released PI-ICE, a server that provides PI with Web Services. "It was only released for six weeks in 2002, and sold nearly 1,800 seats," says Schwenezer, an indication that users are jumping on the Web Services bandwagon.

If you are having any doubts about ERP, this might be an excellent place to stop. "The ERP market is questionable," says Murray. "Scheduled 'go live' data are delayed by years. Plant personnel generally believe that they can manufacture and ship quality product on time without intervention, and they resist installation because of perceived misery with ERP."

It's quite possible you can obtain ERP-like reports without the agony, just by using suitable application software and a historian. If not, there are always frameworks systems.

Dem Bones

Frameworks are an "overarching architecture or framework to ease integration of plant floor and enterprise systems," we reported in a January feature "Framework Wars" [CONTROL"Jan. '03, p50]. "All of these frameworks use industry standards such as OPC, DNA for Manufacturing, and .Net." We also reported that many of you regard all this with great skepticism, and suspect that it is yet another way that process control vendors are trying to lock you into their proprietary boxes.

Chris Boothroyd, product manager at Honeywell, says such intervening software is necessary. "If production-level software and ERP software both support XML, then integration is simplified," says Boothroyd. "But unless both systems use exactly the same XML schema in exactly the same way, then something must still be used to interpret the messages between the two systems."

It is important to note here that XML schema, as defined in a DTD, is what makes the whole system work. When using XML to send data between two systems, both systems--by definition--must use the same schema in exactly the same way. One system tells the other which DTD is being used to encode the data, so the receiving system can use the same DTD to extract the data. There can be no mistakes. This is not a limitation of XML; instead, it may be its most redeeming feature, because the DTDs are public documents. They cannot be made proprietary.

Of course, we have not quite reached that stage yet, because XML schema are still developing. That means we might still need frameworks systems.

"An additional layer of software will sit between the control system and the ERP system," adds Boothroyd. "This might be as simple as a process historian or as complex as a full-blown MES. This layer of software becomes the focal point for ERP integration."

Here's a list of frameworks suppliers, and a synopsis of their offerings:

* Citect (http://www.citect.com): Its framework works with CitectSCADA software and Oracle databases, and uses .Net and XML to connect systems and SQL Server 2000 to access the database. Modules currently running on the .Net framework include Plant2Business Historian and Downtime Monitoring, an application that analyzes plant operations. Citect says that more .Net modules are in the pipeline. A framework system running at BHP Billiton's silver and lead mine in Queensland, Australia, uses all the software noted to monitor and analyze operations.

* Invensys/Foxboro (http://www.invensys.com): Invensys' framework is ArchestrA, and it includes Baan Protean ERP, I/A Series Batch Suite, .Net, SQL Server, XML, OPC servers, and Wonderware HMI/SCADA software. Invensys is a little unusual among control system vendors in that it has its own ERP system. The company enthusiastically embraced the new BatchML standard developed by the World Batch Forum and was able to demonstrate a working XML-based system based on its Baan ERP and an I/A Series DCS.

* Honeywell (http://www.acs.honeywell.com): Honeywell says XML, .Net, and Web Services are not enough to provide direct integration between plant floor systems and IT. Intervening software is needed. Therefore, Honeywell offers a range of software including Uniformance PHD, Business.Flex, OptiVision, and POMS, all of which can communicate with ERP systems via a "message-passing middleware approach." Honeywell says it uses elements of .Net, XML, and Web Services. For example, it uses XML to help integrate with Oracle systems.

* ABB (http://www.us.abb.com): ABB's Industrial IT framework is based on Microsoft technologies such as OPC, and is being updated to include XML, .Net, and Web Services. The services are based on the OPC XML DA specification, and will be made compliant as soon as OPC completes the spec. ABB also provides Web Services for data access and historians, all implemented under .Net.

* Emerson (http://www.emersonprocess.com): Emerson claims that it does not have a framework-type product. Instead, officials say Microsoft technologies are sufficient, so they have built XML, .Net, and Web Services into all their products. To support the exchange of information between its process automation systems and IT, Emerson offers PlantWeb Messenger, which is a XML/Web Services system. Emerson recently formed a partnership with Decision Management Intl. (http://www.dmius.com) to go after the FDA-regulated process industry. Both companies use the Microsoft .Net architecture, so it was easy to integrate DMI's web-based Regulus process manufacturing software with Emerson's DeltaV control systems, and with LIMS and ERP systems.

Get on the Edge

We said the third way for you to connect your control system to IT was via XML and Web Services. Just about every piece of new PC-based hardware or software you buy today will come with the Microsoft .Net architecture, so you get all the tools for XML and Web Services with it.

And, since almost everybody else in the software world is connecting everything via XML and Web Services, there is no reason why you shouldn't do the same. All you have to do is invoke Rule No. 3 (see sidebar, "Rules for Working With IT").

Unless, of course, you don't trust Microsoft. Or vendors in our industry.

"Be prepared for lots of people to say they are Web Services or .Net-compatible," warns Kennedy. "The vendors learn the buzzwords before the users."

Still, we are almost there with XML and Web Services:

* The standards-makers are coming up with XML schema that will work in a process plant. It's not all here yet, but it's coming, like a big freight train.

* XML schema is public, not proprietary, so you can't be tied up by a proprietary vendor system.

* IT vendors are opening up their software to allow XML and Web Services communications. SAP was the biggest holdout, but now it's on board. SAP made it legit.

* The software business has gotten a lot more competitive, and vendors are willing to bend over backward to land customers. You are in a perfect situation to demand concessions from vendors, so go for it.

Even if you are not ready to launch an integration project, you should prepare for the future:

* Only buy software that supports XML and Web Services.

* Only buy hardware that supports Ethernet communications.

* Don't buy anything that reeks of being a proprietary product. Stay open.

* Do it yourself (Rule No. 3).

XML and Web Services are the bleeding edge of technology, but they certainly are the wave of the future. Like the Windows operating system, Ethernet communications, objects, and fieldbus technology, to ignore XML and Web Services at this stage would be foolish. Sure, there are more tried, true, and reliable older solutions today, but Web Services is the future. Avoid using it at your peril.

XML and Web Services

All data is encoded in some way. Standard text and numbers have been encoded in ASCII for years. In recent times, the computer wizards created markup languages such as HTML and XML.

In general, HTML describes how information is rendered; XML describes what it is and how it is used. If you have ever designed a web page, you've worked in HTML, which defines fonts, type sizes, and format. For example, PV1 = says that "PV1" will be printed in 10 pt. Book Antiqua. If a document containing this HTML code is retrieved by any web browser, it will be displayed in the proper font and type size.

XML, on the other hand, defines what the variable is; for example, flow>PV1. Any compatible software program receiving this variable will know, from the XML code, that it is a flow variable. Other XML definitions will provide units of measurement, date of last calibration, time the measurement was taken, and so on. Be advised that all these definitions are still in the works.

Here's an example of XML as defined by the World Batch Forum's schema (see sidebar, "Is XML Ready for Prime Time?"):

Schema definition:

Don't worry, you don't have to encode it. Software programs do that for you (see below). Once a data file is encoded in XML, it becomes a document. A DTD (document type definition) describes its contents, such as the XML version of SAP's NetWeaver system. Most likely,