Root-cause analysis in hours instead of weeks.

Joining historised machine and batch context to quality results turns root-cause analysis from a multi-week reconstruction into an hours-long query. Pexon builds the pipeline that links MES events, process parameters and inspection outcomes, so recurring faults become visible instead of being rediscovered each quarter.

The starting point

The evidence exists. It is just not joined.

Machine parameters sit in the MES, inspection results sit in quality, and nobody has connected them across time. So every recurring fault is investigated from scratch, by the person who happens to remember the last occurrence.

The cost of that gap is not the investigation itself; it is the pattern nobody ever sees. A fault that recurs every quarter with a two-week investigation each time is eight weeks a year spent rediscovering the same root cause, and the second investigation never starts from the first one's findings because those findings were never joined to the machine context that produced them.

What we build

What the pipeline does

  1. 01

    Pattern surfacing

    Recurring combinations flagged instead of waiting to be noticed, with the underlying records available for engineers to check.

  2. 02

    Joining to quality

    Production context linked to inspection and complaint records on material and plant, which is where the causal signal actually lives.

  3. 03

    Historisation

    Machine, batch and process parameters captured over time rather than as a live snapshot, so a fault can be investigated after the fact.

Why the join is the hard part

The signal is in the join, and the join is a data-quality question

Machine parameters, batch records and inspection results each exist on their own timeline, and they only become evidence once they are joined on material and batch keys that were never designed to be joined. Whether that join is possible is the first thing the blueprint checks — it is a data-quality question, not a platform question.

Incomplete historian coverage is common and not automatically a blocker. The blueprint establishes what coverage actually exists before anyone commits to a use case built on it, which is why the answer to "what if our data is incomplete" is a measurement, not a reassurance.

The pattern this unlocks is failure forensics: when a customer complaint arrives, the record of the machine state at the time of production is already joined to the inspection result and the complaint, so the investigation starts from evidence rather than from memory. That is the difference between an incident that costs a week and one that costs an afternoon.

Sequence

The order we run the work in

  1. Map what is historised today. Which machine parameters, batch records and inspection results actually exist over time, and on which keys. This measurement decides everything that follows.
  2. Prove the join on one material and one plant. Join the existing records on the keys that survive, and check the coverage. One line or one plant end to end, before anything widens.
  3. Close the coverage gaps that matter. Historise the parameters the use case actually needs, on the timeline that makes them joinable. Not everything — only what the pattern needs.
  4. Surface patterns from the joined record. Recurring combinations flagged against quality and complaint records, with the underlying records one click away for an engineer to verify.

What changes

  • Investigations start from joined evidence rather than from memory.
  • Recurring faults become visible as patterns rather than as separate incidents.
  • Quality and production argue from the same record instead of two exports.

Start with one line or one plant.

We take a single production line end to end before widening. A pattern proven on one line transfers; a pilot spread thin across four proves nothing.

MES specifics

Which MES systems do you work with?

We are not tied to a vendor. What matters is whether the system exposes historised events and whether the batch and material keys are consistent enough to join to quality data — that is the first thing the blueprint checks.

What if our historian data is incomplete?

That is common and is not automatically a blocker. The blueprint establishes what coverage actually exists before anyone commits to a use case built on it.

Next step

Not a sales call. An architecture call.

Thirty minutes with the architect who would actually run the engagement.