Monitoring Interface for PLC Programs

Operating Principle

By using KEPServerEX to communicate with a PLC, WorkSense™ is able to retrieve the currently-defined tags in the device and subscribe to any updates in the tag values. Because each PLC program is unique, it is always up to the programmer to decide which tags have semantic meaning for process monitoring. Thus, configuring a PLC program for WorkSense™ process monitoring requires the following steps:

1. Modify the PLC program to support the required process monitoring tags.
2. Connect the PLC to the KEPServerEX machine via a secure plant floor LAN.
3. Configure the PLC as a device in KEPServerEX.
4. The WorkSense™ Connector will automatically detect the new device in KEPServerEX and receive the tag list from the PLC.
5. Configure the associated process in WorkSense™ for monitoring by assigning the appropriate semantic meaning to each required process monitoring tag.

Required Tags for Process Monitoring

The following tags should be implemented in the PLC program to support OEE/TEEP metrics.

Up/Down Status Bit

An up/down status is the basic requirement for determining if a process is available or not. This is most easily implemented as a memory bit that is enabled whenever the process is running in automatic mode and no errors are present. Most PLC programs already maintain such a bit, so it is natural to take advantage of it.

Status Byte with Downtime Reason

As an alternative to the simple up/down status bit, a byte can be used to encode both the current up/down state of the process as well as a single current downtime reason. The advantage of this approach over using separate bits for each downtime reason* is maintainability, since additional downtime reasons can be encoded in the PLC program as additional values of the status byte.

It is recommended that the following standard values be used in addition to any application-specific downtime reasons:

*Bitwise encoding of multiple (potentially simultaneous) downtime reasons may be supported in a future WorkSense™ update.

Cycles-Started Counter (Byte or Half-Word)

While it is more natural from an observer’s standpoint to think in terms of good parts and bad parts produced, the nature of a PLC program is such that it is not always easy to determine when a bad part is "produced." For example, a misaligned part may stall a process halfway through and need to be removed before continuing. In this case any bad-part sensor may not be triggered. Thus, the recommended practice for OEE quality monitoring is to count the total number of started parts instead. Further, because WorkSense™ process designs already incorporate the number of parts produced per cycle, the PLC program only needs to count the number of cycles that have been started.

A byte is usually not sufficient for counting cycles even in a single shift or working day. However, the value of the counter itself is irrelevant when integrating with a supervisory system like WorkSense™. WorkSense™ performs a delta analysis to determine when the cycles-started counter is incremented, and calculates OEE metrics based only on the positive increments over time. Since the width of the tag, in bits, is known to WorkSense™ (via the KEPServerEX interface), counter overflows are not a problem.

Yet, in cases where the connection between KEPServerEX and the PLC is unreliable, for example when connecting over a 3G network or in the face of potential server outages, it may be helpful to provide some additional buffer so that any overflows are not missed between successive scans by KEPServerEX. In this case a half-word (or in extreme cases a full word) may be used instead of a byte. The choice makes no difference to the performance of WorkSense™, but memory constraints on the PLC may limit your options.

Good Parts Counter (Byte or Half-Word)

This counter operates on the same overflow-agnostic principle as the cycles-started counter. It should be incremented whenever a good part is ultimately produced by the process. This also means that if a process produces more than one part per cycle, the good parts counter needs to be incremented by the appropriate amount. For example, an assembly line that produces parts in sets of four would need to increment the good parts counter by four each cycle. This allows calculation of scrap percentages and quality metrics.

(Optional) Scrap Reason Counters

While not required, the programmer can optionally maintain a separate counter for each scrap reason that the process is able to determine automatically. This can be a valuable enhancement in analyzing process characteristics, creating Pareto charts, and correlating process variables. WorkSense™ supports manual updating of scrap counters as a fallback.

(Optional) Rework/First-Time-Through Counters

Some processes support rework of certain scrap parts. In these cases, to maintain accurate data, it is best to track the rework as a separate process. This can be done by maintaining a separate Rework Parts-Started counter and a corresponding Rework Good Parts counter. The status bit/byte applies to any process currently running on the associated equipment, so it does not need to be duplicated.