INDUSTRIAL DATA & PREDICTIVE MAINTENANCE

A sensor tag is not yet
a maintenance signal.

The broker can be receiving data while operations still cannot use it. A temperature needs an asset, unit, operating state, quality flag, history and a decision it can change. We build that chain—from plant data to an owned maintenance action.

Map one asset See where meaning enters

Start read-only. Prove the signal before changing the work.Illustrative examples—not a claim that every failure can be predicted.

SIGNAL BENCHILLUSTRATIVE · PICK AN ASSET
P04.VIB.RMS7.2 mm/s✓ MQTT message arrived
  • Asset: cooling-water pump 04
  • State: running at 92% load
  • Baseline: 3.1–4.0 mm/s at this load
  • Maintenance: bearing replaced 14 months ago
OPERATIONAL DECISIONInspect within the next planned maintenance window

Vibration is outside this asset’s load-adjusted baseline, but temperature and flow remain stable.

THE CHAIN.
OT TO ACTION.PLCOPC UAMQTTHistorianAnalyticsCMMS

01 / THREE DIFFERENT PROBLEMS

Connected, contextualised
and actionable are not synonyms.

Most industrial data programmes can show values on a screen. The hard part is preserving enough meaning for another system and another team to trust them.

CONNECTED

The value arrived

A protocol and gateway moved bytes from the plant. This proves transport, not asset identity, units, quality or business meaning.

CONTEXTUALISED

The value means something

The tag is tied to an asset, operating state, timestamp, engineering unit and stable information model.

ACTIONABLE

The value changes work

A tested condition enters a maintenance queue with evidence, priority and an owner who can inspect or dismiss it.

02 / THE WHOLE DATA CHAIN

Six layers.
One operational decision.

A dashboard can be useful, but it is not the final layer. The signal earns its cost when it changes a planned inspection, work order or operating response.

01

Acquire

PLC, SCADA, sensors, gateways, historian exports and vendor APIs—with quality and timestamps intact.

02

Transport

OPC UA, MQTT or the existing plant interface moves the signal; transport is chosen to fit the environment.

03

Context

Asset, unit, state, recipe, location and maintenance keys turn a tag into an operational fact.

04

History

A historian or time-series store preserves enough clean operating history to establish a usable baseline.

05

Detect

Rules, condition indicators and models identify deviation with evidence—not an unexplained risk score.

06

Act

The alert reaches the CMMS or operating queue with asset, reason, evidence, priority and a named owner.

Architecture basis: the OPC Foundation Cloud Reference Architecture explains why MQTT alone does not preserve meaning and context, and how standard information models reduce proprietary payload and topic-tree silos. We use those principles where they fit; this page does not imply OPC Foundation endorsement.

03 / DO NOT START AT PREDICTIVE

Use the simplest level
that changes the decision.

A model cannot manufacture missing failure history or asset context. Condition-based monitoring is often a more honest first production system.

01

Reactive

A failure becomes the signal. Start by making downtime and work-order history trustworthy.

02

Threshold

A limit creates an alert. Useful for known boundaries, noisy when load and operating state are missing.

03

Condition-based

Several signals and the asset state show degradation. Often the best first production target.

04

Predictive

History supports a tested estimate of failure risk or remaining life with an operational response attached.

The economics vary by plant and sector. Siemens’ 2024 True Cost of Downtime report documents that wide range rather than a universal hourly number; its automotive estimate reaches $2.3 million per hour. We do not use that top-end figure as your ROI. Your own lost output, labour, quality, restart and maintenance data determine the case.

04 / THE FIRST ENGAGEMENT

One asset class.
One decision worth improving.

We choose an asset with operational importance, accessible signals, maintenance history and a response the team can actually take. Then we prove the data chain in shadow mode before it creates a work order.

Signal to evidence.
Evidence to action.
  • 01One asset class and one maintenance decision, defined before platform work
  • 02A source and tag inventory with owners, units, timestamps and quality flags
  • 03The canonical asset and event model
  • 04Edge-to-platform transport using supported plant interfaces
  • 05Historian or time-series design and retention boundary
  • 06Baseline and condition indicators using representative operating history
  • 07Alert evidence, suppression and escalation rules
  • 08CMMS or work-order integration with a named maintenance owner
  • 09Read-only shadow run before operational release
  • 10Security boundary, runbook, monitoring and handover documentation
Boundaries we keep explicit
  • No changes to safety logic or control loops without the responsible controls team
  • No promised prediction where there is no labelled history or measurable precursor
  • No cloud requirement where plant policy requires an edge or on-premise boundary
  • No automatic work orders before a shadow run proves alert usefulness

BRING ONE ASSET

Not the whole plant.
The failure that matters.

Bring the tag list, historian sample, operating context, work-order history and the maintenance decision you wish arrived earlier. We will tell you what is usable and what is still missing.

  1. Trace the signal from source to asset context
  2. Test whether history supports a useful condition
  3. Scope a read-only production path into maintenance

OT, maintenance and IT should all be in the room.info@chronexa.io

Describe the asset and the failure mode.

Include available sensors, historian, CMMS and the action you want the signal to change.

BEFORE THE PILOT

Questions that protect the plant.

Do you install sensors or replace our SCADA?

Not as the default offer. We start from the controls, sensors, gateways and historians already present, then assess the missing data and context. Specialist hardware or controls partners may be required where instrumentation is genuinely absent. We do not replace a safety or control system with a cloud workflow.

Is MQTT the same as a Unified Namespace?

No. MQTT is a lightweight transport and broker pattern. A usable industrial namespace also needs consistent topic conventions, payload semantics, asset identity, units, state, quality and governance. The OPC Foundation explicitly notes that MQTT alone does not preserve meaning and context across OT and IT.

Do we need machine learning for predictive maintenance?

Often not first. Clean asset identity, failure labels, operating state and condition indicators usually create value before a model can be justified. Threshold or condition-based monitoring may be the correct production system. We recommend predictive modelling only when the history and decision support it.

Can you predict every equipment failure?

No. Some failure modes have no measurable precursor, some assets lack enough history, and maintenance changes the data-generating process. We define the specific failure mode or condition being detected, test it against representative history and keep the operational response human-owned.

How do you avoid flooding maintenance with alerts?

Model the operating state, add persistence and suppression rules, group related signals, route by asset criticality and measure whether an alert led to a useful action. Alert volume is not success. A smaller number of evidence-rich, owned exceptions is usually the goal.

Can plant data remain on site?

Yes. Collection, contextualisation and detection can be placed at the edge or inside the plant boundary where required, with only approved events or aggregates leaving it. The design follows the existing OT security architecture and change-control process rather than assuming cloud connectivity.