Energy, utilities and offshoreMuvia Industrial
Anomalies and predictive maintenance
Vibration, temperature and current read from the PLC become a deviation from normal, a health index and, if you want, a score from a model of your own, in the cloud or on the node next to the machine. When a signal drifts, an alarm goes off and maintenance hears about it.
Illustrative scenario: it describes a typical case, not a customer project.
A failure shows up in the signals first, but nobody reads them every day.
In most plants the data is already there: the PLC knows the vibration, the bearing temperature, the motor current, the cycles run. But it stays on the operator panel, and maintenance looks at it once the machine has already stopped.
Catching a drift means comparing every signal with its normal behaviour, every day, on every machine. That is a job for a system, not a person. In Muvia your team builds it, with ready-made analyses and, where it helps, a model of your own.
Muvia does not promise to predict failures. It gives you a place, close to the data, to run the rules and models your team develops on your machines.
- Who it's for
- Maintenance managers, process engineers and the data scientists who work with the plant.
In Muvia, step by step
Real product screens, recorded on a project with sample data.
The video · Vibration, temperature and current read from the PLC become a deviation from normal, a health index and, if you want, a score from a model of your own, in the cloud or on the node next to the machine. When a signal drifts, an alarm goes off and maintenance hears about it.
What you get
- Drifts are visible as they happen
- A slowly growing deviation shows up on the dashboard and in an alarm, instead of surfacing only when the machine stops.
- One rule for the whole fleet
- Baseline, index and thresholds apply to every machine: adding one means connecting its tags.
- The model stays yours
- Your team trains it with the tools it prefers; Muvia runs it close to the data and keeps its results next to the signals.
- Every alarm has a history
- Episodes, suggested causes, acknowledgements and notes stay in the register, so the next intervention starts from there.
For the technical team
How it is built in Muvia
- 1
Connect the machine signals
On the edge node you configure the S7 or OPC UA driver and pick the variables: vibration, temperature, current, cycle count. Each becomes a named tag; if the connection drops, the node keeps the readings in a local buffer.
- 2
Define what normal looks like
With the ready-made analyses you compute a moving average and the deviation from baseline (z-score) of each signal, machine by machine. The column profile shows distributions and quantiles before you choose thresholds.
- 3
Roll it up into a health index
The “Weighted health index” catalogue function combines the deviations into a value from 0 to 100, with weights you choose. A scheduled flow writes it to a table that dashboards and alarms read.
- 4
Bring your own model
A Python function loads the model your team trained outside Muvia, as ONNX or joblib, or fits a scikit-learn IsolationForest on the window of data it receives. It runs in the cloud or on the edge node next to the machine, on the same runtime, and a trial run writes nothing.
- 5
Raise the alarm and tell maintenance
A threshold with a deadband on the index or the score opens an episode in the alarm register. The diagnose function asks a language model for likely causes, and maintenance gets the notice, acknowledges it and adds notes.
Python function
import numpy as np
import pandas as pd
import onnxruntime as ort
FEATURES = ["vibration_rms", "bearing_temp", "motor_current"]
def transform(inputs, params, ctx):
df = inputs["rows"].sort_values("ts")
session = ort.InferenceSession(ctx.file("model.onnx"))
x = df[FEATURES].to_numpy(dtype=np.float32)
name = session.get_inputs()[0].name
score = session.run(None, {name: x})[0].ravel()
out = pd.DataFrame({
"ts": df["ts"],
"machine": df["machine"],
"anomaly_score": score,
"anomalous": score > params["threshold"],
})
return {"rows": out}- The data it needs
- Vibration and bearing temperatures from a Siemens S7 PLC
- Motor current and cycle counters from an OPC UA server
- Maintenance history from the ERP, copied from SQL Server
- A model trained by your team, as ONNX or joblib
More cases in this line
All use cases- Energy use per line and per pieceMeters and power analysers read over Modbus TCP, joined with the pieces produced and the orders in the ERP: how much energy each line, each shift and each piece takes, with an alarm when consumption looks out of the ordinary.
- The pumping station in 3DPump hall, sump, headers and tanks in the 3D model, every machine carrying its asset's name and its signals alongside. You search for a pump by name, see it in the model and read its vibration against the manual's limits, next to that of its twin.
- From tag names to assetsFive hundred control-system tags, with names such as KP2_P201A_VT01, read by a Python function the way a technician would read them: machine code, instrument, unit. Every match to an asset variable comes with a confidence and a reason, and the doubtful ones go to a person.
Tell us which machines you run. We'll tell you how to read them.
PLC brand, protocol, how the floor is connected: with those three answers, in a demo with one of our engineers, we show you how Muvia Industrial puts line data next to the rest of the business.