Machine data collection: which data is worth collecting?

From production machines, collect data that helps you reconstruct the production process, identify the source of losses, and connect process parameters with the result. To start with, machine states, cycle times, counters, stops, alarms, and OK/NOK results are usually enough. Add temperature, pressure, current consumption, or vibration when you want to investigate a specific relationship.

Start with a production problem and define what you want to explain, list the information needed for the analysis, and then select the appropriate PLC signals and data from other systems.

A PLC can provide hundreds of variables, but what you primarily need are those that help you explain a specific situation on the shop floor.

When production falls below plan, you check operating time, stops, and cycle rate. When quality issues occur, you connect process parameters with a batch or a specific part. Maintenance analyzes temperature, current consumption, vibration, alarms, and events that occurred before a failure. The easiest way to approach this is through the following six elements:

Suppose you want to find the source of lost production time. First, determine when the machine stopped and how long the downtime lasted. Then assign a cause, check the impact on production, and select the appropriate PLC signals, MES data, or information provided by the operator.

ISA-95 describes models and information exchange between control systems, manufacturing operations management, and business systems. The controller usually provides data about equipment status and the course of the process. MES, ERP, or an operator application can provide context related to the production order, product, batch, or cause of an event.

At the beginning, focus on the questions or problems that come up most often in production. For example:

A drive alarm describes a technical event, and when you combine it with its duration, production order, and shift, you can see how much production time the event consumed. If you want to convert that time into potentially lost production, add the reference production rate appropriate for the given product or process.

The first set of data should allow you to reconstruct how the machine operated during a shift. It usually includes equipment status, cycle start and end, part counter, OK/NOK result, stop start and end, alarm code, operating mode, and the active program or recipe.

From this history, you can determine when the line was running, when it was stopped, how long cycles lasted, and how often disruptions occurred. This gives you material for analyzing availability, micro-stoppages, and changes in operating speed.

A PLC can provide information about a drive failure, safety guard status, sensor error, or another technical event if the controller program supports that type of diagnostics. Organizational causes often come from other sources. MES may contain production order and product data, while the operator may indicate a material shortage, waiting for a quality decision, or a logistics issue.

A counter showing 12,480 parts gives you a specific number, but only the product, production order, and production period tell you what that number refers to. The same applies to process temperature. A value of 186°C only starts to say something meaningful about production when you connect it with the batch, process stage, and inspection result. For this reason, in machine data collection and PLC data extraction, you often also need:

• machine or workstation identifier,
• production order number,
• product and variant,
• batch or serial number,
• recipe,
• production shift,
• downtime classification,
• quality inspection result,
• unit of measurement,
• timestamp.

For every variable, define two sources: the source of the signal itself and the source of its context. This way, you will know which information is available in the PLC, MES, or ERP and which information must be entered by the operator.

Temperature, pressure, torque, current, flow, or vibration can quickly expand the scope of a machine data acquisitionproject, so connect each of these parameters with a specific question.

If the quality department wants to investigate the relationship between temperature and the number of defects, you need the temperature value from the appropriate moment, product or batch identification, and the inspection result. You can then compare the process history with the actual quality result.

You follow a similar approach in diagnostics. If you want to check whether current consumption changes before the equipment stops, compare the current history with the moments of failure, downtime, and service intervention. Such a comparison will show whether a repeatable relationship exists between these events.

Every additional parameter should therefore answer one specific question related to the product, quality, failure, downtime, or process phase.

Every signal changes at a different rate. You can record machine status when it changes, sample the temperature of a stable process periodically, while a rapidly changing diagnostic signal may require much denser data acquisition.

Across the entire data path, separate three stages: reading the source through an OPC UA server, transmitting selected changes to the client, and archiving them in a historian or another system. Each stage may operate according to different rules and at a different frequency.

OPC UA allows you to configure the sampling frequency, queues, and filters for monitored variables. You can also apply a value-change filter, or DataChangeFilter, with a so-called deadband. The system ignores small fluctuations and sends information only when the value changes by a defined threshold. For example, when measuring temperature, you may decide that a change of 0.1°C is too small to record every time and that only larger changes are relevant. The system archiving the data may later apply its own storage rules.

