Contextualization sounds like an enterprise abstraction. It is not. It is six specific joins, each of which changes a real decision on a real line. Here they are, one by one.
In a refinery, a historian streams values from a tag called TI-4711. In an FMCG plant, a PLC reports that the filler on Line 4 stopped for six minutes. The scale is different; the problem is identical. On their own, both are just numbers with timestamps. Their entire decision value comes from what you can join them to.
A contextualized event answers six questions: what was running, what had just happened, which component is involved and what is its history, what physically occurred, what does it cost, and who was operating. Each answer comes from a different join. Each join changes the decision.
Let us take that six minute stop on Line 4 at 14:32 and add the joins one at a time. This example is drawn from our work with a design partner, an FMCG manufacturer whose plants produce detergents, tissue and hygiene products, and food, which means the same platform has to make sense of liquid lines with cleaning cycles, high speed converting lines, and food lines with recipe constraints.
Six joins around a single stop event, and the decision each one changes.
The MES join tells us the line was running SKU 4711, a high viscosity detergent, against production order PO-88213. This matters far beyond bookkeeping. A pump drawing 15 percent more current than baseline is a degradation signal on a thin product and completely normal on a thick one.
Without recipe aware baselines, an insight engine drowns the maintenance team in false alarms within a week, and false alarms are how trust dies. Every performance standard, run rate, and deviation threshold has to be defined per product, not per machine nameplate.
The schedule join tells us the stop occurred 40 minutes after a changeover from SKU 3302, still inside the ramp up window. Ramp up losses are a real and expensive problem, but they are a different problem from steady state failures, with different owners and different fixes.
The same logic applies to cleaning cycles on liquid lines: an energy spike at 02:00 looks like an anomaly until the schedule shows a caustic wash was running. Time context separates the abnormal from the merely scheduled.
The maintenance join is where most plants quietly fail. It tells us the stop involves a specific valve block on the filler, that this is the third stop involving that component this month, and that its last preventive maintenance was six weeks ago.
That sentence is only possible if assets are modeled to component level with stable identifiers used identically across performance monitoring, maintenance, and planning. Where downtime is coded to Line 4 and work orders are written against Filler 2, the phrase third time this month literally cannot be computed.
The repeat offender stays invisible, and repeat offenders are where the money is.
The camera join corrects the record. The PLC reported the stop at the filler, but the video replay shows the jam started at the upstream capper; the filler simply starved seconds later. Without visual evidence, the work order goes to the wrong machine, the fix fails, and the operator learns that reporting problems produces paperwork instead of results.
Computer vision also catches what sensors structurally miss: micro stops, jams, and losses at manual stations. And it settles arguments with evidence instead of seniority.
The ERP join is the one most operational platforms never make, and it changes the language of the entire conversation. Order, bill of materials, and margin data tell us this stop hit the highest contribution SKU on the line, on an order due Thursday for a key customer.
Six minutes is no longer six minutes; it is a quantifiable amount of money and a delivery risk. Prioritizing by euros rather than percentage points is what makes a maintenance backlog legible to a plant director, and it is what lets two completely different problems on two different lines be compared honestly.
The final join adds the human layer: night shift, crew B, procedure version 3. Some patterns that look mechanical are organizational. If changeovers run 20 minutes longer on one crew, the fix is coaching and a better checklist, not a spare parts order. This join must be handled with care and used for improving procedures rather than assigning blame, but ignoring it means treating training problems with wrenches.
Joins are only as good as the data entering them, which is why we insist on capturing the same reality through multiple independent channels. The PLC detects the stop. The camera confirms it and shows what happened. The operator classifies the reason on a mobile device at the machine, scanning the asset QR code.
Work orders cannot be closed without confirmation in the field. When sources disagree, the disagreement is flagged rather than averaged away. The goal is simple to state and hard to achieve: unclassified downtime driven toward zero, because every unclassified minute is a minute the insight engine has to guess about.
Two things follow that deserve to be said plainly, because they decide whether any of this works on a real shift. The cameras watch the process, not the people: they point at product flow and mechanisms, and their job is to explain stops, not to score individuals.
And the operator side of the deal is lighter than the paper it replaces: classifying a stop is a few taps at the machine, in the operator's own language, and crew level patterns are used to improve procedures and training, never for individual performance scoring.
A system that operators experience as surveillance gets fed garbage, and it deserves to.
We will be honest about what capturing context at the source still requires, because this is where projects succeed or quietly fail. It requires a canonical asset hierarchy, from site to line to machine to component, with stable identifiers everywhere. It requires time alignment across PLC clocks, cameras, and human entries, because a 90 second offset attaches a stop to the wrong production order.
And it requires taxonomies that people actually use: failure modes, downtime reasons, and per product standards for run rates and changeovers, since deviation from standard is undefined until the standard exists. None of this is advanced science. All of it is deliberate work, and doing it in weeks rather than quarters is a methodology, not an accident.
Two reassurances belong here as well. The evidence base is built from clean data going forward; fifteen years of messy free text maintenance history do not have to be scrubbed before the system becomes useful, although whatever structure exists is gladly imported. And equipment without PLC access is not excluded: retrofit sensors and computer vision exist precisely so that the older half of the plant is covered too.
Here is the uncomfortable truth to end on: a perfectly contextualized event still changes nothing by itself. It becomes valuable at the moment it turns into a prioritized recommendation, an approved work order, a scheduled window, and eventually a measured outcome. Context is the foundation. What stands on top of it is the subject of Part 3: the decision layer.
Fabrico is a manufacturing operations platform combining OEE monitoring with computer vision, a full CMMS, MES capabilities and production planning in one data model. See it on a connected OEE and CMMS platform or book a demo.
Вход
Блог
