OEE and Production Monitoring Straight from Your PLCs

A useful monitoring system answers four questions for every line at any moment: is it running, how fast, what is it making and, if it is stopped, why. Everything else, including OEE, is built from those answers.

• Line and machine state: running, stopped, starved, blocked, in changeover or in cleaning.
• Output and rejects against the ideal rate for the SKU on the line.
• The current order or SKU, taken from the schedule or selected by the operator at changeover.
• Every stop with its start time, duration, machine and reason.
• Shift, day and week summaries: OEE, downtime Pareto, changeover time and output against plan.

Manual downtime sheets miss short stops, round durations to the nearest few minutes and assign reasons from memory at the end of a shift. The controller does not have that problem. When a filler stops on a low-level interlock or a capper faults, the PLC registers the state change immediately. We map those states and fault bits into one consistent stop model for each machine, so every stop is timestamped and attributed automatically. On lines we built, the stop model follows the logic we wrote. On other lines, we read the code before we trust a signal. Operators are asked only for what the PLC cannot know, such as why the line was waiting on product, and they choose from a short reason list at the HMI instead of writing it down later.

• Map each machine state and fault bit to one stop model, using PackML where the OEM supports it.
• Capture short stops automatically, well below the length an operator would ever write down.
• Separate starved and blocked states so a stop is charged to the machine that caused it, not the one that waited.
• Ask operators only for context the controller cannot supply, from a reason list agreed with production.

Overall Equipment Effectiveness, or OEE, is Availability multiplied by Performance multiplied by Quality, following the ISO 22400-2 definition of the measure. It expresses how much of the planned production time turned into good output at the ideal rate. A single number is only useful when each line counts time the same way, so the harder part is defining machine state consistently across mixed-OEM equipment. We use PackML state models and PackTags where the OEM supports them, so a stop on a filler from one vendor and a stop on a capper from another are recorded against the same definitions, and each SKU carries its own ideal rate so a slow product does not look like a slow line.

We scope and price each site after a short review of its lines, PLCs and network, because the spread between plants is wide. The drivers are predictable, though, and most of them are visible before any work starts. The quickest path is one line first: prove the stop model and reason codes on a single line, have supervisors use it in their daily review, then roll the proven pattern to the next lines. Most of the effort goes into validating signals and agreeing reason codes, not into building screens.

• Whether the state, count and reject signals already exist in the PLC or need new sensors or logic.
• How many machines and OEMs sit on each line, and how many expose clean state data.
• Whether the line PLCs can be reached from a data server on a segmented network.
• Whether a SCADA platform or historian already exists to build on.
• How many lines go live in the first stage.