AllenWeb


SAP R/3 Implementation Concerns



 Jun 98


Business Process/Industrial Process Integration*


Integrating plant operations with SAP R/3

Most manufacturing enterprises can be "mapped" as a five-tier model that includes - from the top down - business systems, production planning, operations management, process control, and the processes themselves.  Different types of software systems serve at each tier, and vendor's supply software that integrates information throughout the enterprise.

One such software system is R/3 from SAP.  The functionality supplied by R/3 covers the top business tier and also functions within the next two layers.  R/3 has been classified as an enterprise resources planning (ERP) product, but it is more, and it appears that SAP has even grande aspirations for R/3 in the years to come.

SAP offers a modular family of software packages that covers financials, human resources, quality, maintenance, production planning, and more.  While an integrated system is a great advantage to management, it has the disadvantage of requiring extensive engineering and implementation efforts.  Many companies (mostly well-known consultants) have formed divisions or subsidiaries to support these efforts, which can cost millions of dollars.

Integrating plant operations with the SAP R/3 ERP system is a particularly challenging project, and there are different ways of approaching the implementation.


The PP-PI Interface

SAP provides several modules that link to different elements of the enterprise operations.  The module for production planning is called PP-PI (Production Planning for the Process Industry). PP-PI provides two-way communication between R/3 and the next lower layer, operations management, using a library of Remote Function Calls (RFC's).

PP-PI performs two basic functions: it enables the download of control recipes to lower-level control systems, and the upload of process-related data to the form of process messages.

In the control recipe, the following data is transferred: process and control parameters; text with instructions for operators of manually operated lines; and information relating to the process messages that are to be returned.  Process messages returning to PP-PI supply information on:

In essence, PP-PI allows R/3 to generate instructions for production and download these instructions at scheduled intervals for execution.  It also allows the results of execution to be transmitted back to R/3 to keep track of inventory levels, production status, etc., and to capture unplanned events, such as process shutdowns.  While this overall scheme can be used for both batch and continuous processing, the design of the system is weighted toward the batch environment.


Connectivity Alternatives

There are three ways in which PP-PI has been connected to the process control system:

In one early application of PP-PI to a batch process, the computer was limited to issuing instructions - via a computer terminal - for human operators to follow.  The instructions included what to do and what information to collect for PP-PI.  For example, PP=PI might instruct the operator to add given amounts of certain materials to a mixer, stir for 45 minutes, and record temperatures a five-minute intervals.  The operator would collect the requested information and use the computer keyboard to enter it after the process was complete.

There are several disadvantages to this approach:  1) manual data entries are subject to errors;  2) process data collected by operators are not easily shared through the system; and 3) this approach can only be used for manually operated batch processes.  It has little or no applicability to continuous process or to processes controlled by distributed control systems (DCS's or PLC's).

Middleware messaging systems solve one of the problems of the indirect connection.  They eliminate manually entered data by electronically linking to process control systems.  They also promise to provide the capability to have multiple process connections to one PP-PI connection.  For example, a single middleware system could connect PP-PI to a laboratory information system (LIMS) and to multiple DCSs, eliminating the need for a separate PP-PI connection to each of these process level systems.

By themselves, however, middleware messaging systems are not able to disseminate process data from one process to other process information systems throughout the plant.  They only provide the messaging service between each process and PP-PI.  They likewise do not validate or condition the data from the process and may not even buffer the information passing from PP-PI to the process.

A PIMS not only acts as a connecting layer between process control and PP-PI, providing the messaging services of the middleware mentioned above, it also provides the other services listed as deficiencies of indirect and middleware connections.  With the proper extensions, a PIMS offers the most comprehensive and ultimately useful approach.


Process Information Management

Using a PIMS, there are three functional layers to the total enterprise model:  1) ERP, the SAP R/3 business server, which provides non-real-time data at the management level; 2) information management: the PIMS, which manages the process of transforming second-to-second real-time process data into useful business information, ensuring the reliability, accuracy and consistency of the data; and 3) process control: the control system server (PLC, DCS), which manages the operation of the process equipment.

The job of the information management layer is first to pass information back and forth between the ERP layer above it and the process layer beneath it and second, to enable the ERP system to achieve optimum performance.  Accomplishing the second objective in not trivial, and it is here where a PIMS (with the proper extensions) can provide much more that with either the indirect or middleware message systems.

