How to Integrate Software

Automation software integration within and among manufacturing sites is becoming more challenging with the increasing mergers, acquisitions, and ties from control into the rest of the enterprise.System integrators accustomed to working with software offer advice on moving from plant-floor to enterprise-wide integration across sites and through the supply-chain.

By Mark T. Hoske, CONTROL ENGINEERING November 1, 2000
  • Software and information integration

  • System integration

  • Human-machine interface software

  • Standards and regulations

  • Enterprise resource planning (ERP)

System integrators see movement toward standards, data integration, IT involvement
Define scope of software integration

Automation software integration within and among manufacturing sites is becoming more challenging with the increasing mergers, acquisitions, and ties from control into the rest of the enterprise.

System integrators accustomed to working with software offer advice on moving from plant-floor to enterprise-wide integration across sites and through the supply-chain.

Multi-site software integration can mean a catalog of different PLCs, control programs, databases, HMIs (human-machine interfaces), design philosophies (in-house vs. out-source), engineering talent available, design standards, version control, documentation (or lack thereof), and technical skill levels, according to Ray Burkholder, president of Burkholder & Associates Inc. (Kitchener, Ontario, Canada). Software integration can also involve wide-area data access, sharing, and control, including network design, reliability, redundancy, bandwidth control, security, and accessibility, he says.

Making it work

Robert Mah, applications consultant, RM Systems Integrators (Toronto, Ontario, Canada), says, “The key is being able to roll the data into a uniform format for head office reporting. Usually this requires standardizing on a database, such as Oracle or SQL Server, and having the system populate it.” Most HMI/control software can handle this. There’s little to gain, after an acquisition, in trying to retrofit equipment with PLCs, controls or SCADA (supervisory control and data acquisition) systems, since there is already local support for the existing systems. “The acquirer is more interested in maintaining production/profit than refitting machines,” Mr. Mah says.

Maintain close relations among integrators, their customers, and original equipment manufacturers, recommends Tony Kaczmarek, president, Kors Engineering (Waterford, Mich.). “This three-way interaction, among developer, customer, and producer helps assure data and product integrity,” he says.

Training, expertise

Gordon Kilgore, vp operations, VAI Automation Inc. (Barton Harbor, Mich.), says customers should “Take advantage of whatever training is available for the specific products to be integrated. Have suppliers provide on-site support to answer questions while planning the work and designing solutions.” Experience counts in design reviews and for deciding what technical staff remains after mergers and acquisitions. Who stays should depend on “who has experience with what systems, rather than any other criteria,” Mr. Kilgore says.

Mark W. Gietz, chief engineer, Programmable Control Services Inc. (PCS, Spokane, Wa.), advises that those doing the integration should “plan and completely lay out the work tasks, considering the complexity introduced in integrating and migrating multi-platform systems. Integrators should also assess risks and communicate frequently with the customer on progress and projections.”

Standards ease integration

Jeff Baxter, senior systems engineer, Progressive Software Solutions (Albany, Ore.), says means of data transfer among types of software depends on the “level.” For “serious” business information transfers, ODBC (Open Database Compliant) and ActiveX are most common. Proprietary formats are still frequently encountered; it is surprising how many “higher” level systems still use fairly primitive mechanisms, such as text file transfers.

OPC (OLE, object linking and embedding, for process control) is gaining ground, he says, but this is seen largely at the “device connection” level (such as field-device communications); many vendors continue to rely heavily on existing drivers using DDE (dynamic data exchange) or other proprietary connections.

Mr. Kilgore says he expects use of custom code to decrease and use of XML (eXtensible Markup Language) to increase, due to its ability to more easily reuse and upgrade code.

In working HMI and plant-floor systems, Mr. Baxter says, “most vendors we see continue to use a proprietary protocol as their primary connection. Most claim to support ‘open’ protocols, especially OPC, but the majority of installed systems we see are still implemented around proprietary protocols. We continue to see performance issues around OPC because it operates significantly slower than proprietary protocols.”

Even with increasing use of Microsoft Windows, continues Mr. Baxter, “Without a doubt, the most common solution for plant-floor automation remains proprietary solutions,” such as PLCs or DCSs (distributed control systems). For applications such as HMI, SCADA, and Plant Information Systems, Windows is the operating system (OS). Windows NT is dominant, but migration has begun toward Windows 2000, Mr. Baxter and others agree.

While PC-based control will expand, mostly with Microsoft OSs, “We also believe that use of proprietary solutions will continue to dominate automation for the immediate future,” Mr. Baxter says, because proprietary solutions are “still perceived as less expensive and often less risky.”

Mr. Mah adds that Linux and Windows CE are on the rise, but still in a comparatively tentative, trial stage. Mr. Kaczmarek, Kors Engineering, observes a trend toward products with built-in web servers. Windows CE, he adds, should make a “strong presence in industrial products very soon.”

Mr. Mah expects more IT (information technology) department input over time, but cautioned that, at present, “IT usually is busy putting out its own fires, rather than performing any strategic planning or standards setting/policing.” Mr. Kilgore sees IT staff being assigned to controls people in the factory.

