First step in digitalisation, without an expensive MES

Many plants receive quotes for MES or “Industry 4.0” projects with licences, integration and two years of consultancy, while the day’s production is still written on paper sheets. In the evening, someone in the production office retypes the sheets into Excel. At the meeting next morning the figures are already old and nobody is sure why line 3 stopped at 2 pm.

An MES solves part of this, but only if you already have clean data, people who look at it and a clear idea of what you want to find out. Otherwise you buy an expensive system that displays the same doubtful figures, only prettier.

Start with a question

Do not start from “we want to digitalise production”. Start from a question that someone asks every week and does not get a good answer to:

• Why does the line stop, and how long does each stop last?
• How much scrap comes out per shift and per product?
• How much of the planned time does the machine actually run?

Pick one. The best is the one that costs the most and is discussed mostly with opinions instead of data. On most lines the first is stops, because almost everything else is calculated from them.

Then decide who uses the answer and when: the shift leader at handover, maintenance at the daily meeting, the production manager at the weekly review. If you cannot name a person and a meeting, the question is not good enough yet.

Data at the source

The basic rule: data that can come from the machine comes from the machine, not from a person. The operator fills in only what the machine does not know.

From the machine you can usually take, without touching the process logic:

• the “running” or “stopped” signal
• a counter of cycles or good parts
• a counter of rejected parts, if the machine has built-in inspection
• alarm codes, if the PLC exposes them

You have two routes. The first: read these values from the PLC, through a protocol it already supports (OPC UA, Modbus TCP or the controller’s native driver). The second, for old machines or where you are not allowed to touch the PLC: fit a simple digital input module that picks up a signal from the signal lamp, from a relay or from an inductive sensor on the movement that marks a cycle. The second route is often faster and safer at the start, because you do not depend on the programmer who wrote the code ten years ago.

What the machine does not know is the reason for the stop. Here you put a tablet at the line, with a short list of reasons. When the machine stops for longer than a set threshold (say two minutes), the tablet asks the operator to pick the reason. A few rules make the difference:

• At most 8 to 12 reasons at the first level, worded in the operators’ language.
• No “Other” option at the top of the list; if you keep it anyway, track how often it is used.
• The machine detects the stop, not the operator. The operator only explains it.
• The list is reviewed monthly with the people on the line.

For scrap, if the machine does not count it, the operator enters it on the tablet at the end of each hour or at lot changeover, not at the end of the shift from memory.

Show the data where decisions are made

Data sitting in a database changes nothing. The first screen you build is not a dashboard for management. It is the shift board: output against plan by hour, stops with reason and duration, scrap. A TV at the end of the line and a printed sheet for the daily meeting are enough.

In the daily meeting, the discussion shifts from “I think it was the tooling” to “we had 47 minutes of stoppage on tool changes, in four stops”. The figures in this example are illustrative, but the kind of discussion is what matters. When people see that their data is used to solve problems and not to look for someone to blame, the quality of data entry usually improves without further campaigns.

In the first months, measure two things: how much of the stop time has a reason filled in, and how much time passes between the event and its appearance on the board. If reasons are missing on half the stops, the problem is the list or the pace of the line, not the operators.

Extend once it works

Only after one line has run for a few weeks without daily intervention from the project team do you move to the second. Extend in this order: the same question on more lines, then a new question on the same lines. Do not do both at once.

IT and OT

Machines do not connect directly to the office network. The production network sits in a separate segment, with a firewall between it and the IT network, and a single point through which data leaves for a server or the cloud. The ISA/IEC 62443 standard describes the zones and conduits model; you do not have to apply it in full from day one, but the separation must exist from the start.

Set out in writing who is responsible for what. Typically automation looks after the PLCs, input modules and the switches on the shop floor, IT looks after the server, backup and accounts, and production owns the list of reasons and the use of the data. Who approves a change in the production network and who holds the firewall password must be clear before the first problem, not after.

No dependence on a single vendor

The first small project often decides the architecture for many years. A few checks before you sign:

• Data is read through open protocols: OPC UA for reading from the PLC, MQTT for transport to the server.
• You can export all raw data, with timestamps, in a standard format, at no extra charge.
• The database is a documented one, not a closed application format.
• The list of reasons, the shift calendar and the line structure belong to you and can be exported.
• The contract says what happens to the data if you leave the vendor.

An architecture in which each machine publishes its data to a common place (an MQTT broker, for example) lets you change the display application later without redoing the connections to the machines.

When you need an MES

An MES starts to pay off when you already have reliable machine data and requirements appear that the simple solution no longer covers:

• Customers require traceability by lot or serial number, linking raw materials, process parameters and the finished product.
• You need work orders sent from the ERP to the line, with automatic confirmations sent back.
• Recipes or parameters must be downloaded to the machine depending on the product, with version control.
• You have several lines or plants that must be compared on the same definitions.
• Your team spends more time maintaining scripts and Excel sheets than analysing data.

If you tick one or two, you can still extend the simple solution. If you tick most of them, write the requirements from what you learned on the first lines, including the list of stop reasons and the definitions you already use. That way you evaluate the quotes against your own data, not the vendor’s demo.

If you have been through this or are just starting, we talk in the WhatsApp group “Digitalisation & Industry 4.0”.