Surviving the discussion

Members of the control community are often involved in laboured and frustrating discussions centred on ways in which control and execution systems integrate into the ERP layer.

A simple way to look at how the manufacturing industries run, is to rationalise operations into two layers. Any form of IT above the control system can be regarded as enterprise resource planning (ERP) while the control system itself can be described as its own layer. In real life there may be an interposing manufacturing execution system (MES) but from the perspective of the control community a simple model can be useful.

The sprawling beast, which is the ERP layer of manufacturing operations, has emerged over the past few years to dominate the ways in which many organisations operate. The ERP layer essentially looks after accounting. It doesn’t make anything but provides information to enable decisions and the necessary transactions to be made.

A transaction-based environment is one where information is passed around to reflect activity in the enterprise. This is what enterprises do – money moves out, stock moves in. Work is expended, value is added, finished goods are produced, and buyers pay for them. All of these are transactions.

The control and execution layer makes things, implements decisions and produces samples not transactions. In the simple two-layer model, ERP provides cost data about the enterprise as a whole while control and execution actually produces the goods to be sold. One very important distinction between the two is that ERP straddles the enterprise. The control and execution layer in this example is fine but it must be remembered that there will almost certainly be several execution systems within one enterprise – each doing different things in different ways.

There are one or two things that integration is not. It does not link systems like SAP to control solutions such as DeltaV. Neither does it link distributed control systems (DCS) to Baan nor does it connect plant devices with ERP via ethernet networks. Integration will not publishing process data on the site intranet or provide digital communications from the CEO’s office to the field device. All these may be signs that there is integration but such signs, although interesting, are not integration in themselves.

Integration is all about providing data to those who need it and building information from data, accepting and disseminating information and taking information from ERP and making it into to data usable by Execution. In a nutshell integration is the sharing of appropriate information with other systems outside the process automation system.

Integration is not a new idea. Control and instrumentation vendors have been selling open systems for years. These days, the enabling IT is available at a palatable price and affords sufficient usable power to implement an integration project in useful time scales. So it should be easy now we have super-powerful PCs, and networks?

Sadly. it’s not that easy. If it was, everyone would have done it ages ago. It’s hard because it’s hard to decide just exactly what information needs to be passed between the layers.

Current generation IT makes the journey possible but it doesn’t help the user decide which pieces of information need to be shared. How many pieces of information does the control system hold and how are data, recipes, set points and all the process variables configured?

In the ERP layer, data represent salaries, raw material costs, exchange rates as well as tax and duty rates. Which elements of this data is needed down in the control world? Just thinking about these two types of information for a few moments should spark the realisation that there are an effectively infinite number of possibilities.

An integration project will need to identify which pieces need of data to be shared and how. It’s not about technology, it’s about information or, more to the point, decisions about information.

Once the requirements specification has been written and agreed, the user is in reasonable shape to survive what could be termed the Integration Minefield. However, watch out for data required by the enterprise, which are not available in the plant control system. Additionally, the enterprise layer may expect value to be added by plant personnel but doesn’t understand this process.

For example, ERP may ask for 250 litres of product. ERP has only the vaguest understanding of what goes on in the execution world, so doesn’t appreciate that the product is made in batches of 80 litres.

Two options are to make 4 x 80 = 240 litres or 4 x 80 + 1 x 10 litres? Somebody or something must decide. At the moment, this value is added by the plant manager. For a high level of integration, a rule-set has to sit in the interface or the decision presented to a human.

Other points to consider are that the ERP layer thinks in a different way, data needed to make the product may not be available or packages could contain the data but in an incompatible format is incompatible. It is also likely that the ERP layer has different time horizons and will normally be slower than the control layer.

During the integration journey, all these problems will arise. To succeed, the installer will need to articulate the workings of the control world to beings who may seem as though they are from other planets – IT professionals.

IT has a different culture to control engineering. IT specialists use different language and inhabit a radically different environment. They bring many things to the integration project such as IT skills and technology, understanding of the ERP layer and, most importantly, funding.

The IT professionals who develop, purchase and maintain business systems come from an entirely different viewpoint to the engineers who develop, purchase and maintain the control systems.

Also, they do not share common terminology, their viewpoints are different & they do not share critical success factors.

Remember, it’s their money and their world. You need to play the game their way to make a success of the project.

As a final tip, make yourself buzzword compliant. Get on board with IT terminology: such as XML, Hub, Switch, Router, Privilege, Account, Share, Trust, Domain, NT. Don’t try to do the IT guys’ jobs but at least understand their language.

The integration minefield will be a tough journey but the benefits can be enormous to the enterprise and to the professional satisfaction of the installer. This brief look at some of the challenges will be useful to those in the control community who face integration, and that’s all of you because integration is coming.

Maybe your organisation has no plans to integrate. If so then beware as there are other enterprises with greater ambition who will overcome the obstacles to become leaner and meaner than you. Not everyone will survive!

Nick Taylor is with Emerson Process Management (formerly Fisher-Rosemount), Leicester.