IT, manufacturing, and engineering personnel usually respect each other’s areas of expertise, says Mr. Gietz of PCS, anticipating “an increase in coordination between the two for data integration.”

Mr. Baxter of Progressive Software Solutions, says original equipment manufacturers are still conservative, but may have a role to play by using PC-based control and initiating end-users’ exposure to nonproprietary systems. Larger customers often have very strict facility standards for logic hardware; most allow just one vendor. Mergers “force them to support different hardware and software platforms…PLCs, PCs, HMI/OI [operator interface], MES [manufacturing execution systems], and ERP [enterprise resource planning] systems.”

Many factories buy equipment that comes with its own controls (both new and used), points out Mr. Mah of RM Systems Integrators. Consequently, although a plant may have a standard, buyers will buckle if requesting a specific PLC impacts the cost or delivery of the equipment.

U.S. regulatory requirements can dampen enterprise and supply-chain integration for pharmaceutical customers, suggests Mr. Kilgore, VAI Automation. Many industries’ specialty instrumentation requirements can inhibit integration, says Mr. Mah: “Specialty displays/controllers generally lack any communications, other than a plain RS-232C serial port, so custom drivers are written, or in some cases analog inputs must be fed to a PLC.”

More integration

With software vendors touting the benefits of industry standards, says Mr. Baxter, “We have seen a significant increase in the amount of software-related integration that we are asked to perform, including integration to MRP [manufacturing resource planning] and ERP systems. Most integration is accomplished using industry-standard means such as ODBC, SQL [Structured Query Language], etc. ‘Out-of-the-box’ interoperability still revolves around the support of basic ‘computer industry’ standards such as ODBC, file transfer, etc.”

A recent implementation allows operator-level access to information in the corporate database, with distributed client-based view of the HMI, according to Mr. Gietz of PCS. It involved a two-staged multi-operator control scheme allowing a remote operator to assert a right to override control.

Despite bright spots, the ideal of full plant-floor, enterprise, and supply-chain integration is a long way from reality. Mr. Baxter, Progressive Software Solutions, says, “Integration varies widely among our customers…the ‘average’ customer we see has far more integration on the plant floor than they do at the supply- chain end. We still see very large gaps between the plant floor and the business-level systems.”

System integrators see movement toward standards, data integration, IT involvement

Replies from seven integrators reflect some clear trends in software integration, including use of Microsoft operating systems and conventions, expectation of more cooperation with IT, and an increasing amount of software integration work.

How are data most often transferred? Available drivers, OPC, ODBC, ActiveX “wrappers” were most common, with HTML and custom code close behind.

Operating systems most commonly used for automation and controls-related applications: Microsoft Windows NT was the clear winner. Within five years, many see continued strength of NT, with some movement to Windows 2000 (compatible with NT 4.0, with more features), Windows CE, and NT with RTX. (For more on operating systems, see Control Engineering’s September 2000 cover story.)

The number of vendors’ logic hardware (PLC, PCs, and embedded systems) at a single site varied widely from a few to eight or more, depending on facility standards and number of acquisitions that foisted multiple platforms onto the organization.

Just more than half of decisions about automation, controls, and instrumentation software configuration and integration involve IT personnel; most integrators expect the level of involvement to increase over time, depending on the complexity and level of the project.

Extent of information integration, connectivity, and data transfer was highest from the sensor to the plant-floor system; less across departments within a site; and least across the supply chain, linking customers and suppliers.

Despite (or perhaps because of higher expectations related to) software vendors’ claims of interoperability and plug-and-play functionality, integrators’ software-related business increased from 30% to 90% over three years, the respondents say. Most expect the push for connectivity to continue.

Broad expertise among the seven integrators touch all 37 categories of software and eight areas of PLC software listed in the Control Engineering Buyer’s Guide, at

Finally, five of seven did the most work at customers with 1,000 or more employees, most at facilities with continuous or batch processing, but also with discrete products manufacturing. The questions were asked of 18 system integrators via e-mail in September 2000.

Define scope of software integration

Successful automation and information system implementations don’t just happen, says Jeff Baxter, senior systems engineer, Progressive Software Solutions (Albany, Ore.). They result from good planning, good communications, and consistent effort. Those implementing software projects need to solidify scope, leadership, resources, and management commitment. (For expanded details, read this article online at

Project scope with stated objectives —This remains most important. Spending money without a clear definition of scope and deliverables is like constructing a building without drawings! An automation or system audit determines specific system requirements and deliverables, resulting in a firm, fixed price for the implementation.

Consistent project sponsorship/leadership —Understand project significance for the organization and ensure that project sponsorship and leadership are there for project duration. Having an informed and supportive sponsor is an absolute key. Make sure the sponsor understands the significance and scope of the undertaking and its potential impact (positive or negative) on the organization.

Resource allocation —Make sure required internal resources are available or available for hire. Internal resources must understand the significance of the project and give it the appropriate priority. Importance increases as project scope broadens.

Management Support —This is the glue that makes successful projects. If project sponsors can fall back to informed decision makers and know that they will get required support, then the likelihood of a successful project goes way up. Informed management support helps resolve conflicts, and dramatically increases odds of a successful implementation by guiding and helping prioritize as required.