We continue the series of articles on ML in manufacturing.

In previous articles, I’ve already talked about defect audits, PLC signals, monitoring, and tidying up factory data. Now the story has become a bit closer to machine learning: we started to formulate data requirements for a model that should help predict defects and product failures.

Sounds nice. But in practice, the first step turned out to be quite down-to-earth: understanding what data is missing, figuring out what kind of data is missing, and writing a proper technical request to the equipment manufacturer—not just asking for “send us something about the sensors,” but clearly explaining what data is needed and why.

Why Can't We Just Take All the Data and Train a Model?

At the factory, data looks like chaos: there are registers, bits, some analog values, failures, counters, parameters from the operator's panel. Formally, the data exists. But what quality is it for ML?

If I see a hypothetical register with a value of 1200, I need to understand:

  • what this parameter is;
  • in what units it is measured;
  • whether it needs to be divided by 10, 100, or not touched at all;
  • how often it is updated;
  • whether it relates to the current cycle, the previous product, or the operator's settings;
  • whether it can be read safely and stably from the outside.

Without this, the model might learn not the production process but a mess of misunderstood numbers.

The most unpleasant scenario is when the model shows some metrics, but we aren't sure they are based on reality. In manufacturing, this is especially dangerous: incorrect data interpretation can lead not just to a bad graph on a laptop but to wrong conclusions about the cause of defects and even equipment failures.

What We Want to Predict

Our goal is quite clear: to build an ML model that can analyze the state of the equipment, operating modes, failures, reasons for stops, and causes of defects, to help predict product defects.

So we need not just “all the data in a row.” We need data that helps link the machine's state to product quality.

Especially important are:

  • total product count;
  • good product count;
  • defect count;
  • reasons for defects, if they are recorded;
  • failures and reasons for stops;
  • operating modes of the equipment;
  • technological parameters;
  • settings and parameters that the operator specifies from the panel.

Why are counters so important? Because they can provide almost automatic labeling (that’s supervised learning). If the equipment itself records the amount of good product and defects, we can build the first logic of the dataset around these registers.

This doesn’t mean the task is solved immediately. But there’s a huge difference between “we’re trying to understand where the defect was by hand” and “we have a systematic signal to work from.”

The Main Problem: Some Data Exists, But It Just Doesn’t Make Sense

At this stage, we already had some materials: some analog values, some registers, some signals, all of which we collected from the machine almost manually.

But it still turned out to be insufficient.

For example, there are D-registers. They are useful, but by themselves, they don’t always explain the whole process. To link them with modes, states, buttons, failures, and logic of operation, we need labels, comments, and an address map (which, by the way, we don’t have).

An additional complexity is the data from the motion controller. Some important parameters may not reside in the main controller but inside a separate CPU related to motion. And here comes the question: can we read this data through the existing connection to the main PLC via an industrial protocol, or do the necessary registers need to be pre-transferred to the main controller's readable area?

This sounds like a minor engineering detail. But for ML, it’s critical. If a parameter is important for defects but we can’t read it stably, it won’t be in the dataset. And if it appears later, the model and pipeline will need to be revisited. So besides ML, we’re starting to deal with ACS TP and sometimes even KIPiA (for example, analyzing the equipment's electrical schematics).

But to make sure we understand everything, it’s better to ask the equipment manufacturer for data.

How We Formulated the Request to the Manufacturer

The main thing is not to ask for “documentation in general,” because you run into authorship/intellectual property issues. Such a request almost always turns into a brush-off.

We took a different approach: we prepared specific tables and a list of what needs to be confirmed or filled in. Because we first understood what data we were missing and what we had.

The request included two main parts.

  1. Completed I/O and register map

For example: - actual address in the main PLC; - data type; - data size; - purpose of the parameter; - unit of measurement; - scaling; - decoding of values for codes and bits; - condition or update period.

This is like a dictionary for the data. Without it, you can’t properly do monitoring, diagnostics, or ML.

  1. Export of labels and comments from the PLC project

Separately, we requested the export of Global Labels and Device Comments from the PLC development environment.

Important: don’t ask for the source code of the logic, functional blocks, or the complete project. No one will give you that. You only need labels, addresses, comments, and the meaning of the data that can be read in read-only mode.

It’s a big illusion that for ML you need everything. In reality, you don’t need to try to dig into the manufacturer’s logic. We need to understand what each available parameter means so we don’t build a model on guesses.

Why Data Accuracy is Directly Related to Product Quality

In our task, ML is needed as a tool for analyzing the production process.

But the tool only works when the input data is accurate.

If we mix up the register address or don’t understand what it means, the model will look in the wrong direction.

If we don’t recognize the scaling, temperature or speed could turn out to be ten times greater or less than the actual value.

If we don’t understand when the defect counter is updated, we’ll incorrectly tie the defect to time.

If we don’t get the decoding of codes, failures will turn into a set of numbers without meaning. And finding them on the actual machine later will be impossible (the machine is 50 meters long).

And in the end, the model might start finding “patterns” that exist only as patterns of some numbers, without their interpretation in the real world.

Formally, of course, as an ML engineer, you’ve done your job—you built a model, and you have a nice recall. But who needs it? Unless to talk about it at a trendy conference?

Practical Checklist Before the Defect ML Model

In short, I would check this list:

  1. Define the target event
    What exactly do we consider a defect? Where is it recorded?

  2. Find automatic labeling
    Are there defect, good product, and total count counters?

  3. Gather a data map
    For each parameter, you need an address, type, size, units, scaling, and comment.

  4. Understand data availability
    What can actually be read from the PLC? What is not directly accessible? What needs to be transferred to a readable area?

  5. Extract meaning from HMI
    Settings and operator parameters often explain more than they seem.

  6. Separate facts from hypotheses
    Unconfirmed signals cannot be used as reliable features.

  7. Don’t ask for too much
    For analysis, the PLC source code is usually not needed. Often, labels, comments, addresses, and read mode are sufficient.

Conclusion

This work doesn’t yet look like a classic ML experience: “here’s your ROC-AUC, here’s your Recall, I’m great.”

But exactly how I described it lays the foundation for a normal ML model.

If the data is accurate, complete, and properly understood, we can then build a normal dataset, confidently search for connections between equipment modes and defects, test hypotheses, and gradually move towards predicting defects. And most importantly, know how to manage them later.

And if this stage is skipped, the model will be about production, but about our guesses and pretty words, ROC-AUC, Recall, etc. And in real production, that’s too expensive a luxury.