When the PIMS is providing complete functional capability, its tasks are to:

  1. Provide a global connection of the ERP layer.  This task is similar to the basic work of a messaging system; i.e., translating information that is flowing between PP-PI and the process controller.  By providing a common platform, the PIMS can connect multiple process control systems, as well as a LIMS, to one PP-PI, simplifying the overall network architecture and providing standard interfaces.  Because a single PIMS server can encompass all of the processes that are part of an entire manufacturing operation, and because the PIMS has considerable processing "smarts," it can pass a global view of the process up to PP-PI, something that may be difficult for a messaging system.
    The global connection provided by PIMS extends the same network that connects PP-PI and the PIMS to other users of process information throughout the plant.  These users at their desktops then can visualize process data using tools provided by the PIMS and also can import the data into their favorite desktop spreadsheets or databases.
  2. Support ERP message needs.  PP-PI messages contain recipes to be made, tests to be performed and actual results achieved, such as the amount of material made, its characteristics, peak temperatures during manufacturing, laboratory quality assays, and SPC charts.  These messages must be both buffered and converted to a meaningful format for the process control layer.
    Buffering acts to synchronize the transactional nature of information at the business layer with the real-time nature of information within the process control layer.  Buffering also manages timing differences between the business and process control layers.  For example, PP-PI can pass a group of recipes for weekend manufacturer, and the buffering function within the PIMS message layer can distribute the recipes to the process control system as needed during the weekend.
    Message conversion includes matching data elements between the business layer and the process control layer, since the business layer and the process control layer do not generally speak the same language.  What the business layer calls a particular data element rarely will be the same name used by the process control layer.  These differences can be rationalized by data element mapping within the message layer of the PIMS.
  3. Convert and reconcile process data.   Another conversion function performed in the PIMS is unit conversion, which can be more complex than simply converting metric tons to kilograms.  For example, the business layer typically uses weight while the process control layer typically measures flow. The PIMS must handle the requisite conversion based on process parameters.
    Even more important, the PIMS verifies that the data being passed up to SAP make sense:  a middleware messaging system, on the other hand, simply translates the data and passes it on without regard to integrity.  A PIMS looks at the data logically; for example, does the quantity produced equal the sum of the quantities put into the process?  Is the average reaction temperature within the correct range for SPC temperature data?  Is the production time appropriate?
    Answering questions like these is absolutely crucial to the functioning of SAP, which relies on the validity and accuracy of the data it gets.  An error inadvertently passed up to SAP can be perpetuated within the company at an alarming and potentially devastating rate.
  4. Monitor real-time events.  The PIMS must pick up information in real-time and convert it to a meaningful transactional format for SAP.  PP-PI does not keep track of time.  It identifies a transaction that it wants to happen and the results that it wants back when the transaction is complete.  The PIMS must capture the beginning and end of every transaction and synchronize transactions with real-time events.  Int the case of continuous processes, the PIMS must also translate an ongoing process into discrete and measurable events, viewing the continuous process as a sequence of timed transactions that are tightly linked, each one occurring immediately after the previous one is completed.
  5. Track available resources.  PP-PI provides a certain level of scheduling based on the order in which it passes recipes down to the process control system.  However, PP-PI does not track resource availability - so if a recipe requires certain equipment that is currently occupied, executing the recipe mus be held up until the equipment is available.
    A PIMS can provide information on equipment availability to either PP-PI or another scheduling system outside of SAP, making it a valuable resource optimization tool.
  6. Deliver product genealogy and material tracking.  When problems occur in a manufacturing process or questions arise regarding the quality of a delivered order, the genealogy of the product or raw material is of great importance.  The PIMS can trace the path to find out what may have caused the problem.  A  PIMS also can trace material forward to tag downstream products that might be impacted by the defective material.  The capability to chain backward and forward along a manufacturing path is critical to the FDA and other standards organizations, and it is a job that is difficult for both SAP and messaging systems.
  7. Provide data visualization and SPC/SQC charting.  Critical decisions in troubleshooting and improving processes depend on knowing the cause-and-effect relationships within the process.  The PIMS provides the computerized visualization and analysis tools to enable operators and engineers to make these critical decisions.  Currently, these tools work against data sets within the PIMS; in the future either may be able to work against model data.  This capability is not available form the middleware messaging and the indirect
    connect systems.
    The PIMS also tells operators whether or not the process is in control through the SQC/SPC charts it displays.  The control limits could be supplied from the DRP layer and the violations could be passed back to the DRP layer, although this is not currently supported in the software.  At present, both control limits and violations are handled by the PIMS, which makes this information available to operators and process engineers through the same visualization tools mentioned above.
  8. Enable advanced process control and process optimization.  Control of manufacturing processes using conventional single-loop controllers provides adequate control in most cases.  However, achieving the highest level of performance with the least product variability and at the least cost requires multivariable control and optimization based on models.  The computing power of the PIMS can provide the necessary platform for this advanced technology.


Server or Desktop?

Another critical issue is involved at the layer between the ERP and process control: should the functions described above be performed at the server level or PIMS or at the desktop?  While certain functions within the operation of a manufacturing process belong to the desktop, there are other functions that are better done at the server level.  Simple visualization and ad hoc analysis belong at the desktop, amenable to the power of OLE, ODBC, and the Microsoft Windows 95 and NT platforms.  And although process data gathered and reconciled by the PIMS can be manipulated by various desktop tools, it makes more sense to handle it within the PIMS server.  That requires that PIMS has some extra :smarts" built into it, that it become an Intelligent Process Data Server (IPDS).


Functions that should be performed by an IPDS at the server level are best identified by examining the problems associated with doing them at the desktop.

Without an IPDS, a key link in the closed-loop information cycle that links SAP to the process control level is at risk.  Desktop technology is appropriate for certain tasks, but the actual two-way transfer of data between the ERP layer and the process layer requires a secure, reliable, accurate, and intelligent interface mechanism.


The Scope of the Problem

The architecture considerations presented here are, of course, only part of the job in determining what kind of system to implement as the interface between the ERP and process control layers.   In addition to supporting a PIMS architecture that will protect and maintain the data, a vendor should be able to provide answers to other important questions:

With a good architectural approach and an experienced vendor, new ERP tools of the type offered by SAP can redefine the manufacturing and chemical processing industries of the future.  Such integrated systems soon may be a requirement for remaining competitive in the 21st Century.

- END -