Therefore, before configuration, determine how quickly the observed phenomenon changes and how detailed a history you will need later. These two criteria should determine the recording frequency.

If you combine manufacturing data from several machines and systems, you need to know the actual moment when an event occurred. Even a small time difference between devices can change the order of events in the analysis if the process runs quickly.

OPC UA distinguishes between SourceTimestamp, which is the time assigned to a value by its source, and ServerTimestamp, which indicates the moment when the server received the value or considered it current.

Before starting data collection, define the time source, the method used to synchronize devices, and how the system should behave after a communication interruption. For micro-stoppages, traceability, and quality analysis, a consistent timeline makes it easier to correctly combine events from multiple sources, while the required synchronization accuracy should be matched to the dynamics of the process and the type of analysis.

• At the first level, collect operational information: states, cycles, counters, stops, and alarms. This allows you to reconstruct how the equipment operated.
• At the second level, add production context: product, production order, batch, recipe, shift, and downtime reason. You can then assign each event to a specific production run.
• At the third level, add process and diagnostic parameters such as temperature, pressure, current, vibration, torque, or flow. Their scope depends on the technology and the problems you are analyzing.

This division helps organize the project and determine the sequence of work. If you want to analyze availability, the first level is often a sufficient starting point. For traceability, you quickly need data from the second level. Quality analysis usually leads to the third.

Suppose a line regularly finishes the shift below the planned number of parts. The team suspects micro-stoppages.

To start with, collect machine status, cycle start and end time, part counter, and stop information. After several days of history, you will see whether the line is losing output because of longer downtime, frequent short interruptions, or gradually increasing cycle times.

If the PLC stores a stop reason code, add it to the history. For organizational events, include MES data or information from the operator.

When the analysis shows increasing cycle times, expand the scope with additional parameters: temperature, pressure, duration of individual phases, feeder status, or drive load. Then every new signal corresponds to a specific hypothesis about the cause of the problem.

Production defines the questions it wants to answer. Automation specialists identify the PLC signals that are available and how they are represented. The process engineer selects the process parameters. Maintenance contributes information about failures and equipment behavior. IT or OT is responsible for transmission, storage, and access to the data.

For quality and traceability, also involve the people responsible for product inspection and batch identification. Together, prepare one worksheet with the objective, source, context, owner, and frequency for each important data point.

Such a document gives the technical team a clear scope and limits the later addition of random variables.

Prepare a simple working table with seven fields:

Based on this, the automation engineer will check signal availability. The integrator will determine how to acquire and map them. Production will verify whether the scope addresses real problems.

If your facility has many machines, several generations of controllers, and different higher-level systems, start with a data source analysis or a pre-implementation audit. This stage will show which information you already have, where the gaps are, and which sources need to be connected through PLC integration.

Add a column called use in decision-making to your tag worksheet. For every variable, enter who uses it and what analysis it supports. If the team can identify a use case, the variable has a clear place in the project. If the data will only be useful for another question later, add it in the next phase.

This is how you design production data and shop floor data collection. You start with the problem, define the information you need, add context, and only then move down to the specific signal from the PLC. This approach gives you a shorter data list and a clearer implementation scope.

Start with machine states, counters, cycle times, stops, alarms, and OK/NOK results. Add process parameters when you are analyzing quality, equipment condition, or a specific phase of the process.

Match the frequency to the dynamics of the signal and the purpose of the analysis. Record status when it changes, record slowly changing parameters periodically, and collect rapidly changing signals at higher resolution.

Connect PLC signals with the product, production order, batch, recipe, shift, and quality result. The context may come from MES, ERP, an operator application, or other systems used in the facility.

You usually need a product or batch identifier, operation time, workstation, recipe, process parameters, and inspection result. Match the scope to the process and the required level of detail in the product history.

Choose one problem, such as micro-stoppages, defects, or increasing cycle time. List the information needed to explain it, and then assign specific PLC variables and data from other sources to that information.