Business Accent

Integrating PLC with SAP R/3

The role of IT professionals has changed. They are asked to deliver a ‘Measurable operational advantage,’ say H Krishnan (above) and D R Mote of Rajashree Cements in the first part of a two-part series

In most organisations, with increasing user awareness (thanks to the Internet and e-mail), expectations from IT harden into demands, and are laced with an urgency to get business advantages. The role of IT professionals has thus changed. From order-takers for ‘Reports’ or ‘Computerisation of systems,’ they are asked to deliver a ‘Measurable operational advantage.’

At Rajashree Cements, we faced a similar situation in 2003. After implementing and stabilising an ERP (which provided a system for transaction processing and capturing operational data), we were thinking, what next? BW (Business Warehousing), SCM or CRM?

As ours was purely a manufacturing set up, with no direct transaction with end-customers, we didn’t find much use for CRM. Because 90 percent of our raw material was available in our captive mines and the rest was also mined as a natural resource, there was not much of supply chaining involved. Also, since most of the data that was captured was process-oriented, we could not see immediate business benefits other than process optimisation, which looked more complex.

The instrumentation and MIS departments teamed up and decided to look at the business sub-processes of production reporting.

Being a highly-automated, continuous process plant, and having a DCS system for process monitoring and control, all the operational information was available to the control room operators via proprietary software. However, it was noted that the data needed for a daily production report was being printed from the PLC system software, and re-entered as data in the process instruction (PI sheet) module of SAP. This activity did not add value, and therefore needed to be minimised if not eliminated. It was causing a delay in making the daily report, not to mention errors of data entry, missing data and so on.

So what is the big deal, one may wonder? Why not connect one computer to another? That was what we also thought. However, when we got down to earth, the problems surfaced.

We had three DCS systems for the three streams of production—ABB-2 systems (one 20 years old, another 10 years old) and Allen Bradley (5 years old). Each of these systems had different levels of upgradation (versions) and protocols for communication in their own data bus. The systems had proprietary interfaces (hardware and software) to third-party systems. In many cases, these tags captured only instantaneous value. For a 24-hour value (such as a day’s production, power consumption, etc), another theoretical tag had to programmed.

There was some add-on software (for instance, Advant for ABB) for collecting and displaying critical production parameters in the Excel format. However, the software had to be run once a day to collect and store data in a file, which would be overwritten the next day (unless copied elsewhere) and was OEM-specific.

Data entry was done during the general shift (starting at 8 am). However, data is collected as of 6 am (when the night shift ends) since it had to be manually checked.

Lastly, none of these DCS systems could talk directly to SAP for uploading data, due to communication protocol issues and SAP data formats and structures.

After detailed analysis, we concluded that the software we wanted (and which could communicate with the DCS system), was available on the Windows Server. This software could communicate directly with the SAP R/3 PP-PI module using SAP’s standard connectors; it could also store data temporarily in its own database (MS SQL, Access, Oracle, etc) for editing.

From the available software products, we realised that we had to install a communication protocol software that could communicate with different DCS systems using standard gateways provided by the OEM suppliers. It had to have the facility to identify and map each piece of data (temperature, output rate, feed rate, etc) with the corresponding instrument tag values. It had to be able to convert measured reading into data value using conversion factors. Further, this data had to be dumped into temporary files or a database for proper identification.

Another software that could collect data from the temporary file format, communicate with SAP, and then upload the data was also required.

Identifying software

For the first software requirement we identified Matrikon (developed by Matrikon Corp) for communicating with ABB’s PLC system, RSLinx gateway for an OPC client (for Allen Bradley PLCs). For the second requirement, the application software for integration with SAP was SLINK incorporating a version of VRTF (Versant Real Time Framework).

The client software of SLINK was configured on a client PC with two network cards that were kept in the control room. One of these network cards was connected to the DCS network and the other to the data network (which included a SLINK server and a SAP system.) To enable data to be read from PLC of ABB, a communication software (Matrikon in case of ABB systems) was configured. The Matrikon software provided the OPC interface between ABB–PLC through a GCOM interface card (H/W).

Deploying the solution

The server portion of SLINK was loaded on a separate server (in an optical fibre LAN in the IT department half a kilometre away) in which two agents (services) were configured. The first was an ODBC agent to store and retrieve data from a local database (MS SQL in our case). The second was a SAP agent to generate process messages as per PP-PI module format from the data collected from the client PC. An application was developed (ASP) for entering additional data not captured by PLC (stoppages, reasons for stoppages, etc) and sending the same as a process message to the SAP server.

Step by step

The steps involved in the implementation are:

1. Identifying data required for the daily production report.

2. Identifying which data was polled and stored in the PLC system. Some were available as totalised tags predefined in the PLC system. In some cases, they had to be created and totalised for the day’s value.

3. Mapping these tag numbers to the fields in the temporary database.

4. Developing the RFC in SAP which could collect data in a process message format for further processing in SAP.

5. Setting up and configuring SQL agent to pick up data from PLC and dump it into an SQL database.

6. Setting up a SAP agent to push data from SQL database to SAP tables.

7. Developing an application interface to:

• Download process recipe from SAP once a month or as and when there is a change.
• Develop a data-entry screen to display data from PLC temporarily stored in a database, for users to edit and enter additional data that is not collected by the instruments (stoppages, reasons for stoppage, etc).

8. Saving and sending data to SAP.

The project took nearly 12 months to complete, mainly because the interfacing with different systems required different drivers of different versions. Subsequently, user interface for data entry had to be made as simple and convenient as they were used to on the SAP screen. The collisions in the network had to be ironed out before adjusting the polling rate. The system was initiated in April 2003 and installed in Feb 2004; it went live in April 2004.

Note: This system was implemented for two streams of production. We deferred implementation of the third stream awaiting PLC upgradation.

H Krishnan is IT Head, and D R Mote is Head, Instrumentation, at Rajashree Cements