The indicators: MTBF, MTTR and availability
MTBF (Mean Time Between Failures) says how long a machine runs on average between one failure and the next; MTTR (Mean Time To Repair) how long it takes, on average, to get it running again. Together they give inherent availability.
MTBF = run time ÷ number of failures
MTTR = total restore time ÷ number of failures
Inherent availability = MTBF ÷ (MTBF + MTTR)
The guide to MTBF and MTTR explains the formulas with an example and has a calculator.
What the dashboard shows
- MTBF and MTTR per machine, month by month, with inherent availability.
- The most frequent fault codes and those that cost the most hours.
- Distribution of restore times: a few long failures and many short ones call for different actions.
- Failure timeline for each machine, with the recorded maintenance work alongside.
- The trend after an intervention, to see whether MTBF really improved.
The signals to read on the OPC UA server
| Signal | Example | What it is for |
|---|---|---|
| Machine state | running, stopped, faulted, under maintenance | Run time and the start and end of each failure |
| Fault code | the code of the active alarm | Grouping failures by cause |
| Hour or cycle counter | running hours, cycles since the last service | Checking the calculated run time |
| Mode | automatic, manual, setup | Excluding stops that are not failures |
The maintenance history often sits in the ERP and the maintenance plan in an Excel file: they are connected as cloud sources and joined by machine.
The steps in Muvia Industrial
An edge node is installed on the machines' network and enrolled with a token.
On the node you add the OPC UA driver: the server's address and the nodes to read. With a subscription the server sends each state change as it happens, the most precise way to know when a failure starts and ends; polling is the alternative.
With a model for the machine type and an asset for each machine, every variable is bound to its tag: queries and calculations written on the model hold for every machine that follows it.
A Python function, run by a flow every night, turns state changes into failure episodes and calculates MTBF and MTTR per machine and period.
The dashboard shows the indicators; an alarm on a failure warns maintenance by email, and the register says who took it on and with which cause.
The pitfalls of machine states
- What a failure is: an operator stop, a wait for material and a safety alarm are not failures. Count only the fault state, perhaps only above a minimum duration.
- States that bounce: an alarm that resets and trips again within seconds becomes ten failures instead of one. Close episodes must be merged with an explicit rule.
- Run time or calendar time: dividing by calendar hours flatters a machine that works only one shift.
- Nodes that change: after a machine software update some OPC UA identifiers may change; the edge node reports the state of each driver, and it is worth checking after every intervention.
- Few failures, unstable averages: with two or three failures a month MTBF jumps around. A rolling window over several months is easier to read.
Frequently asked questions
For MTBF and MTTR what matters is knowing when the state changes: a subscription receives each change as it happens, while polling only sees it at the next read. The node's OPC UA driver supports both.
No, and there is no ready-made predictive maintenance module. Muvia measures MTBF and MTTR from real data; predictors are a building block your team can use, for example, for anomaly detection on vibration or temperature.
The edge node keeps reading and holds the data in a local buffer until the connection returns, then sends it.
The same node also reads Siemens S7 and Modbus TCP. If the fault state is available, the calculation is the same.